What does knowability bar mean in market structure detection?

Rule S9: every emitted event carries the bar where it became knowable; no event uses information from any later bar and no event is ever revised once emitted.

What was the delivery contract for this project?

Fixed price via escrow, released when all three checkpoint reviews passed, the provided fixtures and held-out data passed, and the code read clean. Work-for-hire with no portfolio disclosure of the client.

Market Structure Detection Engine — 14-Rule Spec, Executed Exactly

Q: How do you guarantee streaming and batch stay identical?

Batch mode is a literal replay of the streaming engine over the fixture — one rule interpreter, one code path, so there is no drift by construction.

A private research group supplied an exact 14-rule specification (S1–S14) for detecting candidate pivots and confirmed structure highs/lows on OHLCV data. This is what exact implementation looked like.

August 30, 2026 | 13 min read

What the Specification Actually Asked For

The brief was deliberately precise. Two event streams from OHLCV candles: (1) candidate pivot points from a candle-counting rule, and (2) confirmed structure highs/lows, where a level is only confirmed when price revisits the prior extreme — labeled HH/HL/LH/LL. No trading logic, no exchange connections, no UI. Rules were already defined; the job was implementing them exactly.

The requirements carried three hard constraints that make this project genuinely difficult, and they were tested on data the developer never sees:

Batch ≡ streaming: run(bars) and on_bar(bar) must produce identical output.
Never revise: an emitted event is emitted once, at the bar where it becomes knowable, and never changed.
Rule-cited code: every rule ID appears in a comment at its implementation site and in at least one test name.

The Hard Part: Knowability and Append-Only Events

A streaming engine cannot guess. When the 3rd bar of a counter-run appears, the candidate pivot becomes knowable — its price and index can then be computed (S8 anchoring), but only from data up to and including that forming bar (S9). Divergence risk between batch and streaming is the classic failure mode of this spec, so the architecture is deliberately boring:

structure.py — core design

class MStructure:
    """14-rule market structure module (S1S14).

    ONE decision path. batch() IS a replay of on_bar().
    Events are appended to self.events and never mutated.
    """
    def on_bar(self, bar):
        # S1 inside-bar filter -> S2 direction -> S3 progress
        # S4 inside_ref (mother|previous) -> S5 doji (break|skip)
        # S6 qualification at min_run -> S7 candidate formation
        # S8 anchor to extreme <= forming bar -> S9 knowability
        # S10 revisit confirmation pairs level+intervening extreme
        # S11 touch (wick|close) -> S12 supersede, never revise
        # S13 standing levels -> S14 label HH/HL/LH/LL
        ...
        return  # never raises, never recalls prior output

    def run(self, bars):
        for bar in bars:
            self.on_bar(bar)   # batch = replay of streaming
        return self.events

Because batch mode is literally a replay of the streaming entry point, there is no second code path to drift. The event append-only rule is enforced at the emission point (S9), not by convention.

Checkpoint Flow: Three Reviews, Three Chart Artifacts

The spec required milestone gates: work level by level (L1, L2, L3 datasets), and at each completed level stop, send 3 chart examples of detected pivots and confirmed structure drawn on the data, and wait for review. This process is what makes a spec like this safe to build — misreadings of the rule get caught in days instead of at acceptance.

The rendered checkpoint chart below is the L1 artifact format:

Market structure L1 checkpoint chart with candidate pivots, confirmed structure zones and revisit labels

What the reviewer sees: green/red candles, candidate pivots (amber highs, purple lows) pinned at their exact knowability bars, blue confirmed-structure zones annotated with the revisit bar and touch type, and a left-stream event log proving no event was ever revised.

The Rule Map Delivered With the Code

Each rule was implemented at a single site, commented with its rule ID, and covered by a named pytest:

Rule	Essence
S1–S2	Inside bars excluded from run counting; body direction classifies runs
S3–S5	Progress on close; non-progress restarts run at 1; doji break/skip configurable
S6–S7	Run qualifies at min_run=2; opposing qualified run forms the candidate
S8–S9	Anchor to extreme traded price ≤ forming bar; every event carries knowability bar
S10–S12	Revisit confirms level + intervening extreme; exceeded candidates superseded, confirmed structure never revoked
S13–S14	Standing levels persist until next revisit; labels HH/HL/LH/LL vs prior same-side

Edge Cases in the Test Suite (Per Spec)

Flat (zero-range) bars and equal highs/lows
Doji chains and inside-bar chains (S1, S5)
Series start before any run qualifies (S6)
A revisit occurring on the same bar that sets the intervening extreme (S10/S12)
Multiple candidates forming before any revisit confirms (S7)
Batch ≡ streaming equivalence on held-out data — the acceptance test

Every test name contains its rule ID, so a reviewer can grep the suite and see exactly what behavior was verified — the same discipline we apply when we build custom MT5 Expert Advisors and the quant engines behind our statistical arbitrage tools.

FAQ

How do you guarantee streaming and batch stay identical?

Batch mode is not parallel logic — it is a literal replay of the streaming engine over the fixture. One rule interpreter, one code path, no drift by construction.

What does "knowability bar" mean?

Rule S9: every event carries the bar where it first became observable. No event may use information from any later bar, and no event is ever revised once emitted.

What was the delivery contract?

Fixed price via escrow, released when all three checkpoint reviews passed, fixtures and held-out data passed (batch ≡ streaming included), and the code read clean. One round of spec-divergence fixes included. Work-for-hire, no portfolio disclosure of the client.

Have a Spec on Your Desk?

Rules in, verified engineering out. See the full case study portfolio, or send your own spec for a fixed-price quote.

Read the Full Case Study Request a Quote