Skip to content

Commit b4404b0

Browse files
github-actions[bot]github-actions[bot]
committed
Deployed b78c8a8 to 0.1.0 with MkDocs 1.6.1 and mike 2.1.3
1 parent 1cc3027 commit b4404b0

9 files changed

Lines changed: 316 additions & 42 deletions

File tree

‎0.1.0/00-guides/terminology/index.html‎

Lines changed: 0 additions & 30 deletions
Original file line numberDiff line numberDiff line change
@@ -952,28 +952,6 @@
952952
</span>
953953
</a>
954954

955-
</li>
956-
957-
<li class="md-nav__item">
958-
<a href="#flow" class="md-nav__link">
959-
<span class="md-ellipsis">
960-
961-
Flow
962-
963-
</span>
964-
</a>
965-
966-
</li>
967-
968-
<li class="md-nav__item">
969-
<a href="#pipeline" class="md-nav__link">
970-
<span class="md-ellipsis">
971-
972-
Pipeline
973-
974-
</span>
975-
</a>
976-
977955
</li>
978956

979957
</ul>
@@ -4825,14 +4803,6 @@ <h2 id="analysis">Analysis</h2>
48254803
<hr />
48264804
<h2 id="canonical-storage">Canonical Storage</h2>
48274805
<p><strong>Canonical Storage</strong> is the specialized, persistent, and authoritative storage layer for datasets (validated, promoted data) used across Stacks. It is not the Runtime Event Stream; replay and State reconstruction are defined from Events, not from storage alone.</p>
4828-
<hr />
4829-
<h2 id="flow">Flow</h2>
4830-
<p>A <strong>Flow</strong> is a narrative or diagram of how information moves between parts of the infrastructure. Flows are explanatory; <strong>Processing Order</strong> and the Event Stream are normative for causality.</p>
4831-
<hr />
4832-
<h2 id="pipeline">Pipeline</h2>
4833-
<p>A <strong>Pipeline</strong> is a staged description of processing. For example, the <strong>intent pipeline</strong> is a documented staging of</p>
4834-
<p><strong>Strategy ➝ Risk ➝ Queue ➝ Adapter</strong>.</p>
4835-
<p>Stages map to the Core semantics defined in this document, not to separate sources of truth.</p>
48364806

48374807

48384808

‎0.1.0/10-architecture/physical-architecture/index.html‎

Lines changed: 4 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -4580,13 +4580,15 @@ <h2 id="data-storage">Data Storage</h2>
45804580
<li>Operational logs and telemetry</li>
45814581
</ul>
45824582
<p>A typical storage layout:</p>
4583-
<p><code>data/
4583+
<pre class="code-wrap">data/
45844584
├─ raw/
45854585
├─ normalized/
45864586
├─ canonical/
45874587
├─ derived/
45884588
├─ quarantine/
4589-
└─ experiments/</code></p>
4589+
└─ experiments/
4590+
</pre>
4591+
45904592
<p>The <code>canonical/</code> layer holds promoted validated market data used by Backtesting as its Event Stream input for historical Market Events.</p>
45914593
<hr />
45924594
<h2 id="market-data-pipeline">Market data pipeline</h2>

‎0.1.0/20-concepts/order-lifecycle/index.html‎

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -4340,6 +4340,14 @@ <h1 id="order-lifecycle">Order Lifecycle</h1>
43404340
<hr />
43414341
<h2 id="purpose-and-scope">Purpose and scope</h2>
43424342
<p>This document defines the <strong>lifecycle of Orders only</strong>: how an <strong>Order</strong> evolves as a <strong>derived entity</strong> in <strong>Execution State</strong> from <strong>submission</strong> (<code>Submitted</code>) through <strong>terminal disposition</strong>.</p>
4343+
<p>Core baseline mapping note:</p>
4344+
<ul>
4345+
<li>The current Core baseline includes explicit canonical terminal Event coverage
4346+
for <code>Cancelled</code>, <code>Rejected</code>, and <code>Expired</code> outcomes through
4347+
<code>OrderCanceledEvent</code>, <code>OrderRejectedEvent</code>, and <code>OrderExpiredEvent</code>.</li>
4348+
<li>The conceptual <code>Accepted</code> stage remains part of the lifecycle model, but no
4349+
dedicated <code>OrderAcceptedEvent</code> is added in this baseline slice.</li>
4350+
</ul>
43434351
<p>It specifies <strong>lifecycle stages</strong>, <strong>valid transitions</strong>, and <strong>terminal states</strong>. It does <strong>not</strong>:</p>
43444352
<ul>
43454353
<li>define <strong>Intent</strong> lifecycle (<a href="../intent-lifecycle/">Intent Lifecycle</a>);</li>

