status: evidence-map blueprint_revision: 5 pins: Cargo.lock regenerated: null reviewed: 2026-09-13

Arrow (Rust) — capability map

Current binding: blueprint revision 5 and ADR-0039–ADR-0048. The inventories and original extraction/probe receipts below retain their historical scope and dates; this update did not regenerate that corpus. Historical comparisons to revision 2 are not current acceptance claims. Corrected interpretations are recorded in place. The current design remains Proposed; pinned library mechanisms are Interface-checked, and only the named characterization experiments are Tested.

[review:E1]–[review:E6] refer to the retained six-group characterization and its conditions: Rust 1.98.1, Arrow 59.3.0, DataFusion 55.1.0, dev, Arrow force_validate, zero failure baseline. The revision-4 review explains the counterexamples; these markers do not certify a platform implementation.

Companion to docs/authoritative_design/blueprint.md and to supporting-rust-libraries.md, which covered the §3.3 supporting crates and deliberately excluded Arrow and DataFusion. The DataFusion half of this pair is datafusion-rust.md. Each map now carries its own principle-alignment register (§11) and its own acceptance-gate review (§12); in the previous edition both lived only in the DataFusion map, which meant neither document could be updated on its own.

Compiled 2026-09-13 against arrow 59.3.0. Historical survey adjudicated blueprint revision 2 (2026-09-13). The previous edition of this map adjudicated revision 1 and never said so; §0.4 lists what revision 2 changed underneath it.

0. Purpose, sourcing constraint, and evidence rules

0.1 What this document is

Per crate cluster: what Arrow can actually do, which of its APIs the blueprint’s stated requirements land on, what we deliberately will not use, and where the blueprint assumes a capability that does not exist or is under-specified. A second pass asks a different question — what does Arrow offer that the blueprint has not claimed, which would improve alignment with design_principles/DATA_MODEL_DESIGN_CHARTER.md (DM-01…DM-60, gates G1–G7)?

0.2 The sourcing constraint, and how it is enforced

This document was written without using any of the repository’s existing Arrow or DataFusion material — not the docs/library_ref/ prose references, not the datafusion-pyarrow-* skills, not the pre-existing build/facts/arrow59-default surface (which is at 59.2.0 and would misrepresent the pin), and not the vendored arrow-rs/ checkout.

Two of those are now moot rather than merely avoided: docs/library_ref/ has been deleted, and the vendored checkouts survive only as orphaned git worktrees under .worktrees/ whose parent repositories are gone, so their tags can no longer be verified. The constraint is now structural as well as chosen.

Everything here comes from four fresh lanes:

The constraint is mechanically checked by counting citations, not mentions: no provenance marker in this document is of the form [ref:…] (the companion map’s marker for local references) and none cites /apache/arrow. Both strings appear in this section and in the evidence ledger, where they record the rule and the rejected candidate respectively — that is the intended behaviour of the check, which greps for the bracketed citation forms. A claim carrying no marker is a defect.

0.3 Status vocabulary

leverage (the library provides it, use it) · build on top (foundation only; platform code required, cost stated) · confirmed (a specific blueprint claim is true as stated) · refined / erratum (claim wrong or imprecise; correction given) · adopt / evaluate / reject (Pass-2 recommendations) · open item (a question this lookup surfaced).

Pass-2 recommendations are disciplined by charter §G (common false positives) and DM-58 (scale architectural machinery to demonstrated needs): a recommendation that names no principle and replaces no identified hand-written code does not appear.

Pass 3 (§10) is new in this edition and answers a third question: taking the complete inventory of the family — every crate, every public trait, every feature flag, every release delta — what is this design not leveraging at all?

0.4 What changed underneath this map, and what it got wrong

The previous edition was compiled at 14:35 on 2026-09-13; the blueprint was rewritten at 15:24. Four things follow.

And one correction to this document’s own earlier reasoning. The previous edition asserted, under A1’s “Gaps and risks” and as register row #8, that because Schema.metadata is a HashMap the canonical IPC encoding is non-reproducible unless the platform sorts metadata keys first. That is wrong for IPC. Measured across six independently constructed schemas carrying 0, 1, 2, 3 and 5 metadata keys, the IPC byte stream was identical every time [probe]. Arrow’s IPC writer does not inherit the HashMap’s iteration order. The concern is real, but it belongs to two other paths — a platform-side fingerprint that iterates the map directly, and datafusion-proto, which does inherit it and is measurably unstable (companion map D9). §2 and §10 carry the corrected finding.

