Reference · development snapshot
Development evidence and source notes
A dated, qualified view of intended architecture, bounded implementation, separate versions and evidence limits. Source snapshot: 5 October 2026.
Source access: curated reference registry. The historical provenance scope and ledger record archival metadata; they do not validate the implementation findings below.
Draft summary · source snapshot dated 5 October 2026. This is a derived explanation of development documentation, not a new specification, a live status feed or an independent validation. The underlying formal contracts and scoped evidence retain authority. The complete architecture is not established as implemented or validated.
Architecture: intended and implemented
Maneuver Calculus supplies behavioral and defensive semantics within the wider maintained world-state system reference architecture. Ten logical components describe responsibilities; six technical layers describe another view of their organization. Neither is a deployed-service inventory or a sequence that every task executes once.
The documented implementation supports a bounded path from source custody and provisional interpretation through compilation and admission to retained world revisions, queries and decision records. Receipt, interpretation, computation and accepted admission are distinct events. A recorded action proposal does not establish that an external action occurred.
Shared meaning, representation and evaluation apply across the flow. Storage, adapters and governance are supporting boundaries. General registries, executable target compilation, operational action execution, semantic migration and hypothetical branching remain broader development goals.
The connected map preserves the canonical reference names. In its component crosswalk, Applications & interaction (L6) has Evaluation and conformance (C10) as its sole direct association. Applications still consume other capabilities through interfaces; adding direct associations would change that reference mapping.
Components: bounded capabilities and limits
Current implementation responsibilities are grouped around native compilation and history, maintained-world ingestion and session management, and queries, projections and decision records. These groups overlap the ten logical reference components; matching names do not prove matching packages or complete delivery.
| Reference responsibility | Documented capability and boundary |
|---|---|
| Semantic registry and environment loader C1 | Pinned contracts and version checks provide a bounded semantic context. A general registry and imported-definition authority are not established. |
| Data model and serialization C2 | Structured records carry provenance and qualifications. Schema validity does not prove truth, admission or a complete semantic type contract. |
| Ingestion and normalization C3 | Source custody and provisional extraction are recorded. Quotation does not establish entailment; arbitrary-source coverage and interpretation faithfulness are not guaranteed. |
| Semantic compiler and reasoner C4 | A finite acyclic native engine computes bounded, qualified consequences. Computation is distinct from admission, and a known native identity-join failure limits conformance. |
| World-state store and runtime C5 | History, snapshots, replay and bounded incremental updates exist. Admission checks the current head before atomically accepting a revision. Custody and computation records can survive rejection; general branching and semantic comparison of revisions are not established. |
| Query and projection C6 | Named projections and bounded retrieval read retained interpretations. General task-preserving reduction and multi-principal confidentiality are not established; a modeled perspective is not disclosure authority. |
| Behavioral and analytical methods C7 | Bounded policy evaluation and comparisons exist. General maneuver composition and hypothetical simulation are not established by the retained implementation evidence. |
| Output compiler and targets C8 | Qualified structured output and summaries exist. This role translates results for a destination; it is distinct from C4’s computation. General executable targets with independent preservation checks are not established. |
| Execution and feedback C9 | Decision records and attributed observations are adjacent capabilities. They do not establish a general governed external-action engine. Attempt, effect, telemetry and detection remain separate observations. |
| Evaluation and conformance C10 | Retained checks and independent probes support scoped findings. Evaluation spans all six layers; no whole-system conformance claim follows. |
These are explanatory summaries of documented boundaries, not a fresh execution report. General action feedback, full source-withdrawal mapping and semantic migration still require separate contracts and evidence.
Baseline: independently versioned parts
The specification, ontology, native implementation and maintained-world integration have separate identities. A version label does not establish universal compatibility, conformance or release readiness.
| Part | Selected snapshot and qualification |
|---|---|
| Formal foundation | MC-SPEC 0.4.20 and ontology mc-core 0.4.20.2. The ontology’s archival deposit stamp and DOI remain pending. |
| Native compiler | Native core 1.0.1, frozen admission contract 0.2.0 and visibility package 1.0.1. This bounded implementation does not execute the ontology’s RDF rules or implement the whole specification. |
| Maintained-world integration | v025 is primary in the selected development snapshot. Its retained experiments do not establish general practical advantage. |
| Candidate integration | v026 is prepared and unpromoted. Focused candidate probes do not establish broad repair or justify promotion. |
Known conformance failures and incomplete release assurance qualify this baseline. The larger world-state system design remains in development; no unified complete world-state system release is established. See Roadmap: current state for the site’s status orientation.
Evidence: what the findings support
Retained tests, static inspection and experiments establish different things. A test definition is not a run; a historical pass applies to its recorded conditions. Reproducibility and artifact integrity do not by themselves establish semantic correctness. Neither these notes nor the documentation refresh performed a new semantic test.
Three established failures remain material:
- Ontology temporal/context handling: named RDF consumers can use evidence outside its applicable interval or context.
- Native identity joins: missing identity fields can compare equal and wrongly qualify a required join.
- Ontology measured-evidence carriage: constraints do not enforce all required test/date or test/population evidence for measured statuses.
The newer review edition retains the earlier finding dispositions. These failures apply to their named paths; they are not all defects in the native compiler. Historical passes do not erase them, and open broader policy choices do not postpone repair of accepted-contract failures.
Maintained-world experiments retained unsuccessful cases and additional resource cost, so they do not establish a general improvement in decisions. Wider confidence would require independent, representative cases and evidence matching the exact claim. General privacy-preserving projection, task-preserving reduction and complete operational action execution remain unestablished.
Proposed follow-up checks remain distinct from executed evidence. The stronger policy for a single coherent support witness is still open; the existing contract permits separate support-dimension summaries. This summary does not select a stronger policy or redefine a failure.
Staged tests: selected blank masters
These six stages organize planned evaluation. Not run below describes the blank master records, not the absence of every historical MC experiment. Each actual run must retain its own case, version, evidence and verdict. The five architecture workflows and the historical S1–S6 tabletop scenarios are separate from these stages.
| Stage | Purpose | Snapshot state |
|---|---|---|
| T1 — Complete Controlled Case | Use a complete report, synthetic telemetry and real rule baseline/retest execution. | Not run |
| T2 — Missing Evidence | Identify a decisive gap, request evidence and use only what is returned. | Not run |
| T3 — Meaningful Choice | Select a report-supported validation path and explain rejected alternatives. | Not run |
| T4 — Changed Premise | Update affected conclusions while preserving unaffected reasoning and history. | Not run |
| T5 — Live Execution | Use authorized lab evidence, separating execution, effect, telemetry and detection. | Not run |
| T6 — Transfer and Practical Value | Test an independent case, a fresh-consumer handoff and a fair ordinary-workflow comparison. | Not run |
Stage ordering and accumulation, some no-change and unavailable-evidence cases, and practical-value thresholds remain unresolved. This summary supplies no new rubric, threshold, score or result. Template selection is not capability validation.