‎0.1.0/50-evolution/dev-logs/execution-control/introducing-control-time-events-for-execution-control/index.html‎

Lines changed: 96 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -4334,6 +4334,56 @@
43344334
</ul>
43354335
</nav>
43364336

4337+
</li>
4338+
4339+
<li class="md-nav__item">
4340+
<a href="#iteration-5-runtime-ordering-evidence" class="md-nav__link">
4341+
<span class="md-ellipsis">
4342+
4343+
Iteration 5 – Runtime ordering evidence
4344+
4345+
</span>
4346+
</a>
4347+
4348+
</li>
4349+
4350+
<li class="md-nav__item">
4351+
<a href="#iteration-6-structured-control-scheduling-obligation-boundary" class="md-nav__link">
4352+
<span class="md-ellipsis">
4353+
4354+
Iteration 6 – Structured Control Scheduling Obligation boundary
4355+
4356+
</span>
4357+
</a>
4358+
4359+
</li>
4360+
4361+
<li class="md-nav__item">
4362+
<a href="#iteration-7-single-pending-obligation-semantics" class="md-nav__link">
4363+
<span class="md-ellipsis">
4364+
4365+
Iteration 7 – Single pending obligation semantics
4366+
4367+
</span>
4368+
</a>
4369+
4370+
<nav class="md-nav" aria-label="Iteration 7 – Single pending obligation semantics">
4371+
<ul class="md-nav__list">
4372+
4373+
<li class="md-nav__item">
4374+
<a href="#remaining-transitional-deferred-items" class="md-nav__link">
4375+
<span class="md-ellipsis">
4376+
4377+
Remaining transitional / deferred items
4378+
4379+
</span>
4380+
</a>
4381+
4382+
</li>
4383+
4384+
</ul>
4385+
</nav>
4386+
43374387
</li>
43384388

