Receipt page · Feed & Execution
How the Feed & Execution suite measures
This is a receipt page. Dossier §8.2 fixes what one contains, and the five sections below are that anatomy in order: the versioned methodology, the pre-registrations, the proof corpus, the changelog, and the invitation to recompute any published number without asking me for anything. Nothing has been measured yet. Three of the five sections are therefore empty, and they are empty in a way you can inspect — the structure is printed, the slots are named, and each one says NOT YET PUBLISHED rather than showing you something plausible. Looking for what this family will contain instead? That is the Feed & Execution suite hub.
Receipt anatomy · dossier §8.2Feed & Execution suiteReceipt version v1.0
- Instruments in scope
- 3
- Metrics defined
- 14
- Pre-registrations posted
- NOT YET PUBLISHED
- Artifacts published
- NOT YET PUBLISHED
- Measurements published
- NOT YET PUBLISHED
- 01Methodology, versionedProse and formal definitions. Every metric carries its name, its definition, the estimator that computes it, its known failure modes, and what it does not establish. The page carries a version, and the version is printed on it.DEFINED · v1.0
- 02Pre-registrationsDeclarations made and dated before any measurement runs: decision thresholds, exclusion rules, completeness bars. Immutable once posted — an amendment appends beneath the original with its reason, and never overwrites it.NOT YET PUBLISHED
- 03Proof corpusThe published artifacts themselves: dataset descriptors, content hashes, download links, and the version tag of the code that generated each one. A result whose inputs are not downloadable is not a receipt.NOT YET PUBLISHED
- 04ChangelogAppend-only, dated, written by a person. What changed on this page, when, and why. A correction is a new entry naming the entry it corrects — entries are never edited away.1 ENTRY
- 05Independent recomputationThe exact numbered steps a stranger follows to re-derive a published number without asking me for anything. Where the recomputation disagrees, the disagreement is the finding.PROCEDURE STATED
Methodology, versioned
version v1.0last changed 2026-08-0114 metrics · 3 instruments
The Feed & Execution suite measures the layer most traders are told to trust and never shown: the broker’s published quote stream, the microstructure underneath it, and what execution against that stream actually cost. Its instruments treat a broker feed as a measurable object — inter-tick cadence, two-sided coordination, per-side staleness, spread regimes, freeze and rollover behaviour — and extend the same discipline to the subscriber’s own fills.
Retail feeds are evaluated today by reputation and screenshots. Neither is a measurement. This suite exists so that "what does your broker’s feed actually do" has a distributional answer with a published method behind it, instead of an opinion.
Every metric below carries five fields, because four of them are the fields a methodology usually leaves out. Definition states what the quantity is, closely enough that a stranger could implement it. Estimator states how it is computed and which parameters must be fixed before the data is read. Known failure modes states where the estimator breaks — written now, while nothing depends on it, rather than conceded later under questioning.Does not establish states the claim the metric will not support, however natural the reading. The last field is the one that costs something to publish, which is why it is published.
The feed fidelity battery run against a subscriber’s own broker feed, treating the published quote stream as a measurable object rather than a trusted one.
P1.1Publication cadence
- Definition
- The distribution of intervals between consecutive quote updates on the feed as it arrives at the subscriber, reported as a floor and a set of percentiles rather than as a mean.
- Estimator
- The empirical distribution of inter-tick intervals. The floor is taken at a low-order percentile of that distribution, and percentiles are reported conditioned on trading session; both the percentile and the session partition are fixed in the registration before the sample is read.
- Known failure modes
- A thin session, a transport interruption, or a platform-side buffer can each impose a cadence floor that is not the broker’s. Timestamp resolution coarser than the true tick rate censors the left tail of the distribution entirely, and the censoring is invisible in the result unless the resolution is published with it.
- Does not establish
- A cadence floor does not establish sampling, throttling, or intent. It establishes that on this path, in this sample, updates did not arrive faster than the measured floor.
P1.2Two-sided coordination
- Definition
- Whether bid and ask update jointly or independently, expressed as the co-occurrence structure of the two sides within the feed’s own cadence window.
- Estimator
- The rate of same-window updates on both sides, compared against the rate expected if the sides updated independently at their observed marginal rates. The window is a registered parameter.
- Known failure modes
- The window sets the answer: too wide and independent sides read as coordinated, too narrow and coordinated sides read as independent. A window chosen after seeing the ratio is not a measurement, which is why it is declared in advance.
- Does not establish
- Coordination is a structural description of the quote stream. It does not establish how the price was formed, nor that anyone chose to move both sides together.
P1.3Per-side staleness
- Definition
- The age of each side of the quote at every observed tick — how long the displayed bid, and separately the ask, has stood unchanged — kept as a distribution rather than collapsed to an average.
- Estimator
- Per-tick elapsed time since that side last changed, accumulated into a distribution and conditioned on session and on declared event windows.
- Known failure modes
- Staleness is measured against arrival time on the subscriber’s machine, so a stalled connection and a stalled feed are the same shape unless transport gaps are recorded separately and removed under the registered rule.
- Does not establish
- Concentrated staleness does not establish that a quote was unavailable in the market — only that this feed did not publish a new one for that interval.
P1.4Spread regimes
- Definition
- Contiguous intervals over which the bid-ask spread series is statistically homogeneous, each with a start, an end, and the session context it fell in.
- Estimator
- Change-point detection on the spread series under a penalty fixed in the registration. Segment boundaries are the detected change points; each regime reports its own spread distribution and its own length.
- Known failure modes
- Change-point methods find boundaries in any series, including pure noise. A penalty calibrated against the wrong null over-segments a quiet feed and under-segments a volatile one, and the segmentation looks equally confident either way.
- Does not establish
- A regime boundary is a statement about the series. It does not establish a cause, an event, or a decision by anyone.
P1.5Freeze and rollover behaviour
- Definition
- Intervals in which the feed publishes nothing at all, and the feed’s behaviour across contract boundaries: how long the gaps run, how often they occur, and where in the session they fall.
- Estimator
- Gap detection on the arrival series combined with quote-age analysis across the boundary window. Each gap is recorded with its duration, its session position, and the prints either side of it.
- Known failure modes
- Scheduled closures, subscriber-side disconnections and genuine publication freezes are indistinguishable in an arrival series unless the session calendar and the transport state are carried with the sample.
- Does not establish
- A freeze does not establish that trading was unavailable, nor that prices were withheld. It establishes an interval in which this feed published nothing.
Standing limit. Where a sample cannot support a dimension, the battery publishes the honest null — "insufficient ticks in sample" is a result, not a failure, and it prints as one.
Full instrument page →
Transaction-cost analysis computed from the subscriber’s own imported statements — what execution actually cost, fill by fill, measured against the quote conditions running at that instant.
P9.1Slippage distribution
- Definition
- The signed difference between the price a fill executed at and the price of record at the moment the order was committed, kept per fill as a distribution.
- Estimator
- Per-fill signed differences taken from imported statement records and matched against the quote of record at the fill timestamp; reported as a distribution with its sample size, never as a mean alone.
- Known failure modes
- Statement timestamp resolution bounds the match. A broker reporting fills to the second cannot support a match against a feed that updates faster, and the report names that limit rather than interpolating across it.
- Does not establish
- A distribution that leans against the subscriber does not establish misconduct, adverse routing, or that another venue would have filled better.
P9.2Spread-regime context at execution
- Definition
- The spread regime that was running at the instant each fill executed, attached to that fill so realized costs sort by regime instead of pooling into one figure that describes no regime.
- Estimator
- Each fill is assigned to the regime segment containing its timestamp, using the same change-point segmentation the feed battery produces, under the same registered penalty.
- Known failure modes
- Fills landing on a regime boundary are ambiguous by construction. The boundary-assignment rule is declared in advance and boundary fills are counted separately rather than absorbed into whichever side is convenient.
- Does not establish
- Cost concentrated in one regime does not establish that the regime caused it — the trader’s own behaviour may concentrate in the same regime.
P9.3Session-timing structure of cost
- Definition
- Where realized cost concentrates across the trading day: the rollover window, the thin hour, the overlap.
- Estimator
- Cost aggregated into session buckets fixed before the statements are read, each bucket publishing its own fill count beside its figure.
- Known failure modes
- A subscriber who trades one hour a day produces buckets that are empty everywhere else. Comparisons across buckets with very different sample sizes are reported with intervals rather than as a ranking.
- Does not establish
- It does not establish a better hour to trade. It describes when this account’s costs occurred.
P9.4Cost against the quote of record
- Definition
- What each fill cost relative to the price that was published to this subscriber, rather than to a consolidated tape the subscriber never received.
- Estimator
- The difference between fill price and the subscriber’s own archived quote of record at the fill timestamp, using the feed the account was actually quoted on.
- Known failure modes
- If the quote of record was not archived at the time of the fill, this figure cannot be computed retrospectively. It is then reported as uncomputable rather than reconstructed from a later source that the subscriber never saw.
- Does not establish
- It does not establish a best-execution benchmark. There is no counterfactual venue anywhere in this measurement.
P9.5Effective sample
- Definition
- The number of fills behind every published figure on this instrument, printed on the figure rather than in a footnote.
- Estimator
- A direct count of matched fills after the registered exclusion rules have been applied. The counts before and after exclusion are both published.
- Known failure modes
- The count is only as honest as the exclusion rule that produced it, and an exclusion rule chosen after seeing the data can manufacture any sample. The rule is therefore fixed in the pre-registration, not in the analysis.
- Does not establish
- A large sample does not establish representativeness. It establishes only how many fills entered the estimate.
Standing limit. It measures the subscriber’s own executions from their own records. It does not estimate a hypothetical best execution and does not assert broker intent.
Full instrument page →
Per-pair descriptive microstructure analytics, bundled inside the Broker Feed Auditor subscription and never sold standalone — because estimates computed on an unaudited feed inherit every defect of that feed.
P6.1Realized volatility, modelled
- Definition
- Realized variance aggregated over short, medium and long horizons and entered into a single heterogeneous-autoregressive model of the realized-variance cascade.
- Estimator
- HAR-RV fitted over the realized-variance cascade, with out-of-sample skill computed on data held out of the fit and published beside every fitted figure rather than assumed.
- Known failure modes
- Realized variance is sensitive to sampling frequency and to microstructure noise; on an unaudited feed the estimate describes the vendor’s artifacts rather than the market. Out-of-sample skill degrades silently whenever the holdout overlaps the fit window.
- Does not establish
- A fitted volatility model does not establish a forecast worth acting on. The out-of-sample figure printed beside it is the whole of what the model has earned.
P6.2Jump and liquidation share
- Definition
- The decomposition of total variation into its continuous part and its jump part, reported as the share of a pair’s movement that arrives discontinuously.
- Estimator
- Continuous/jump decomposition of realized variation over the sampled return series; the share is the jump component as a fraction of total variation, under a threshold fixed in advance.
- Known failure modes
- The decomposition is threshold-dependent, and a threshold set on a noisy or sampled feed misclassifies microstructure noise as jumps. Overnight gaps and session boundaries inflate the jump share unless removed by a declared rule.
- Does not establish
- A high jump share does not establish forced flow, liquidation, or any cause at all. It establishes the shape of realized variation over the sample.
P6.3Transaction-cost proxies
- Definition
- Spread- and impact-based estimates of what trading a pair costs, computed from the quote stream itself rather than from executions.
- Estimator
- Quote-derived spread and impact proxies computed per pair and reported per session, each carrying its own definition beside the value so two proxies are never silently compared.
- Known failure modes
- A proxy computed from quotes is not a fill. Where the feed’s quotes are unrepresentative of the prices actually available, the proxy inherits that error and gives no signal that it has.
- Does not establish
- A cost proxy does not establish what a subscriber paid. That question belongs to the Execution Cost Auditor, which measures fills rather than quotes.
P6.4Tails and session structure
- Definition
- Tail behaviour of the return distribution, and how every other quantity on this instrument changes when conditioned on trading session.
- Estimator
- Session-conditioned empirical distributions with tail quantiles reported per session and never pooled across sessions, since the same pair in two sessions is two different objects.
- Known failure modes
- Tail quantiles are the most sample-hungry figures here. A session with few observations yields an interval wide enough to be uninformative, and the interval is published rather than the point estimate alone.
- Does not establish
- Session structure does not establish that a session will behave the same way tomorrow.
Standing limit. Descriptive only. Nothing on this surface is a signal, and the out-of-sample skill of every model publishes beside it — including where that skill is poor.
Full instrument page →
Versioning rule: this page is v1.0. A change to any definition, estimator, failure mode or limit above increments the version and appends an entry to the changelog in §04 naming what changed. Definitions are never edited silently, because a definition that can move after a result is published is not a definition — it is a degree of freedom.
Pre-registrations
A pre-registration is a declaration made and dated before the measurement runs: the thresholds that will decide, the rules that will exclude, and the sample bar below which the honest null publishes instead of a number. Its entire value comes from its ordering. Posted before the answer is known it is a constraint; posted afterwards it is a description of a result, which is a different and much cheaper object wearing the same clothes.
Pre-registration record · Feed & ExecutionNOT YET PUBLISHED
No pre-registration has been posted for the Feed & Execution suite. Not one that is pending review, not one that is drafted and unhashed — none. This block is the structure a registration will occupy, printed empty on purpose, because the alternative is a page that describes a discipline while quietly implying it has already been exercised.
A pre-registration is worth exactly the provability of its ordering. It has to be posted, dated and content-hashed while the answer is still unknown; posted afterwards it is a description of a result, which is a different and much cheaper object. So the first registration cannot be backdated into this slot, and the slot stays visibly empty until one is posted in the only way that counts.
The field schema of a pre-registration record for the Feed & Execution suite: each field, what it will hold, and its current value. Every value reads NOT YET PUBLISHED because no registration exists.| Field | What it will hold | Value |
|---|
registration_ref | The permanent identifier this registration is cited by. | NOT YET PUBLISHED |
|---|
scope | The instruments and the measurement window the declaration binds. | NOT YET PUBLISHED |
|---|
declared_utc | When the declaration was posted — necessarily before any data was touched. | NOT YET PUBLISHED |
|---|
first_data_utc | When collection began. This must fall after the line above, and the ordering is the evidence. | NOT YET PUBLISHED |
|---|
thresholds | Every decision threshold, fixed while the answer was still unknown. | NOT YET PUBLISHED |
|---|
exclusion_rules | What will be dropped from the sample, and on what stated grounds. | NOT YET PUBLISHED |
|---|
completeness_bar | The minimum sample below which the honest null publishes instead of a number. | NOT YET PUBLISHED |
|---|
document_sha256 | The content hash of the registered document itself. Any later edit changes it, visibly. | NOT YET PUBLISHED |
|---|
amendments | Appended corrections, each with its own date and reason. The original text stays. | NOT YET PUBLISHED |
|---|
What a Feed & Execution registration must fix in advance. The lists below are classes of declaration, not declarations. They name the decisions that have to be made before the data is touched, because each one is a decision that could otherwise be made afterwards, in the direction that flatters the result. No value below has been registered.
Thresholds
- The percentile taken as the cadence floor, and the session partition it is computed within.
- The co-occurrence window inside which two-sided updates count as joint rather than independent.
- The change-point penalty that fixes how many spread regimes a series is permitted to have.
Exclusion rules
- How scheduled closures are separated from publication freezes, using a session calendar declared before the sample is read.
- How subscriber-side transport gaps are identified and removed — and what is reported when they cannot be.
- Whether the first and last ticks of a session enter the cadence distribution at all.
Completeness bars
- The minimum tick count below which a cadence percentile publishes the honest null instead of a number.
- The minimum number of two-sided updates required before a coordination ratio is reported.
- The minimum segment length below which a detected spread regime is not published as a regime.
Immutability, stated before it is tested. Once a registration is posted it is not edited. If it is wrong, an amendment is appended beneath it carrying its own date and the reason for the change, and the original text stays where it is, readable, above the correction. A registration that quietly improved after the data arrived would be indistinguishable from one that was right all along — which is precisely why the append rule is written here, now, while there is nothing yet to be tempted by.
Amendment rule, stated in advance: a posted registration is never edited. An amendment is appended beneath the original carrying its own date and its reason, and the original text stays above it, readable. This page will show both.
Proof corpus
The corpus is the set of artifacts a published measurement ships with — not a description of them, the artifacts themselves, downloadable, each with the digest that proves you received the bytes I measured and the code tag that produced them. A result whose inputs cannot be downloaded is not a receipt; it is an assertion with better typography.
The corpus for this suite is empty. Every row below is a slot, and every slot is NOT YET PUBLISHED. The table is printed anyway, because a reader should be able to see the exact shape of what will arrive — and because a page that described a corpus without showing how empty it currently is would be making the claim it exists to refuse.
Five columns: artifact, contents, content hash, code tag, download. Scroll sideways if they do not all fit.
Proof corpus for the Feed & Execution suite: the seven artifact classes a published receipt carries, what each will contain, and its current state. Every content hash, code tag and download reads NOT YET PUBLISHED, because no artifact from this suite's proof corpus has been published yet.| Artifact | What it will contain | Content hash | Code tag | Download |
|---|
| Registered methodology document | The versioned document these definitions are taken from, in the exact form it was registered — estimators, parameters, and the limits stated above. | SHA-256NOT YET PUBLISHED | NOT YET PUBLISHED | NOT YET PUBLISHED |
|---|
| Pre-registration record | The dated declaration: thresholds, exclusion rules and completeness bars, plus any amendments appended beneath the original with their reasons. | SHA-256NOT YET PUBLISHED | NOT YET PUBLISHED | NOT YET PUBLISHED |
|---|
| Point-in-time tick archive | The quote stream as published, in arrival order, with transport gaps recorded as gaps rather than closed. One digest per file, plus a manifest digest over the set. | SHA-256NOT YET PUBLISHED | NOT YET PUBLISHED | NOT YET PUBLISHED |
|---|
| Result set | Per-metric results with intervals and effective sample sizes, and the honest nulls wherever a sample could not support a metric. | SHA-256NOT YET PUBLISHED | NOT YET PUBLISHED | NOT YET PUBLISHED |
|---|
| Can-fail proof transcript | For every test in the battery: the planted defect, the refusal that was expected, and the outcome that was observed. | SHA-256NOT YET PUBLISHED | NOT YET PUBLISHED | NOT YET PUBLISHED |
|---|
| Kill-ledger extract | Hypotheses registered against this suite and killed by the data, each with the run that killed it. Published with the same visibility as a registration. | SHA-256NOT YET PUBLISHED | NOT YET PUBLISHED | NOT YET PUBLISHED |
|---|
| Generation code | The tagged commit that produced the result set, with its build receipt. Named here because a result whose code version is unstated cannot be re-run. | SHA-256NOT YET PUBLISHED | NOT YET PUBLISHED | NOT YET PUBLISHED |
|---|
Corpus state, per instrument
Per instrument, so that the emptiness cannot hide behind a suite-level summary.
Changelog
Append-only, dated, written by a person. It records changes to this page — it is not a measurement log, and it will not become one. A correction is a new entry that names the entry it corrects; nothing here is ever edited away, because a changelog you can rewrite is a marketing surface with a monospace font.
2026-08-01 · v1.0
Receipt page established for the Feed & Execution suite, carrying all five parts of the §8.2 anatomy: the versioned methodology with a formal definition, estimator, failure modes and non-claim for each of the 14 metrics its 3 instruments measure; the pre-registration structure with no registration in it; the proof-corpus table with no artifact in it; this changelog; and the independent-recomputation procedure. Supersedes the earlier per-suite methodology summary at this URL, which carried the battery outline without the receipt anatomy. No measurement, pre-registration, artifact or hash accompanies this version — every receipt slot below is empty as a matter of fact, not of omission.
Independent recomputation
Independent recomputation is what makes the rest of the page checkable rather than merely well-written. It is the exact sequence a stranger follows to re-derive a published number from this suite using only artifacts I published — no account, no request, no conversation with me at any point.
Today the procedure terminates at step 1, because no measurement from the Feed & Execution suite has been published and there is no receipt to open. The steps are written now, in the specific form they will take for this suite, precisely so that they exist before the first result does and cannot afterwards be shaped to fit one.
Open the receipt and take its four identifiers.
Every published measurement links a receipt carrying four: the registration reference, the methodology-document digest, the input-manifest digest, and the generation-code tag. If any one is missing, stop — the result is not recomputable and should not be treated as though it were, including by me.
Verify the methodology document against its digest.
Download it, hash it, compare. A mismatch means the method you are about to apply is not the method that was registered, and everything after this step would be measuring a different thing.
Check the ordering before you check anything else.
The registration timestamp must precede the first-data timestamp on the manifest. If it does not, the registration is a description of a result rather than a constraint on one, and no statistic downstream can repair that.
Download the tick archive and verify every digest.
The archive is point-in-time: quotes in the order they arrived, with transport gaps recorded rather than closed. If a file’s bytes do not hash to the manifest value, stop — you are not holding the input that was measured.
Apply the registered exclusion rules yourself, before computing anything.
The session calendar, the transport-gap rule, and the minimum-tick completeness bar. Applying them after computing is a different measurement, and it is the difference that produces most disagreements.
Check out the battery at the code tag on the receipt and run it.
The battery is deterministic: no sampling, no seeds, no wall-clock input. The same archive under the same tag produces the same output every time or the determinism claim is itself falsified.
Recompute the cadence floor, the coordination ratio, the staleness distribution and the spread segmentation.
The floor and the ratio must match to the published precision. Segment boundaries must match exactly — the segmentation is deterministic given the penalty printed on the receipt.
Run the can-fail proof.
Inject the recorded synthetic defect into a copy of the archive and confirm the battery refuses it by name. A battery that passes a planted defect is not measuring anything.
If your number differs, the difference is the finding.
Send it with your inputs and the version you ran. A confirmed discrepancy publishes as a correction appended beside the original — and the original stays exactly where it is, unedited, because the error is the part of the record that proves the discipline is real.
The point of publishing this before there is anything to check: a recomputation procedure written after a result is a procedure written by someone who already knows which steps would be inconvenient.