1. Version anchors, pin discipline, and the extraction receipt

1.1 Anchors

1.2 Pin-discipline erratum — §3.1 — resolved in revision 2

Retained as a record of why §3.1 reads as it now does, not as a live recommendation. Revision 2 adopted this finding verbatim, including the cargo tree -d reasoning.

Revision 1 of §3.1 stated the intent well: “arrow, arrow-*, parquet, arrow-flight, arrow-avro | 59.2.0 | One release family; never mix Arrow majors in the graph (cargo tree -d in CI)”. The stated mechanism does not achieve the stated intent.

Resolving a project that pins only the umbrella crate:

arrow        = "=59.2.0"     ->  arrow        59.2.0
                                 arrow-array  59.3.0   <-- floated
                                 arrow-schema 59.3.0   <-- floated

The umbrella depends on arrow-* ^59.2.0, so every sub-crate floats to the newest compatible release. This is not a duplicate, so cargo tree -d does not catch it — it is a silently mixed family, which is what §3.1 says it wants to prevent. The same applies to DataFusion, where the umbrella at 55.0.0 resolves sub-crates at 55.1.0.

Recommended amendment (now applied): pin every crate in both families with =, or commit a Cargo.lock and enforce it in CI. This document’s extraction does both — every crate =-pinned and the resolved Cargo.lock committed under evidence/rust/ — which is why its receipt shows a single version per family. Committing the lockfile is the stronger half and §3.1 still does not require it: = pins bind direct dependencies, but nothing stops a transitive path from pulling a second Arrow version, and only a lockfile plus a CI assertion catches that.

1.3 Feature flags (fresh, from crates.io/docs.rs)

arrow 59.3.0 is an umbrella over required arrow-arith, arrow-array, arrow-buffer, arrow-cast, arrow-data, arrow-ord, arrow-row, arrow-schema, arrow-select, arrow-string, plus optional arrow-csv, arrow-ipc, arrow-json, arrow-pyarrow [docs.rs:arrow@59.3.0].

The complete feature list of the arrow umbrella at 59.3.0, so §10’s E3 enumeration has a stated denominator [gh:apache/arrow-rs@59.3.0/arrow/Cargo.toml]:

1.4 Extraction receipt

rustdoc JSON generated locally from a scratch project with every crate =-pinned, resolved offline from the crates.io mirror, one toolchain:

toolchain       rustc 1.100.0-nightly (809936eac 2026-09-12)
cargo           1.100.0-nightly (7941be6fb 2026-09-11)
flags           -Z unstable-options --output-format json
format_version  61
run             2026-09-13T16:15:24-04:00 .. 16:16:22-04:00
targets         57 requested, 57 OK, 0 FAIL, 60 JSON documents
arrow family    20 crates, every crate_version 59.3.0
                arrow, arrow_arith, arrow_array, arrow_avro, arrow_buffer, arrow_cast,
                arrow_csv, arrow_data, arrow_flight, arrow_ipc, arrow_json, arrow_ord,
                arrow_row, arrow_schema, arrow_select, arrow_string,
                parquet, parquet_variant, parquet_variant_compute, parquet_variant_json
datafusion      37 crates, every crate_version 55.1.0  (companion map)
lockfile        361 packages; one version per family, asserted

This is a substantially wider extraction than the previous edition’s, which covered 13 arrow crates and preserved nothing. Newly covered here: arrow-avro, arrow-csv, arrow-flight, arrow-json, and the three parquet-variant* crates. The normalized form is written to build/facts/arrow593/ — 30,920 declarations, 101 public traits, 18,268 impl relations — alongside, and never overwriting, the older arrow59-default profile at 59.2.0.

Every [rustdoc:…@59.3.0] marker in this document resolves against that extraction.

Committed under docs/capability-maps/evidence/rust/: the extraction manifest (apisurface-Cargo.toml), the resolved apisurface-Cargo.lock, the generation script, the generation log, the five probe programs, and their captured output (probe_output.txt). The lockfile is the part the previous edition lacked — without it “re-derivable” meant “re-resolvable to whatever is current”, which is not the same claim.

1.5 Probe receipt

Measurements in this document come from five programs compiled against the pinned crates. Arrow-side probes 1–5 are unchanged from the previous edition; 6 and 7 are new, and 6 corrects a claim this map previously made (§0.4).