43394389
<li class="md-nav__item">
@@ -4552,6 +4602,52 @@ <h3 id="outcome_1">Outcome</h3>
45524602
</ul>
45534603
<p>while also removing unnecessary dependence on external Market or Execution Events for future Queue re-evaluation.</p>
45544604
<hr />
4605+
<h2 id="iteration-5-runtime-ordering-evidence">Iteration 5 – Runtime ordering evidence</h2>
4606+
<p>The Runtime ordering semantics for realized deadlines are now explicit and validated in the current Backtesting Runtime slice:</p>
4607+
<ul>
4608+
<li>A realized scheduled deadline results in injection of a canonical <strong>Control-Time Event</strong>.</li>
4609+
<li>The Runtime processes the canonical <strong>Control-Time Event</strong> <strong>before</strong> performing any deadline-caused queued-intent pop / flush behavior.</li>
4610+
<li>If canonical processing of the injected <strong>Control-Time Event</strong> fails, the Runtime does <strong>not</strong> pop queued intents and does <strong>not</strong> mark the deadline as successfully injected.</li>
4611+
<li>A previously injected deadline does not cause repeated queue pops without a new canonical injection.</li>
4612+
</ul>
4613+
<p>This ordering improves causality and failure atomicity for the transitional Runtime-owned queue-pop step. It does <strong>not</strong> imply full Core-owned Queue Processing or a finalized Execution Control scheduling model.</p>
4614+
<hr />
4615+
<h2 id="iteration-6-structured-control-scheduling-obligation-boundary">Iteration 6 – Structured Control Scheduling Obligation boundary</h2>
4616+
<p>The boundary between non-canonical scheduling intent and canonical control-time history is now structured:</p>
4617+
<ul>
4618+
<li>A <strong>Control Scheduling Obligation</strong> is a <strong>non-canonical</strong>, runtime-facing scheduling instruction derived from current State + Configuration.</li>
4619+
<li>Obligations are structured data (e.g. include due time and audit metadata) and remain explicitly <strong>not</strong> part of the Event Stream.</li>
4620+
<li>The compatibility gate decision contract (<code>GateDecision</code>) can carry structured Control Scheduling Obligations.</li>
4621+
<li><code>next_send_ts_ns_local</code> remains a <strong>compatibility timestamp</strong> (mirror / scalar fallback) for wakeup scheduling; it is not the semantic canonical form of scheduling.</li>
4622+
<li>The Runtime may map obligation metadata into existing <strong>Control-Time Event</strong> audit fields when injecting the canonical Event.</li>
4623+
<li>A Control Scheduling Obligation never enters <code>EventStreamEntry</code>; only the injected canonical <strong>Control-Time Event</strong> does.</li>
4624+
</ul>
4625+
<hr />
4626+
<h2 id="iteration-7-single-pending-obligation-semantics">Iteration 7 – Single pending obligation semantics</h2>
4627+
<p>The current transitional Runtime slice now treats Control Scheduling Obligations with a <strong>single pending</strong> lifecycle:</p>
4628+
<ul>
4629+
<li>The Runtime maintains <strong>exactly one</strong> pending <strong>Control Scheduling Obligation</strong> (or <code>None</code>) as the current complete future control-time need.</li>
4630+
<li>The pending obligation is <strong>runtime-facing</strong> and <strong>non-canonical</strong>. It does not mutate State and does not enter the Event Stream.</li>
4631+
<li><strong>Latest consumed decision output wins:</strong></li>
4632+
<li>if a consumed gate decision emits an effective obligation, the Runtime sets/replaces/keeps the pending obligation;</li>
4633+
<li>if it emits no obligation, the Runtime clears the pending obligation (subject to the scalar fallback described below).</li>
4634+
<li>If multiple obligations are emitted in a single consumed decision, the current Runtime slice collapses them deterministically by:</li>
4635+
<li>minimum <code>due_ts_ns_local</code>, then</li>
4636+
<li>minimum <code>obligation_key</code> lexicographically.</li>
4637+
<li><strong>Realization:</strong> if the pending obligation reaches due time before a later consumed decision replaces or clears it, the Runtime injects <strong>one</strong> canonical <strong>Control-Time Event</strong> derived from that pending obligation.</li>
4638+
<li><strong>Success path:</strong> after successful canonical processing of the injected Control-Time Event, the Runtime consumes the pending obligation and clears the compatibility mirror <strong>before</strong> performing the transitional queue pop / gate re-evaluation.</li>
4639+
<li><strong>Failure path:</strong> if canonical processing fails, the pending obligation remains and the Runtime does not pop queued intents.</li>
4640+
</ul>
4641+
<h3 id="remaining-transitional-deferred-items">Remaining transitional / deferred items</h3>
4642+
<p>The following items remain explicitly transitional or deferred in the current slice:</p>
4643+
<ul>
4644+
<li>Core-side reducer behavior for Control-Time Events remains minimal / no-op.</li>
4645+
<li>Deadline-caused queue pop remains Runtime-owned (sequenced after canonical processing as above).</li>
4646+
<li><code>next_send_ts_ns_local</code> remains as a compatibility mirror / scalar fallback.</li>
4647+
<li>Strict “clear on every canonical pass” semantics remain deferred when no gate decision is produced.</li>
4648+
<li>Full Core-owned Queue Processing / queue re-evaluation remains deferred.</li>
4649+
</ul>
4650+
<hr />
45554651
<h2 id="open-questions">Open Questions</h2>
45564652
<ul>
45574653
<li>What is the exact canonical shape of a Control-Time Event?</li>

