Design review: blueprint revision 5 contract amendment

1. Decision and scope

Decision: Accept for the bounded proposed-design scope below. The revised contracts address R4-01–R4-13 and assign a concrete consumer or deferred trigger to L1–L9. Acceptance means the reviewed mechanisms, boundaries and refusal paths are specified. It does not certify their implementation, scientific validity or performance, and does not change any ADR to accepted.

Proposal: blueprint revision 5, ADRs 0039–0048 and their capability-map/register reconciliation. Standard: Data Model–Based Design Charter, gates G1–G7. Author/reviewer: Codex, including review of its own amendment; this is not an independent second-person review. Date: 2026-09-13. Evidence: Proposed architecture, selected Interface-checked library mechanisms and the explicitly bounded historical Tested characterizations in the revision-4 review.

Observable outcome: implementers have one declared route for admitting physical meaning, resolving demand, binding complete stage inputs, handling guarded failures, and preserving content through alternate encodings. Existing Arrow/DataFusion operators perform their standard jobs; domain rules remain in the platform contracts that invoke them.

Method and coverage. Inspected the changed semantic contracts in blueprint §§4–9, 14, 18, 20–21 and 24–26, their declarations in §6, affected decisions and glossary, all new ADRs and their supersession boundaries, and the four capability maps’ current recommendations. Replayed the earlier review’s counterexamples against the proposed rules by inspection. Followed the concrete journeys in §5; checked section/port ownership, membership framing, numerical/failure policy and the implementation handoff. Static validation is recorded in plan 02.

This is a follow-up on the changed contracts. Unchanged thermodynamic correlations, every unit template, the full IDAES coverage matrix, all specialized diagnostics and later-phase solver/provider routes were not re-certified. No product compiler, solver, canonicalizer or Python adapter was implemented or executed by this amendment. The retained probe receipts were not regenerated. Context7 returned broad analyzer/runtime/reader material during reconciliation; the pinned source/probe evidence in the earlier review remains the basis for precise library claims. Unbuilt behavior is outside this acceptance claim, rather than silently being scored as tested.

The reviewed blueprint SHA-256 is 63629cd7221d7083f95b7e39f916cc6a6d3395599a2faadf5674e98c175c1a5b. Dependency pins/features, both lockfiles, the toolchain, charter and original probe source are unchanged; Cargo.toml has only a citation-comment amendment.

Supported limits: local single-writer publication; explicitly admitted Arrow layouts; the row/byte/offset envelope in blueprint §5.3; complete stage input keys; pure contracted kernels; and only numerical/backend routes whose actual implementation and conformance binding is available. Larger canonical streams, finer dependency tracking, Parquet optimization, coalescing and preimages retain register triggers. The design supplies rejection paths for unsupported cases.

2. Authority and lifecycle map

Opaque behavior: specialized kernel bodies, numerical workspaces, solver callbacks and storage I/O remain ordinary code behind the declared contracts. Registration or a function signature cannot supply a missing derivative, conditional implementation or physical conversion.

Renames preserve semantic IDs while changing label-bearing relation content. Row/batch order, supported dictionary encodings and hidden null payload do not change declared logical identity. Changed semantic parents remain visible even when an unchanged relation shares storage; initial reuse does not discard lineage.

3. Semantic contracts and invariants

Missing measurements remain nullable values. Invalid evaluation is a typed error, or a mandatory per-coordinate outcome in the separate tolerant operation; a null alone cannot stand for both. An absent optional input is part of the cache key. An empty required output is explicit, while a failed output is never an empty successful bundle. Unknown/conflicting rule facts remain outside decided heads.

Equivalence is role-specific: canonical content identity, physical checksum integrity, full values/multiplicities for pushed scans, guarded numerical outcomes under the selected absolute/relative/signed-zero policy, and attributable decoded meaning for noncanonical plan evidence. These are not interchangeable tests.

4. Derivation and execution design

The library opportunities are bounded: AnalyzerRule and recursive traversal for admission; built-in CASE for relational guards; physical predicates and Arrow filters for exact scans; standard aggregation/unnesting for P8 and memberships; shared RuntimeEnv/reservation APIs for accountable allocations; field-aware UDF arguments and scalar paths; safe ScalarBuffer owners; and explicit-schema readers for observations. No new query engine or general inversion/ingestion framework is justified. CSV/JSON feature wiring remains part of the future import consumer.

5. Representative journeys

Ordinary extension. A method requiring a second property declares the requirement and implementation/quantity contract. P3/P6 bind the finite scope and candidate set before P9 realization. Its adapters come from the admitted binding; an unavailable derivative or undeclared late dependency is rejected. Extension work is the new declaration, any new algorithm and its focused conformance fixture.

Meaningful change. Add a species, change a unit set, or remove a provider. The domain/package/candidate input changes, so the complete P7/P6-dependent keys change. Fresh output snapshots preserve the new lineage. A fixed-value change refreshes bound_values and any value-dependent analysis/preparation even if the instruction topology is the same. Clean compilation is the equivalence oracle.

Alternate representation. Construct equal nested nullable relations with different hidden payload/child validity and serialize each as IPC file or Parquet. Canonical v2 specifies normalization before logical hashing. Each finished encoding has its own checksum; restore decodes and validates meaning instead of substituting a byte checksum for logical identity. A Python consumer that loses an extension cannot re-enter a checked platform path by silently relabeling storage.

Failure. A mixed batch selects different branches and includes a log-domain error only in an excluded branch. CASE/native masks prevent its evaluation; a selected invalid branch instead returns the declared error/outcome. Cancellation or reservation failure releases owned workspaces and prevents successful stage publication. A truncated existing object fails verification before a new ref can expose it. These are proposed journeys with the named acceptance fixtures in plan 02.

6. Acceptance gates

Each Pass below is Proposed document scope, not runtime assurance.

7. Principle findings

No residual MUST gap was identified in the revised, bounded contract decisions. The table records the decisive corrections, not new assertions that the runtime already enforces them. Verification names are Proposed fixtures in plan 02.

Applicability. All twelve groups bear on these cross-boundary changes, but this review reassesses only the principles listed below and their revised mechanisms. Other principles and unchanged subsystems retain the earlier review’s coverage limits; they are not silently recertified or declared irrelevant. “Satisfied” is a verdict on specified Proposed design, with the boundary and rejection behavior identified above. No numerical maturity score is assigned.

8. Alternatives and architectural leverage

Registry and operation generation are justified by repeated Rust/Python/storage boundaries; typed aggregate/unnest operations have P8/membership consumers. A new distributed service, universal inversion engine, extra dataframe system or automatic dependency framework is not justified by these findings. Canonical normalization, sparse numerical algorithms, masks and buffer ownership remain ordinary typed code, not new DSLs.

9. Verification and measurement plan

The dependency-ordered packets and exact proposed fixtures are in plan 02.

No ordinary full Rust/Python/solver suite can establish unimplemented behavior. Current runs are scoped static/governance checks; future implementation changes must run their actual test/slice recipes. API-reference lint remains deferred under R-20 and is not credited as interface verification.

10. Exceptions and unresolved decisions

No SHOULD deviation is needed for these revised contracts: whole-stage reuse is the smallest currently trustworthy granularity, supported boundaries refuse unavailable behavior, and optional features have explicit triggers. This review does not close unimplemented behavioral acceptance by treating it as an exception.

11. Decision and implementation changes

Accept the revised, bounded Proposed design contracts. All seven gates pass for that document scope. The review does not accept runtime behavior, every unchanged blueprint detail, an ADR status transition or a performance claim.