2. Type system, Field, Schema, and metadata (A1)

Role: §4.3 metadata conventions; §4.5 logical type catalog; §4.2’s generated fn schema() -> SchemaRef and the try_from(&RecordBatch) that checks a schema fingerprint.

Capability inventory

What the blueprint binds to

Pass 2 — alignment opportunities not in the blueprint

Gaps and risks

• Fields is an Arc-backed shared slice, so schemas are cheap to clone but shared; RecordBatch::schema_metadata_mut clones on write [c7:/websites/rs_arrow_arrow]. Mutating schema metadata after a batch is built is therefore possible but not free, and it silently diverges the batch’s schema from the registry’s. §4.3 says metadata is “attached by the provider” — that should be read as attached at construction, never patched later.

• Metadata is HashMap<String, String> — unordered — but the IPC writer does not inherit that disorder. This is a correction to the previous edition, which claimed the canonical IPC encoding was non-reproducible for this reason. Measured [probe]:

  PROBE 6  canonical IPC bytes vs number of metadata keys (6 independently built schemas each)
     0 keys: len=312  distinct encodings = 1  STABLE
     1 key : len=416  distinct encodings = 1  STABLE
     2 keys: len=488  distinct encodings = 1  STABLE
     3 keys: len=560  distinct encodings = 1  STABLE
     5 keys: len=704  distinct encodings = 1  STABLE
  

  So §5.3’s content_hash is not at risk from metadata ordering, and the previous edition’s register row #8 overstated the problem. The risk is real but confined to two other paths, and the second one is serious:

  1. Any platform code that fingerprints by iterating metadata() directly — pse.contract.fingerprint as §4.3 describes it — is exposed, because that iteration is the HashMap’s. Sorting there is still required (DM-48).
  2. Protobuf metadata remains unordered. Sorted insertion into field/schema HashMaps does not stabilize datafusion-proto bytes [review:E5]. Blueprint §14.2 now records noncanonical diagnostic encodings outside semantic memo keys (ADR-0044); §5.3 separately canonicalizes metadata for logical relation identity.

• fields_with_dict_id / Field::new_dict(dict_id, …) expose Arrow’s legacy dictionary-id mechanism. §4.5 says “dictionary encoding … never carries identity” — consistent, but the generated code must not set dict_id, and a governance check is cheap.

3. Extension types and the canonical_extension_types feature (A2)

The densest blueprint↔library coupling in the Arrow surface: §4.4 declares ten pse.* extension types and states exactly which Arrow machinery implements them.

This cluster is where DM-06 (“type semantic distinctions, not only machine representations”) is either satisfied or lost. FixedSizeBinary(16) is a machine representation; pse.semantic_id and pse.content_hash are two different semantic types that share it. Arrow’s extension mechanism is the only place in the format where that distinction can be recorded and carried, so everything below is DM-06 infrastructure.

Capability inventory

What the blueprint binds to

Pass 2 — alignment opportunities

Gaps and risks

• Arrow has no extension-type registry — but DataFusion 55.1.0 does, and it changes this cluster’s conclusion. The Arrow trait is per-type and field-local; nothing in arrow-schema maps a name back to an implementation. That much is unchanged. What is new is that datafusion_expr::registry::ExtensionTypeRegistry provides exactly that mapping, keyed on the ARROW:extension:name string, and it is wired into SessionStateBuilder. Measured [probe]:

  PROBE X1  ExtensionTypeRegistry
     canonical types preloaded (7): arrow.timestamp_with_offset, arrow.opaque,
        arrow.fixed_shape_tensor, arrow.uuid, arrow.variable_shape_tensor,
        arrow.bool8, arrow.json
     register pse.semantic_id          -> 8 registrations
     resolve from a good Field         -> storage_type=FixedSizeBinary(16)
     Field with the WRONG storage type -> REJECTED: "pse.semantic_id requires
                                          FixedSizeBinary(16), got Utf8"
     unregistered pse.* name           -> Err("Logical type not found")
  

  Scope correction: X1 invokes create_extension_type_for_field directly; it does not validate query admission. E1 shows malformed and unknown extension fields survive an ordinary SELECT with zero factory calls [review:E1]. Generated recursive admission plus a platform AnalyzerRule supplies the missing boundary (blueprint §4.4).