‎0.1.0/50-evolution/milestones/index.html‎

Lines changed: 113 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -4082,14 +4082,75 @@
40824082
</li>
40834083

40844084
<li class="md-nav__item">
4085-
<a href="#current-position" class="md-nav__link">
4085+
<a href="#april-2026-present" class="md-nav__link">
40864086
<span class="md-ellipsis">
40874087

4088-
Current Position
4088+
April 2026 – Present
4089+
4090+
</span>
4091+
</a>
4092+
4093+
<nav class="md-nav" aria-label="April 2026 – Present">
4094+
<ul class="md-nav__list">
4095+
4096+
<li class="md-nav__item">
4097+
<a href="#core-semantic-milestone" class="md-nav__link">
4098+
<span class="md-ellipsis">
4099+
4100+
Core semantic milestone
4101+
4102+
</span>
4103+
</a>
4104+
4105+
</li>
4106+
4107+
<li class="md-nav__item">
4108+
<a href="#core-runtime-alignment" class="md-nav__link">
4109+
<span class="md-ellipsis">
4110+
4111+
Core Runtime alignment
4112+
4113+
</span>
4114+
</a>
4115+
4116+
</li>
4117+
4118+
<li class="md-nav__item">
4119+
<a href="#packaging-deployment-validation" class="md-nav__link">
4120+
<span class="md-ellipsis">
4121+
4122+
Packaging / deployment validation
4123+
4124+
</span>
4125+
</a>
4126+
4127+
</li>
4128+
4129+
<li class="md-nav__item">
4130+
<a href="#control-time-obligation-semantics-transitional-implementation-track" class="md-nav__link">
4131+
<span class="md-ellipsis">
4132+
4133+
Control-Time obligation semantics (transitional implementation track)
4134+
4135+
</span>
4136+
</a>
4137+
4138+
</li>
4139+
4140+
<li class="md-nav__item">
4141+
<a href="#explicit-deferred-capabilities" class="md-nav__link">
4142+
<span class="md-ellipsis">
4143+
4144+
Explicit deferred capabilities
40894145

40904146
</span>
40914147
</a>
40924148

4149+
</li>
4150+
4151+
</ul>
4152+
</nav>
4153+
40934154
</li>
40944155