• Extension-type metadata versioning remains unresolved. An inbound field carrying pse.quantity_value written by a different version of the platform deserializes only if our current Metadata type still parses it. §4.4 has no versioning story — pse.contract.version versions the relation, not the extension type. The registry gives a place to put a resolution rule; it does not supply one. Open item (DM-44, DM-51).

• deserialize_metadata must error on unexpected metadata, not ignore it [docs.rs:arrow-schema@59.2.0]. For the blueprint’s metadata-free types (pse.content_hash, pse.ordinal_ref) the implementation must therefore reject a field that carries an ARROW:extension:metadata key rather than shrug — otherwise two different producers disagree silently.

• pse.ordinal_ref is the weak link in §4.4. Its storage is UInt64 and “metadata names the target relation” — but that target is carried in pse.semantic.fk-style platform metadata, not in the extension’s own Metadata. Making the target relation part of the extension type’s Metadata would let supports_data_type/deserialize_metadata enforce it. Evaluate (DM-09, DM-44).

• has_valid_extension_type returns bool and discards the reason [rustdoc:arrow-schema@59.3.0]; use try_extension_type wherever the failure must become a diagnostic (§23.2).

4. Arrays, buffers, and the zero-copy boundary (A3)

Role: §4.2 generated typed views (StoichiometryView<'a> { reaction_id: &'a FixedSizeBinaryArray, … }) and builders; D11 — “the evaluation program, sparse Jacobian structures, and solver workspaces … borrow Arrow buffers when layouts permit and copy when they do not. Zero-copy is a preference, not an obligation.”

Capability inventory

What the blueprint binds to

Pass 2 — alignment opportunities

Gaps and risks

• Borrow through safe views. PrimitiveArray::values incorporates the logical slice offset. A null-free contiguous one-chunk slice can be borrowed with its owning handle retained; raw base-pointer indexing is invalid. A filter need not produce a nonzero offset. Layout/coercion/multi-chunk cases use checked reserved copies (blueprint §18.2; review L7).
• Nullability: a borrowed Float64Array may carry a validity bitmap. §18.2 treats parameter values as dense f64; borrowing a nullable column without checking null_count() == 0 reads uninitialised slots as data. State the precondition.

5. Null, NaN, and -0.0 — semantic distinctness (A4)

The cluster with the highest gate stakes: G2 — semantic fidelity (“required meaning is ambiguous, silently dropped, reinterpreted, or represented by an indistinguishable sentinel”) and DM-08 (“represent absence, unknowns, uncertainty, invalidity, and failure distinctly”).

Role: §7.6 null/bound/unknown semantics; §4.4’s pse.bound (“explicit bound; never NaN or null sentinels”); §5.3 step 4 (“floats hash as IEEE-754 bits after canonicalizing NaN to the quiet NaN with zero payload; -0.0 is preserved (it is distinguishable and can matter to solvers)”).

Capability inventory

Empirical verification

Run locally against the pinned build (arrow 59.3.0, program and output in the evidence ledger, row 16):

PROBE 2  null vs NaN vs -0.0 after an IPC round-trip
   is_null(1)=true   value(2)=-0   signbit(2)=true

PROBE 3  sort order of [0.0, -0.0, NaN, -1.0, null] with nulls_first
   sorted: ["null", "-1", "-0", "0", "NaN"]

Three facts follow, and all three matter to the blueprint:

1. Null is structurally distinct from NaN and survives serialization. DM-08 and G2 are satisfied by the format, not by convention — there is no sentinel to confuse.
2. -0.0 sorts strictly before +0.0. totalOrder treats them as distinct and ordered, so §5.3’s “-0.0 is preserved” is not merely a hashing choice — Arrow’s own ordering already distinguishes them, and a canonicalisation that collapsed them would contradict the sort.
3. NaN sorts last, after all finite values. Deterministic placement, so §5.3 step 1’s key ordering is well defined even if a NaN reaches a sort column.

What the blueprint binds to

Pass 2 — alignment opportunities

Gaps and risks

• The NaN canonicalisation is ours to implement and is easy to get wrong. Arrow will not do it; f64::to_bits() on a signalling NaN, a negative NaN, or a NaN with a payload gives different bytes. §5.3 step 4 must be a named, tested function applied to every Float64 column before hashing — and it must not be applied to data on the way to a solver, where a NaN’s provenance may matter for diagnostics (§18.2 step 6).
• make_comparator returns Box<dyn Fn(usize, usize) -> Ordering> and does not support nested types; lt/gt likewise state “nested types (e.g. lists) are not supported” [c7:/websites/rs_arrow_arrow]. §4.4’s pse.index_tuple (List<FixedSizeBinary(16)>) therefore cannot be compared or sorted by the ordinary kernels — see the row format in A5, which can. This is a real constraint on §5.3 step 1 that the blueprint does not anticipate.

6. Compute kernels, ordering, and the row format (A5)

Role: §5.3 step 1 (order rows by primary key) and step 2 (concatenate, expand dictionaries); §15.4 numerical checks over Jacobian values; §16 scaling transformations.

Capability inventory

What the blueprint binds to

Pass 2 — alignment opportunities

Gaps and risks

• The arithmetic kernels are checked by default (add errors on overflow; add_wrapping is the opt-in wrapping form) [rustdoc:arrow-arith@59.3.0]. Good default; worth stating so nobody reaches for the wrapping variants to silence an error.
• ArrayFormatter / array_value_to_string exist for display only. They must never appear in a hashing or identity path — string rendering is locale- and option-dependent (FormatOptions).

7. IPC, Parquet, and canonical serialization determinism (A6)

The cluster that decides whether §5.3 — and therefore every content hash, snapshot id, and reproduction claim in the platform — actually holds.

Role: §5.3 canonical serialization and hashing; §20.1 artifact store (.arrow IPC hot artifacts, .parquet durable artifacts); §4.3 “metadata … preserved through IPC/Parquet”.

Capability inventory

Empirical verification — the four facts that matter

Run locally against the pinned build (evidence ledger row 16):

PROBE 1  metadata through an IPC round-trip
   schema md preserved : Some("rel-1")            <- pse.contract.id
   field md preserved  : Some("qt-demo")          <- pse.semantic.quantity_type
   ext name preserved  : Some("pse.semantic_id")  <- ARROW:extension:name

PROBE 4  batch splitting
   1-batch len=872   2-batch len=1080   concat-then-write len=872
   1-batch == 2-batch      : false
   1-batch == concat-first : true

PROBE 5  alignment
   align8 len=872   align64 len=1032   equal=false

PROBE 7  Parquet — survival and determinism            [new in this edition]
   two writes of identical data: len=1093  identical=true
   schema md survives : Some("rel-1")
   field md survives  : Some("qt-demo")
   ext name survives  : Some("pse.semantic_id")
   null preserved=true   -0.0 sign preserved=true
   'created_by' writer string embedded in the file: true

Pass 2 — alignment opportunities and a specification gap

Gaps and risks

• Identity and integrity are separate. Blueprint §5.3 defines a versioned logical hash; §20 names each stored encoding by its own byte checksum. IPC-file/Parquet encodings cannot be verified against the canonical stream digest [review:E4].
• Finish and validate every writer before publication. Verify physical checksum/length/format, then the decoded semantic contract and logical hash where required. An existing checksum-named object is not automatically trusted (blueprint §20.1; [review:E4]).

8. The C Data / C Stream FFI boundary and Python interop (A7)

Role: §21.1 extension module (pyo3 + pyo3-arrow, cdylib); D12 “one adapter consumes a CanonicalMathProblem bundle over the Arrow C stream interface”; §21.5 typed Python contracts.

Capability inventory

What the blueprint binds to

Pass 2 — alignment opportunities

Gaps and risks

• pyo3-arrow depends on thiserror ^1 [docs.rs:pyo3-arrow@0.19.0] while the wider ecosystem has moved to thiserror 2.x. Two major versions of thiserror in one graph is legal (no shared types cross the boundary) but worth knowing before §23.2’s failure taxonomy is built on thiserror.
• The buffer_protocol default feature “requires either the abi3-py311 pyo3 feature or building non-abi3 wheels” [docs.rs:pyo3-arrow@0.19.0]. §3.1 targets Python 3.11+, so abi3-py311 is available — but this is a wheel-building constraint that must be settled before packaging, not after.
• FFI ownership: export_array_into_raw and to_ffi transfer ownership across the boundary under the C Data contract. A panic unwinding across that boundary is undefined behaviour — the same rule the companion map records for the Ipopt callbacks. State it once, apply it at every FFI edge.

9. Flight, Flight SQL, and the file-format readers (A8) — survey

Surveyed for completeness and rejected, with reasons, so the rejection is on the record rather than an omission.