40954156
</ul>
@@ -4376,15 +4437,58 @@ <h3 id="canonical-model-consolidation">Canonical Model Consolidation</h3>
43764437
<li>Established a coherent architecture model that can now guide further implementation and documentation work</li>
43774438
</ul>
43784439
<hr />
4379-
<h2 id="current-position">Current Position</h2>
4380-
<p>At this stage, the project has:</p>
4440+
<h2 id="april-2026-present">April 2026 – Present</h2>
4441+
<p>This transitional implementation milestone closes Core and Core Runtime alignment:</p>
4442+
<h3 id="core-semantic-milestone">Core semantic milestone</h3>
4443+
<ul>
4444+
<li>Core import root is <code>tradingchassis_core</code> and the distribution name is <code>tradingchassis-core</code>.</li>
4445+
<li>The Core public canonical processing API is usable and stable for the current slice:</li>
4446+
<li><code>CoreConfiguration</code></li>
4447+
<li><code>ProcessingPosition</code></li>
4448+
<li><code>EventStreamEntry</code></li>
4449+
<li><code>process_event_entry</code></li>
4450+
<li><code>fold_event_stream_entries</code></li>
4451+
<li><code>EventStreamEntry</code> is a minimal envelope containing only:</li>
4452+
<li><code>position</code></li>
4453+
<li><code>event</code></li>
4454+
<li><code>CoreConfiguration</code> is explicit and versioned, with deterministic identity (fingerprinted), and is passed call-level to processing (it is not embedded in <code>EventStreamEntry</code>).</li>
4455+
<li><code>ProcessingPosition</code> defines <strong>Processing Order</strong>. Event Time is carried by Events as external metadata and does <strong>not</strong> define Processing Order.</li>
4456+
</ul>
4457+
<h3 id="core-runtime-alignment">Core Runtime alignment</h3>
4458+
<ul>
4459+
<li>Core Runtime import root is <code>core_runtime</code> and the distribution name is <code>tradingchassis-core-runtime</code>.</li>
4460+
<li>Core Runtime consumes Core (<code>tradingchassis_core</code>) and owns runtime orchestration responsibilities around canonical processing:</li>
4461+
<li>owns a runtime <code>EventStreamCursor</code></li>
4462+
<li>allocates <code>ProcessingPosition</code></li>
4463+
<li>constructs <code>EventStreamEntry</code></li>
4464+
<li>calls <code>process_event_entry(..., configuration=CoreConfiguration)</code></li>
4465+
<li>Local hftbacktest-backed runtime smoke is usable:</li>
4466+
</ul>
4467+
<p><code>python -m core_runtime.local.backtest --config core_runtime/local/local.json</code></p>
4468+
<ul>
4469+
<li>Default local outputs are generated under:</li>
4470+
<li><code>.runtime/local/results/</code></li>
4471+
</ul>
4472+
<h3 id="packaging-deployment-validation">Packaging / deployment validation</h3>
4473+
<ul>
4474+
<li>The Core Runtime Docker image has been validated locally and is intentionally minimal (runtime-only: no tests, no repo checkout).</li>
4475+
<li>Kubernetes / Argo / GHCR execution is a <strong>deployment validation track</strong>, not a claim of full production readiness.</li>
4476+
</ul>
4477+
<h3 id="control-time-obligation-semantics-transitional-implementation-track">Control-Time obligation semantics (transitional implementation track)</h3>
4478+
<ul>
4479+
<li>Phase 16C: Runtime ordering for realized deadlines is explicit: inject/process canonical Control-Time Event before deadline-caused queue pop; failure prevents pop/marker advancement; old deadlines do not repeatedly pop.</li>
4480+
<li>Phase 16F: Structured non-canonical Control Scheduling Obligations are exposed on the gate decision contract; <code>next_send_ts_ns_local</code> remains a compatibility mirror / scalar fallback.</li>
4481+
<li>Phase 16H: Runtime maintains a single pending Control Scheduling Obligation (or <code>None</code>) and collapses multiple obligations deterministically; realization injects one canonical Control-Time Event; success consumes pending before transitional pop; failure preserves pending and prevents pop.</li>
4482+
<li>Still deferred in this track: Core reducer remains minimal/no-op for Control-Time Events; queue pop remains Runtime-owned; strict clear-on-every-canonical-pass remains deferred when no gate decision is produced; full Core-owned Queue Processing remains deferred.</li>
4483+
</ul>
4484+
<h3 id="explicit-deferred-capabilities">Explicit deferred capabilities</h3>
43814485
<ul>
4382-
<li>a defined infrastructure foundation</li>
4383-
<li>a working Core Runtime and Backtesting foundation</li>
4384-
<li>a documented deterministic event-driven architecture model</li>
4385-
<li>a public documentation and repository structure that reflects the infrastructure coherently</li>
4486+
<li>Runtime canonical <code>FillEvent</code> ingress</li>
4487+
<li><code>ExecutionFeedbackRecordSource</code></li>
4488+
<li>full canonical post-submission lifecycle</li>
4489+
<li><code>ProcessingContext</code></li>
4490+
<li>replay/storage / Event Stream persistence</li>
43864491
</ul>
4387-
<p>The next milestones are expected to focus on downstream documentation alignment, additional Runtime refinement, and further maturation.</p>
43884492

43894493

43904494

0 commit comments

Comments
 (0)