10. Pass 3 — the under-leverage sweep

Passes 1 and 2 both start from the blueprint: Pass 1 asks whether what it claims is true, Pass 2 asks what would improve alignment in the areas it already touches. Neither can find a capability the blueprint never gestured at, because neither enumerates the library independently.

This pass does. Four complete enumerations, each with a stated denominator, each row adjudicated bound (already used), adopt, evaluate or reject, with reason. Charter §G and DM-58 still apply: a row naming no principle and replacing no identified work does not appear. Where a whole group is uninteresting it is dismissed as a group rather than padded out.

The denominator matters because of the rule this corpus inherits: absence from the extraction is not evidence that a feature does not exist.

10.1 E1 — the crate inventory

arrow-rs 59.3.0 declares 27 workspace members [gh:apache/arrow-rs@59.3.0/Cargo.toml]. Four are build or test scaffolding (arrow-flight/gen, arrow-integration-test, arrow-integration-testing, parquet_derive_test), leaving 23 publishable crates. This map extracts 20; the three gaps are named below rather than silently omitted.

10.2 E2 — the extension-point inventory

101 public traits across the 20 extracted crates [rustdoc:arrow593@59.3.0]. Most are type-level machinery — ArrowPrimitiveType, ByteArrayType, OffsetSizeTrait, the Sealed markers — which exist to make the generic kernels work and are not extension points in any useful sense. Roughly a dozen are places where a platform can insert its own behaviour. Those are the interesting rows.

10.3 E3 — the declared-policy surface

Arrow’s policy surface is small and almost entirely compile-time, which is itself worth stating: unlike DataFusion (155 runtime config keys), Arrow’s behaviour is fixed at build time by feature flags, so it enters the provenance record as the dependency manifest rather than as a settings hash.

The full feature enumeration is §1.3. Two rows are new findings:

• force_validate — adopt for test and CI profiles. It runs full structural validation on every array constructed, which is too expensive for release builds and is exactly right for a gate. G3 asks whether an invalid state can reach an operation that assumes validity; this turns “we believe our builders are correct” into a checked property across the entire test suite, at the cost of one line in a cargo profile. The blueprint’s §24.1 test layers do not mention it.
• pool — evaluate, per E2.

Beyond features, one runtime policy surface matters and the blueprint already half-specifies it: IpcWriteOptions. Its three constructor arguments (alignment, legacy format, MetadataVersion) plus compression are the complete set of knobs that change the bytes §5.3 hashes. They are policy in the DM-16 sense — declared, versioned, and part of the reproducibility contract — and §5.3 currently names none of them. That is §15 item 1, unchanged from the previous edition and still open.

10.4 E4 — the release delta, 59.0 → 59.3

Features landed in the 59 line [gh:apache/arrow-rs/dev/changelog]. Most are performance work invisible to a consumer. These are the ones that touch a principle:

10.5 Third-party extenders — bounded survey

Surveyed so that a future “we should use X” is already answered. None is adopted.

11. Principle-alignment register (Arrow)

Capabilities the blueprint does not claim, which would improve alignment with DATA_MODEL_DESIGN_CHARTER.md. Every row names a principle and the hand-written work or risk it removes. Rejections are included, because a recorded rejection is worth as much as an adoption.

In the previous edition these rows lived in the DataFusion map as one combined 47-row table. They are split here so each map stands alone; the DataFusion rows are in that map’s §13. Numbering is local to this map.

Adopt

Evaluate

Reject, with reason

12. Acceptance-gate review (Arrow)

This map establishes library surfaces and bounded observations, not platform gate acceptance. The earlier gate summary credited registration and incomplete canonicalization too strongly; the revision-4 review supersedes it.

Use the revision-5 design review for current document-stage gates and plan 02 for implementation acceptance.

13. Leverage matrix

14. Evidence ledger

Rows 1–22 are the previous edition’s, retained so its claims stay traceable. Rows 23–32 are this edition’s. Row 15’s extraction no longer exists on disk and is superseded by row 26; row 14’s open question is closed by row 28.

15. Open items and recommended blueprint amendments

The reviewed amendments are now Proposed blueprint revision-5 contracts. The existing probe receipts remain historical observations; no library receipt proves their platform integration.

The revision-4 evidence supplies E1/E3/E4/E5; review L3/L7/L9 records the pinned source interfaces for the added bindings. Regeneration of the original evidence corpus was not part of this update.