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

Supporting Rust libraries — capability map

Current binding: blueprint revision 5. The original survey and version/probe receipts below retain their historical scope; they were not regenerated in this update. Earlier revision comparisons and parked recommendations are historical. The revision-4 review and ADR-0039–ADR-0048 determine the corrected design bindings below. Platform integration remains Proposed; interface and probe evidence are labeled at their original scope. No Python behavioral corpus was re-audited by this revision.

Companion to docs/authoritative_design/blueprint.md §3.3 (supporting libraries and the boundary each must respect), and the fourth of four capability maps — the other three are arrow-rust.md, datafusion-rust.md and python-libraries.md.

Compiled 2026-09-13 against the versions in §1. Historical survey adjudicated blueprint revision 2 (2026-09-13). The previous edition adjudicated revision 1 and never said so.

0. Purpose, scope, and evidence rules

0.1 What this document is

Blueprint §3.3 names sixteen supporting-library rows covering 24 Rust crates (the seventeenth row is Python and belongs to the Python map), each with a one-line role and a one-line boundary. That is enough to justify a dependency and not enough to build against. This document answers, per crate: what the library can actually do, which of its APIs the blueprint’s stated requirements land on, what we deliberately will not use, and where the blueprint has assumed a capability the library does not provide.

A second pass asks what these libraries 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). A third (§13) enumerates each library independently and asks what is being left on the table.

(The previous edition said “twenty-two crates” while its own anchor table had 25 rows. The count above is reconciled against §3.3: 24 Rust crates plus the Ipopt C API, which is not a crate.)

0.2 Evidence rules

Every API name, type, signature or behavioural claim carries a provenance marker. A claim with no marker is a defect in this document.

The previous edition also declared a [bp:§n] marker it never used, and used a [c7 resolve: …] form it never declared. Both are gone: blueprint assertions are named in prose, and context7 resolutions are ledger rows.

The [ref:] marker has been retired. It pointed at docs/library_ref/, which has been deleted. Every one of the previous edition’s 35 [ref:] citations has been re-sourced against live evidence or removed with its claim — §0.4 records what that cost.

Status words in the “what the blueprint binds to” tables mean:

• leverage — the library provides this; use it directly.
• build on top — the library provides a foundation but not the capability; platform code is required and its cost is stated.
• confirmed — a specific claim the blueprint makes about a library is true as stated.
• refined / erratum — the claim is wrong or imprecise; the correction is given and the affected blueprint section named.
• open item / open decision — a question this lookup surfaced that must be answered before or during implementation.

0.3 Status vocabulary

Status words in the “what the blueprint binds to” tables mean:

• leverage — the library provides this; use it directly.
• build on top — the library provides a foundation but not the capability; platform code is required and its cost is stated.
• confirmed — a specific claim the blueprint makes about a library is true as stated.
• refined / erratum — the claim is wrong or imprecise; the correction is given and the affected blueprint section named.
• adopt / evaluate / reject — Pass-2 and Pass-3 recommendations, disciplined by charter §G (common false positives) and DM-58: a recommendation that names no principle and replaces no identified hand-written work does not appear.
• open decision — a question this lookup surfaced. §18 gives each one a recommendation and the evidence; the decision itself remains the owner’s.

0.4 What the deleted reference corpus cost, and what replaced it

The previous edition drew on docs/library_ref/, a corpus of local deep-dives. That directory has been deleted. Thirty-five citations across eleven files became unresolvable, and with them the sole support for three of the ten recommended blueprint amendments.

Every one has been re-sourced or removed. The outcome:

Two corrections this exercise forced on the previous edition’s own text, beyond the amendments:

1. It claimed “this cluster produced the document’s one blueprint erratum” (C3, serde_yaml) and then issued a second one eleven sections later (C4, petgraph). This edition carries five, and counts them.
2. Its object_store trait surface was taken from a reference describing a different version than the one §3.1 pins. That is precisely the failure mode an unresolvable citation hides.

0.5 Coverage

Where the previous edition relied on context7 breadth, this one leads with locally generated rustdoc: 26 crates extracted at the pinned versions, 190,463 declarations, 589 public traits (§1.5). context7 and docs.rs remain for idiom and intent. Three crates that context7 does not carry at all — num-dual, serde_arrow, feos-core — are now covered by the authoritative lane rather than by fallback.

One named exclusion: the Ipopt C API has no crate and needs a native library, so it is sourced from the upstream header at an exact tag [gh:coin-or/Ipopt@releases/3.14.16] rather than by extraction.

0.6 Version anchoring

Anchors in §1 are pinned exactly and resolved into a committed lockfile, not proposed. MSRV/edition-2024 compatibility against the platform’s Rust 1.94 floor (§3.1) is recorded where a crate states one.

1. Version anchors, the pin gap, and the receipts

1.1 The pin gap — the largest single finding in this map

Blueprint §3.2 line 277 states that the workspace manifest “carries every pin once”. Blueprint §3.1 pins five components: the DataFusion family, the Arrow family, object_store, pyo3/pyo3-arrow, and tokio.

Of the 24 supporting Rust crates §3.3 names, exactly one — tokio — has a version anchored anywhere in the blueprint. The other 23 have none. §26 F11 acknowledges two of the 23 (serde_yaml, num-dual); the remaining 21 are unrecorded.

That includes blake3, which is the most deeply wired supporting crate in the design — roughly twenty use sites spanning semantic-ID derivation (§5.1), content hashing (§5.3), hash-consing (§7.4), the plan fingerprint (§14.2) and the manifest (§20.2) — and which is additionally assigned to no crate in §3.2 and used at two digest widths (128-bit IDs, 256-bit content hashes) with no derivation mechanism named.

The table below is therefore offered as a §3.1 amendment the blueprint can adopt wholesale. Every version was resolved into the committed lockfile of §1.5, not proposed.

1.2 Anchors

1.3 Measured: the num-dual split is real, and worse than a duplicate

Resolving the manifest above produces 362 packages with 17 names at more than one version, and one of them is load-bearing [probe]:

num-dual    0.14.2, 0.15.0      <- type-identity hazard
thiserror   1.0.69, 2.0.20
syn         1.0.109, 2.0.119, 3.0.5

Reverse dependencies, from the lockfile:

feos-core 0.10.1           ->  num-dual ^0.14   (resolved 0.14.2)
quantity  0.14.1           ->  num-dual ^0.14   (resolved 0.14.2)
<this manifest>            ->  num-dual =0.15.0

Three facts follow, and the third is the one that matters.

1. The split is entirely feos’s. Only feos-core and its own quantity dependency want 0.14. Nothing else in a 362-package graph does.

2. feos-core 0.10.1 sits one minor behind on both of its key dependencies — num-dual ^0.14 against 0.15.0, and quantity ^0.14 against 0.15.0.

3. The trait’s shape changed between the two, so the kernel source differs, not merely the type. From the extraction [rustdoc:num-dual@0.14.2], [rustdoc:num-dual@0.15.0]:

   0.14.2   trait DualNum<F>: … NumOps<F> … From<F> … DualStruct<F, Real = F> …
   0.15.0   trait DualNum:    … NumOps<Self::Primitive> … From<Self::Primitive> …
                                DualStruct<Real = Self::Primitive> …
   

   §18.5 promises “the same body monomorphized over num_dual::DualNum”. A kernel written for 0.14 is bounded D: DualNum<f64>; the same kernel for 0.15 is bounded D: DualNum<Primitive = f64>. Those are different source files. The choice is not “which version do we depend on” but “which signature does every kernel body in pse-kernels carry”.

   A secondary confirmation, from this extraction’s own tooling: cargo rustdoc -p num-dual fails outright with “specification num-dual is ambiguous” once both versions are present. The hazard is visible to cargo before it is visible to the type checker.

1.4 Supply chain and maintenance

A lane the Arrow and DataFusion maps do not need: those are one well-run Apache project each, whereas this map’s surface is 24 independently-owned crates.

RustSec advisories touching this set — three, all patched below the versions in play [rustsec:RUSTSEC-2018-0005], [rustsec:RUSTSEC-2023-0078], [rustsec:RUSTSEC-2024-0358]:

cargo audit is therefore clean today. And that is the finding, because:

serde_yaml’s deprecation is invisible to cargo audit. It carries no RustSec unmaintained advisory. The deprecation is encoded only in the semver build metadata — 0.9.34+deprecated — and a repository banner, neither of which any standard tool interprets. It still takes ~90 million downloads a quarter [crates.io:serde_yaml].

So a clean cargo audit is not evidence that the dependency set is maintained. §24’s supply-chain gate needs cargo deny’s maintenance and ban checks, not cargo audit alone — otherwise the one dependency this map flags as an erratum passes CI silently.

Maintenance recency, worth stating because none of it is an advisory [crates.io:*]:

1.5 Extraction receipt

toolchain       rustc 1.100.0-nightly (809936eac 2026-09-12)
flags           -Z unstable-options --output-format json
format_version  61
targets         25 requested; 3 needed explicit name@version specs (see below)
documents       26 (both num-dual majors extracted, for §1.3)
lockfile        362 packages, committed
facts           build/facts/support — 190,463 declarations, 589 public traits,
                113,713 impl relations

Three targets — syn, num-dual, thiserror — could not be documented by bare crate name because each resolves at more than one version; they were re-run as name@version. That is §1.3’s hazard showing up in the build tooling.

Committed under docs/capability-maps/evidence/rust/: support-Cargo.toml, support-Cargo.lock, gen_rustdoc_support.sh, rustdoc_gen_support.log, the five probe programs, and probe_output_support.txt.

1.6 Probe receipt

The previous edition made no measurements at all. Five programs, eight probes:

2. Code generation — syn, quote, proc_macro2, prettyplease (C1)

Re-sourced. The previous edition rested this cluster on a 172 KB local deep-dive that has since been deleted. Every claim below is now taken from the pinned crates’ own rustdoc [rustdoc:syn@3.0.5], [rustdoc:quote@1.0.47], [rustdoc:proc-macro2@1.0.107], [rustdoc:prettyplease@0.3.0] and from the registry [crates.io:syn]. One anchor had drifted: syn is at 3.0.5, not 3.0.3.

Version anchors [crates.io:syn]:

Note the major version: syn 3 (with prettyplease 0.3 matched to it), not the syn 2 most of the ecosystem still uses. Any example found elsewhere may target syn 2; the local reference is the authority here.

What the blueprint binds to

What we deliberately do not use

• No procedural macros. §4.2’s parenthetical “(non-macro pipeline)” is a deliberate rejection of the derive-macro model, and it is the right one for this platform: a derive macro hides generated code from review, defeats §4.2’s “emitted source is committed and diffed in CI”, and makes the no_shadow_structs.rs governance check impossible to write against real symbols. The local reference covers derive/attribute/function-like pipelines (§22–§24) — those sections are explicitly out of scope.
• The registry is authoritative, the generator is a projection. §3.3’s boundary. A generator that reads anything but reference.schema_* has introduced a second source of truth.

Gaps and risks

• prettyplease formatting stability across versions is the only real operational risk (above).
• syn 3’s feature flags (§7) gate large parts of the AST; enable deliberately — full is convenient and slow to compile, and a generator emitting only items may not need it.

3. Boundary serialization — serde, serde_arrow (C2)

C2.1 serde_arrow — Rust records ⇄ Arrow batches under a declared schema

Proposed anchor: 0.15.0 (released 2026-08-09) [docs.rs:serde_arrow@0.15.0] Arrow compatibility: feature flags arrow-53 … arrow-59; when several are enabled the highest wins [docs.rs:serde_arrow@0.15.0]. The blueprint’s Arrow 59.2 pin (§3.1) is therefore supported — this was the single largest compatibility risk in the cluster and it clears. Role: §4.2 — a SerdeArrowSchema is a generated artifact of the registry, consumed by import/export adapters and the Python contract layer; §1.3 places serde_arrow adapters directly beneath the schema registry.

Capability inventory

What the blueprint binds to

Measured (PROBE 2) — why §3.3’s boundary is not optional

§3.3’s boundary for this row reads “Explicit schemas from the registry; no inference from sample data in production”, and §4.2 says the SerdeArrowSchema is “derived from the registry (never inferred from samples)”. Measured against a Rust record shaped like a pse.* relation row [probe]:

PROBE 2  struct Row { id: [u8; 16], v: f64, label: String }
  field id     type = Struct([16 x UInt8 fields named "0".."15"])
               metadata = {"SERDE_ARROW:strategy": "TupleAsStruct"}
  field v      type = Float64      metadata = {}
  field label  type = LargeUtf8    metadata = {}
  round-trip equal : true

Two findings, and the first is the more serious.

Traced types are not the registry’s types. A [u8; 16] — the natural Rust shape for a pse.semantic_id — traces to a struct of sixteen UInt8 fields, not FixedSizeBinary(16). A String traces to LargeUtf8, not Utf8. Nothing here is wrong of serde_arrow; tracing infers from the Rust type, which is what §4.2 forbids. But it makes the boundary concrete: if anyone ever calls from_type/from_samples in a production path, the resulting schema is structurally incompatible with §4.4’s extension types, and the failure is a wrong storage type rather than an error. The governance grep §4.2 already implies should name SchemaLike::from_type and from_samples explicitly.

And the adapter stamps its own metadata. The traced field carries SERDE_ARROW:strategy = "TupleAsStruct", which survives into the RecordBatch. That is open question 5’s concern, confirmed: a batch that arrived through the adapter carries field metadata a registry-built batch does not. Since §5.3 hashes the canonical IPC encoding, which includes field metadata, two logically identical relations would hash differently depending on their provenance.

The resolution follows from the first finding rather than needing a new rule: because the registry supplies the schema, no SERDE_ARROW:* key should ever appear on a platform relation. Recommendation for Q5: treat any SERDE_ARROW:* key on a relation schema as a contract violation — a governance check, not a hashing-policy decision.

What we deliberately do not use

• from_samples and from_type are banned in production paths. §3.3’s boundary (“explicit schemas from the registry; no inference from sample data in production”) maps exactly onto never calling these two constructors. A governance grep for from_samples(/from_type::< outside test code enforces it cheaply — recommend adding it beside the existing no_shadow_structs.rs check (§4.2).
• Not the marrow path. to_marrow/from_marrow exist so libraries can avoid pinning an Arrow major; the platform deliberately pins Arrow 59.2 workspace-wide (§3.1) and wants the real RecordBatch, so the arrow-59 feature and to_record_batch/from_record_batch are the right surface.
• serde_arrow is not the relation writer. Generated typed builders and views (§4.2) remain the interior path; serde_arrow serves import/export adapters at the edges, where the peer is a serde type rather than a relation.

Gaps and risks

• Field-metadata key collision — a real design item. serde_arrow writes its own key, STRATEGY_KEY, into Arrow field metadata [docs.rs:serde_arrow@0.15.0], the same namespace §4.3 reserves for pse.semantic.* and ARROW:extension:name. Two consequences to settle: (1) §4.3’s “metadata is a carrier” rule must tolerate a foreign key on fields that pass through serde_arrow; (2) §5.3 step 2 strips volatile metadata before hashing — STRATEGY_KEY must be classified explicitly as volatile (stripped) or contractual (kept), or two logically identical relations could hash differently depending on whether they arrived through an adapter. Open decision.
• Extension types. The docs reference support for field metadata, extension types, FixedSizeBinary and dictionary encoding, but the status detail lives in a separate support-matrix module that was not fetched. Since every blueprint extension type (§4.4) is backed by FixedSizeBinary, Struct, List or Dictionary storage, the risk is low — but the round-trip of pse.semantic_id (FixedSizeBinary(16)) and pse.quantity_value (a struct) through serde_arrow should be a spike before committing, with Overwrites as the fallback for forcing a field’s definition.
• TracingOptions and Strategy are needed only when a Rust type has no direct Arrow match. If the generated record types are shaped from the registry, this should never fire; a Strategy appearing in production is a signal the generated type diverged from the relation.

C2.2 serde — the trait layer underneath

Role: §3.3 pairs serde with serde_arrow for schema-governed conversion at import/export boundaries; it is also the derive layer under serde_yaml/toml (C3) and appears as an optional feature of num-dual (C7) and uom (C7).

No capability lookup was performed and none is warranted: serde is the Rust serialization substrate, its surface (Serialize/Deserialize/derive) is stable and universally documented, and the blueprint asks nothing unusual of it.

What matters is the boundary, which is entirely a platform rule:

• A #[derive(Serialize, Deserialize)] struct that mirrors a relation’s column list is a governance failure under §4.2 (“nothing hand-written may duplicate a column list”), regardless of which crate consumes it. The no_shadow_structs.rs check must therefore cover serde-derived types, not only plain structs.
• serde types are legitimate for documents (package/case YAML and TOML, §22.1), manifests (§20.2 JSON), and external formats (IDAES to_json v4 import, §20.5) — shapes that are genuinely not relations.

4. Document loading and the expression DSL — serde_yaml, toml, winnow (C3)

This cluster produced the document’s one blueprint erratum: serde_yaml is no longer maintained.

C3.1 serde_yaml — deprecated; a replacement decision is required

Current release: 0.9.34+deprecated [docs.rs:serde_yaml@0.9.34+deprecated]. The documentation carries a banner stating verbatim: “(This project is no longer maintained.)”

§3.3 names serde_yaml for package/case document loading and §22.1 makes YAML a first-class authoring format. Adopting an unmaintained crate for the authoring boundary — the platform’s outermost trust boundary, parsing user-supplied documents — is the one place where “unmaintained” is not a cosmetic concern: it means no security fixes for a parser fed untrusted input.

Verified replacement candidates (existence and coverage confirmed; selection not made):

Recommendation to evaluate, not to adopt blind: serde-saphyr’s two stated properties — panic-free, and no intermediate structure — are exactly what an authoring-boundary parser wants, since §23.2 requires authoring.parse to be a typed failure with a source span, never a panic. serde_norway is the lower-effort path if drop-in compatibility outweighs that. Open decision requiring a spike; whichever wins, §3.3’s table needs updating.

Boundary (unchanged by the substitution): §3.3 — “parser output is authored relations; no evaluation during parsing.”

Measured (PROBE 7) — the replacement decision, settled by evidence

Open question 1 asked which YAML crate replaces serde_yaml, and set the criterion itself: §23.2 requires typed failures with spans rather than panics, so span support should decide it. Measured [probe]:

PROBE 7b  serde-saphyr 1.2.0
  valid input            : parsed ok
  type error             : rejected, with
       error: line 2 column 10: invalid u32
        --> <input>:2:10
         |
       1 | id: pkg.demo
       2 | version: three
         |          ^ invalid u32
  -- hostile input --
  unterminated flow seq  -> typed Err (no panic)
  tab indentation        -> typed Err (no panic)
  duplicate key          -> typed Err (no panic)
  deep nesting (200)     -> typed Err (no panic)

serde-saphyr produces a caret diagnostic with line and column out of the box — the shape §23.2 wants, and better than serde_yaml offered — and refuses all four malformed inputs with typed errors rather than panics. It also ships a budget module for bounded parsing and a localizer for message control [rustdoc:serde-saphyr@1.2.0], which matter at a boundary that parses user documents.

Against the alternatives [crates.io:*]: serde_norway has not been released since 2024-12-21, so replacing one quiet crate with another quiet crate; serde_yml is explicitly deprecated in its own description. serde-saphyr was released 2026-08-30.

Recommendation for Q1: serde-saphyr 1.2.0. The decision remains the owner’s; the evidence is one-sided.

And the TOML half, which the previous edition correctly called free and unclaimed [probe]:

PROBE 7a  toml::Spanned
  id      span = 5..15   value = "pkg.demo"
  version span = 26..27  value = 3
  source slice at the version span : "3"
  type error span = Some(26..33), rendered with a caret at line 2 column 11

Byte offsets that slice back to the source exactly, plus spans on errors. §22.1’s package.toml and §4.4’s pse.source_span get this for nothing.

C3.2 toml — document loading with source spans

Proposed anchor: 1.1.6+spec-1.1.0 [docs.rs:toml@1.1.6] — a 1.x stable crate, one of only two in this document. Role: §22.1 package layout and §22.2 change sets; the TOML half of §1.3’s “load (serde_yaml, toml)”.

What the blueprint binds to

Asymmetry to resolve: TOML gets spans for free; the YAML path’s span support depends entirely on which replacement crate C3.1 selects. Since §4.4 defines one pse.source_span type for all authored documents, span support should be a selection criterion for the YAML crate, not an afterthought.

C3.3 winnow — the expression DSL parser

Proposed anchor: 1.0.4 (released 2026-07-13) [docs.rs:winnow@1.0.4] — 1.x stable; MSRV policy is “the last 6 months of rust releases”, no fixed number. Already in the graph: toml depends on winnow ^1.0.0 [docs.rs:toml@1.1.6], so the DSL parser adds no new parser engine — one engine, one version, which is what §3.3’s “explicitly not added” discipline wants. Role: §7.7 — parse the authored expression DSL into template expression-graph nodes with unresolved paths and source spans.

Capability inventory

What the blueprint binds to

What we deliberately do not use

• Not Partial. Authoring documents are read whole; streaming-input support adds failure modes for nothing.
• The parser never resolves, evaluates, or type-checks. §3.3’s boundary and §7.7’s P3 split — unit inference (§8.3) and path resolution belong to canonicalization, not to the grammar.
• cut_err is a discipline, not an optimization. Once a construct is unambiguously entered (sum( has been consumed), failing must be unrecoverable so the error reports the real problem rather than backtracking into a misleading alternative. This directly serves §23.2’s requirement that failures name the culprit.

Gaps and risks

• Both toml and winnow are 1.x with stable APIs — the lowest-risk crates in this document. The cluster’s risk is concentrated entirely in the serde_yaml replacement decision (C3.1).
• winnow’s MSRV policy is a rolling window rather than a fixed floor; with the platform on Rust 1.94 this is not a constraint, but it does mean winnow may raise its floor without a major-version bump.

5. Graph algorithms — petgraph (C4)

Re-sourced and measured. The previous edition rested this cluster on a 598 KB local deep-dive that has since been deleted — including the only support for recommended amendment B. Every claim below is now taken from petgraph 0.8.3’s own rustdoc [rustdoc:petgraph@0.8.3] and from PROBE 3 [probe]. Amendment B survives intact, with one fact the deleted reference did not carry. Role: §12.5 topology closure (inferred.topology_edges “built in petgraph, persisted as rows”); §15.2–15.3 structural analysis; §14.1 pass-DAG checks; §17.4 topological unit ordering for sequential-modular initialization.

What the blueprint binds to

Claim audit: “petgraph lacks maximum matching”

petgraph does ship maximum matching: algo::maximum_matching(graph) -> Matching<G> plus greedy_matching and the Matching type [rustdoc:petgraph@0.8.3]. But the decision to hand-write Hopcroft–Karp is still right, for a stronger reason than the blueprint states:

• maximum_matching uses Gabow’s algorithm for general graphs, documented complexity O(|V|³), auxiliary space O(|V| + |E|), and it treats the input as undirected regardless of orientation [rustdoc:petgraph@0.8.3].
• The equation×variable incidence graph (§15.3) is bipartite, where Hopcroft–Karp runs in O(|E|√|V|). At process-model scale the difference between O(|E|√|V|) and O(|V|³) is the difference between a usable and an unusable structural check.

Recommended erratum to §15.3: replace “petgraph lacks it” with “petgraph ships only general-graph matching (Gabow, O(|V|³)); the incidence graph is bipartite, so Hopcroft–Karp’s O(|E|√|V|) is required.”

Measured (PROBE 3)

(a) The matching claim — amendment B — survives verbatim. petgraph 0.8.3’s own rustdoc for maximum_matching reads [rustdoc:petgraph@0.8.3]: “Compute the maximum matching using Gabow’s algorithm… The input graph is treated as if undirected. The algorithm runs in O(|V|³). An algorithm with a better time complexity might be used in the future.” Measured [probe]:

PROBE 3b  directed eq->var graph, maximum_matching : [(0,3), (1,2)]  size=2
          every edge reversed                      : [(0,3), (1,2)]  size=2
          same matching either way                 : true

Reversing every edge changes nothing, which is what “treated as if undirected” means in practice. The decision to hand-write Hopcroft–Karp stands, for the stated reason: O(|E|√|V|) against O(|V|³) on a bipartite incidence graph.

One fact the deleted reference did not carry: maximum_matching panics if g.node_bound() is usize::MAX [rustdoc:petgraph@0.8.3]. Unreachable at realistic sizes, but a panic is not a typed failure (§23.2), so the platform’s own implementation should not inherit the habit.

(b) SCC ordering — the determinism rule is confirmed, with a sharper demonstration [probe]:

PROBE 3a  graph with a 3-cycle {0,1,2}, a 2-cycle {3,4}, and an acyclic tail
  tarjan_scc, insertion order 1 : [[5], [4, 3], [2, 1, 0]]
  tarjan_scc, insertion order 2 : [[5], [4, 3], [2, 1, 0]]
  kosaraju_scc, same graph      : [[5], [3, 4], [0, 1, 2]]

tarjan_scc is stable across insertion orders — but kosaraju_scc returns the same components in the opposite intra-component order. The order within a component is therefore an artifact of the algorithm, not a property of the graph, and petgraph guarantees nothing about it. §15.3’s rule — order ties on semantic ID — is required, and §5.1’s “re-running compilation on an unchanged snapshot reproduces identical IDs” depends on sorting within every block, not only across blocks. Swapping one petgraph algorithm for another would otherwise silently change every derived ID.

(c) A capability §12.5 does not claim: feedback_arc_set [probe]:

PROBE 3c  flowsheet-shaped recycle 0->1->2->3->1
  greedy_feedback_arc_set : [(3, 1)]      <- exactly the recycle edge
  toposort before removal : Err(Cycle(NodeIndex(3)))
  condensation            : 4 nodes -> 2

A tear set is a feedback arc set. §12.5 and §15.3 list tear selection among the hand-written algorithms; petgraph ships greedy_feedback_arc_set, and on a recycle it returns precisely the tear. See §13.

What we deliberately do not use

• Graphs never persist. §3.3’s boundary — “graph facts persist in Arrow; matching and DM decomposition are implemented in pse-structural”. petgraph structures are built per analysis from compiled.incidence and dropped; inferred.topology_edges is the relation of record (§12.5).
• petgraph node indices are not identity. They are artifact-local at best and reused after removal; §5.1’s three identity forms admit no fourth. Map NodeIndex ↔ semantic ID explicitly at the boundary of every analysis. [rustdoc:petgraph@0.8.3]
• Not GraphMap keyed by semantic ID, tempting as it looks: GraphMap implements NodeCompactIndexable but the identity mapping is better kept explicit and sorted, since determinism (above) requires a canonical order anyway.
• Not DM decomposition from petgraph — it has none; §15.3’s coarse Dulmage–Mendelsohn is platform code over the matching, as the blueprint says.

Gaps and risks

• petgraph 0.8.3 is pre-1.0 and was last released 2025-09-30 [crates.io:petgraph]; algorithms continue migrating toward graph-trait-based implementations, so signatures may shift across minor versions. Pin exactly.
• maximum_matching’s docs note “a better-complexity algorithm may be used in the future” [rustdoc:petgraph@0.8.3] — worth re-checking at upgrade time, though a bipartite-specialized implementation remains ours regardless.

6. Incremental compute — salsa (C5)

Proposed anchor: 0.28.2 (released 2026-08-03) [docs.rs:salsa@0.28.2]. MSRV not stated — open item against the 1.94 floor. context7 coverage: the richest of any crate in this document — three sources, used for different purposes: /websites/salsa-rs_github_io_salsa (the book, for the algorithm and idiom), /websites/rs_salsa (docs.rs, for the API and internals), /salsa-rs/salsa (the repo). Role: §14.3 — “each pass is a salsa query keyed by the content hashes of its declared inputs and its own version… the memo stores the output artifact hashes, which the artifact store resolves”; §14.4 — the invalidation matrix; §2 D14 — incrementality follows declared dependencies.

Capability inventory

What the blueprint binds to

Measured (PROBE 6) — what F13 actually turns on

§26 F13 says salsa duplicates artifact-hash memoization and leaves it open. The question is decidable, and the answer is that the two overlap in purpose and not in mechanism [probe]:

PROBE 6  token_count = 3, doubled = 6
         -- input replaced with different text, same token count --
         token_count = 3, doubled = 6      (backdating: `doubled` need not re-run)
         -- accumulator --
         token_count(src2) = 4, accumulated findings = 1
            Finding("suspicious token in \"this is bad \"")
         -- durability: LOW / MEDIUM / HIGH available --

salsa keys on revision counters and durability, not on content hashes. Its unit is the in-process query; it backdates when a recomputed value is unchanged, so downstream queries are skipped even though the input changed. §14.4’s invalidation matrix is expressed entirely semantically and never names salsa — which is precisely why F13 looks like duplication. The two mechanisms answer different questions:

Neither subsumes the other. The artifact hash cannot skip a sub-computation within a pass; salsa cannot survive a restart. F13’s real question is therefore not “is salsa redundant” but “is intra-pass granularity worth a second memoization system” — a DM-58 question about demonstrated need, and one §24.3’s benchmarks can answer.

Two salsa capabilities the blueprint does not name and should:

• #[salsa::accumulator] — findings travel alongside a query’s value without being part of its return type, which is exactly §23’s “a pass either succeeds with findings or fails” shape. Measured above. This is recommended amendment E, and the mechanism works as that amendment describes.
• CancellationToken and Cycle — §18.3 and §20.1 both specify interruption behaviour, and §14.2’s rule engine runs to a fixed point. salsa has first-class machinery for both [rustdoc:salsa@0.28.2].

What we deliberately do not use

• salsa never holds the authored model. §3.3’s boundary (“caches compiler computations, never the authored model”) is enforceable and cheap: #[salsa::input] holds content hashes and identifiers, never relation payloads. The artifact store (§20.1) is the only thing that holds bytes, and salsa memos point into it.
• Not #[salsa::interned] for semantic IDs. Semantic IDs are already 128-bit opaque values with cross-artifact meaning (§5.1); re-interning them into database-local integer ids would create a second identity space that dies with the database — precisely the artifact-local-ordinal mistake D4 separates out.
• report_untracked_read is a defect, not a tool. Any pass that reads the artifact store or the filesystem outside a declared input makes itself re-execute every revision and silently voids §14.4. Recommend a governance check that it appears nowhere in pse-compiler.
• Not salsa’s cycle recovery for the rule engine. §14.2’s fixed-point executor iterates DataFusion plans to a fixed point with provenance rows; that is a different mechanism at a different layer from salsa’s query-graph cycle recovery. Keep them unconflated — though cycle_fn/cycle_result remain available should the pass DAG itself ever need it (it should not; §14.1 declares a DAG).

Gaps and risks

• MSRV unknown against the 1.94 / edition-2024 floor — verify at cargo add.
• API churn. salsa 0.28.x is pre-1.0 and has been restructured substantially (the current generation is macro-attribute based; older tutorials describe a different query-group API). Pin exactly, and treat any web-sourced salsa example as possibly pre-dating this generation.
• Accumulators are feature-gated (feature = "accumulator" guards appear in the source) — enable deliberately if findings ride this path.
• Unwind-based cancellation interacts with FFI: a cancellation unwinding through the Ipopt C-API callback boundary (C11) is undefined behaviour. The solve driver must check cancellation between callbacks, never unwind through one. Design rule to record.
• Durability assignment is a design decision the blueprint has not made: which inputs are HIGH/NEVER_CHANGE (reference packages, the schema registry within a snapshot) versus low (case values). Getting this right is most of the performance benefit. Open item.

7. Equality saturation (optional, phase 4) — egglog (C6)

context7 ID: /egraphs-good/egglog (115 snippets, benchmark 60.25) — the thinnest coverage of any crate here that context7 does cover. Status in the blueprint: optional, phase 4 (§25); §7.4 canonicalization is otherwise hand-written. Role: §3.3 — “equality-saturation rewrites under explicit type/domain guards”, bounded to “only rewrites justified by physical type, domain, and numerical policy”.

Capability inventory

Fit assessment against the blueprint

Measured (PROBE 8) — extraction is reproducible; the trap is elsewhere

Open question 10 asked whether egglog’s extraction is deterministic across runs, because §5.1 identity and §20.4 reproduction would both depend on it. Five identical runs of the same program, compared under three renderings [probe]:

PROBE 8  5 identical runs -> distinct results by rendering
  Debug   ({:?})                          : 5
  Display ({})                            : 1
  snapshot_stable_under_proof_encoding    : 1
  extracted term : (Mul (Add (Var "x") (Num 2)) (Var "y"))

The extraction is deterministic. What varies is the Debug rendering of the internal TermDag, whose nodes field is a hash set — so its iteration order changes per process. The extracted term itself, and egglog’s own snapshot_stable_under_proof_encoding, are identical every time.

This is the same trap the companion DataFusion map found in datafusion-proto’s field metadata, and the same one the Arrow map found in Schema metadata: hash iteration order leaking into a rendering that something downstream might hash. The rule generalises — if any egglog output ever reaches an ID or a content hash, it must go through Display or snapshot_stable_under_proof_encoding, never {:?}.

[UNVERIFIED] — one process, one egglog version. Cross-process and cross-version stability are not measured, and §26’s phase-4 timing makes the cross-version question the live one: egglog has released three majors in ten months (0.5 → 1.0 in 2025-10, 2.0 in 2026-02, 3.0 in 2026-08) [crates.io:egglog], so whatever is assessed now will not be the API phase 4 meets.

The structural cost, stated plainly

egglog requires the IR to be re-encoded into egglog’s own datatype/sort language [c7:/egraphs-good/egglog]. That is precisely the “second model language” the blueprint rejects elsewhere (§13.6 for diffsol, D6 for DataFusion Expr). The encoding is mechanical and can be generated from §7.2’s operator catalog — but it is a real, maintained translation layer with its own drift risk, and the blueprint’s §3.3 boundary line does not acknowledge it.

Recommendation: keep egglog exactly where the blueprint puts it — phase 4, optional, behind a feature flag — and make adoption conditional on two spikes: (1) determinism of extraction, (2) a generated encoding from the operator catalog so the two representations cannot drift. Hand-written canonicalization (§7.4) must remain complete on its own; egglog is an optimization, never a dependency of correctness.

8. Numerics — num-dual, faer, uom (C7)

The cluster carrying the most blueprint weight and the least prior coverage. num-dual and faer are both fallback-lane crates (§0.3).

C7.1 num-dual — generic forward-mode derivatives inside kernels

Proposed anchor: 0.15.0 (released 2026-08-12) [docs.rs:num-dual@0.15.0] Role: §18.5 kernel adapters — “the same body monomorphized over num_dual::DualNum types”; §18.2 step 5 — kernels contribute second derivatives as hyper-duals; §9.8 — FeOs SAFT/cubic models are written over num-dual and so derivatives arrive natively.

Capability inventory

What the blueprint binds to

Measured (PROBE 4) — the implicit function theorem is library capability

§9.8’s Helmholtz route and §18.2 step 4’s implicit kernels both need the derivative of a root that is defined implicitly. Measured against a cubic-EOS compressibility root, Z³ − Z² + (A − B − B²)Z − AB = 0, differentiating the vapour root with respect to the attraction parameter [probe]:

PROBE 4  solved Z(A0)          = 0.023366337826   residual = 0.000e0
         dZ/dA by hand (IFT)   = -0.014355061869
         implicit_derivative   = -0.014355061869
         agrees with hand IFT  : true
         second_derivative f'' : -1.859802

num_dual::implicit_derivative reproduces the hand-derived implicit function theorem exactly. Recommended amendment G is confirmed by measurement: this is library capability, not platform code to write, and the blueprint should say so where §18.2 step 4 says “implicit kernels apply the implicit function theorem on the selected branch”.

The surrounding family is wider than §3.3’s “forward-mode and hyper-dual derivatives” suggests: ImplicitFunction and ImplicitDerivative give the structured form, implicit_derivative_binary/_vec/_sp the multivariate forms, and hessian/partial_hessian the second-order forms §18.2 step 5 needs [rustdoc:num-dual@0.15.0].

One API note that follows from §1.3. The probe’s kernel body is bounded D: DualNum<Primitive = f64>. On num-dual 0.14 — the version feos-core forces — the same body is bounded D: DualNum<f64>. This is what “the kernel source differs between the two pins” means concretely.

What we deliberately do not use

• No whole-problem differentiation. §3.3’s boundary (“kernel-local; never a dense dual vector over the whole problem”) is confirmed to be the right call for a second reason the blueprint does not state: num-dual is forward-mode only [docs.rs:num-dual@0.15.0]. Forward mode costs one sweep per independent variable, so a dense dual over all solver variables would be O(n) sweeps per residual evaluation. The per-equation reverse adjoint sweep of §18.2 step 4 is ours to write; num-dual cannot supply it.
• Not the nalgebra/ndarray integrations by default. The evaluation program owns its layouts (§3.3, D11). Feature-gate these off unless a kernel genuinely needs matrix-valued duals; gradient/hessian signatures are expressed over OVector/OMatrix, so using the drivers pulls nalgebra in — kernels that want to avoid it differentiate with the scalar types directly.

Gaps and risks

• MSRV / edition-2024 compatibility not stated in the fetched docs — open item, verify at cargo add against MSRV 1.94.
• Third-derivative types exist but the blueprint never asks for them; do not adopt speculatively.
• The linalg module over dual-valued matrices is a possible shortcut for small implicit kernels — noted, not committed.

C7.2 faer — sparse and dense linear algebra for diagnostics and workspaces

Proposed anchor: 0.24.4 (released 2026-06-24) [docs.rs:faer@0.24.4] Role: §15.4 num.condition_number; §15.5 SVD toolbox; §3.3 “sparse LU/QR, dense SVD, condition estimates; solver workspaces”.

Capability inventory

What the blueprint binds to

Measured (PROBE 5) — the iterative SVD route §15.5 leaves unnamed

§15.5 says “dense faer SVD for small problems, iterative for large” and names no implementation; §26 F17 lists the iterative SVD route as open. faer 0.24.4 does have a matrix-free tier — faer::matrix_free with conjugate_gradient, bicgstab, lsmr, and eigen::{partial_eigen, partial_self_adjoint_eigen, partial_svd} [rustdoc:faer@0.24.4] — so the question is whether it answers F17.

The operator contract works and is small [probe]:

PROBE 5  LinOp::apply matches a direct product    : max|diff| = 0.000e0
         BiLinOp::transpose_apply matches A^T * y : max|diff| = 0.000e0

Five LinOp methods plus three BiLinOp methods, and a sparse Jacobian never has to be materialised. That is the right shape for §15.5 operating on a Jacobian the evaluation program already knows how to apply.

But it does not answer F17 on its own. faer’s own documentation for partial_svd says it computes “an estimate of the singular values … with the largest magnitude” [rustdoc:faer@0.24.4]. §15.5 wants the smallest k singular values — rank deficiency below a tolerance, and the small-singular-value/vector pairs that identify the culprit variables and equations. That is the opposite end of the spectrum, and a Krylov method reaches it only through shift-invert, i.e. by applying A⁻¹, which requires a sparse factorisation.

So the answer to F17’s iterative route is two components, not one: faer’s sparse LU to apply the inverse, and matrix_free to iterate against it. Recording that is more useful than “use matrix_free”, which would have been the wrong shortcut.

[UNVERIFIED] — partial_svd was not executed. Its dimension preconditions (max_dim < min(m, n) against a v0 of length ncols) were not satisfiable in this harness, and the finding above rests on the crate’s documentation plus the measured operator contract rather than on a completed run.

What we deliberately do not use

• No model truth in faer types. §3.3’s boundary holds: SparseColMat instances are per-diagnostic scratch built from compiled.incidence/Jacobian values and discarded; the sparsity pattern of record is the Arrow relation, not the SymbolicSparseColMat.
• Not faer’s own parallelism defaults. Every call takes Par explicitly; §18.8 requires the platform, not the library, to choose.

Gaps and risks

• Condition number cost. The IDAES-parity definition (Frobenius norm of the inverse) is inherently O(n) solves. Either accept it as an opt-in expensive diagnostic, or add an estimator (e.g. Hager–Higham 1-norm estimate) as platform code. Open decision — the blueprint states the formula but not the budget.
• Iterative SVD: present, but aimed the wrong way. §15.5’s “iterative for large” does have a faer entry point — matrix_free::eigen::partial_svd — which targets the largest singular values while §15.5 needs the smallest. Options: implement Lanczos bidiagonalization over matrix_free, add a dedicated crate, or restrict the SVD toolbox to problems small enough for dense SVD and say so. Open decision.
• Pre-1.0 API churn. 0.24.x has no stability guarantee; faer has restructured its API across recent releases. Pin exactly and treat upgrades as a reviewed change, exactly as §3.1 treats the Arrow family.
• context7 coverage for faer is thin (20 snippets), so this inventory is mostly docs.rs-sourced; API shapes below module level should be re-checked at implementation time.

C7.3 uom — compile-time dimensional checking inside kernels

Proposed anchor: 0.38.0 (released 2026-06-23), MSRV rustc 1.68.0 [docs.rs:uom@0.38.0] — comfortably under the platform’s 1.94 floor. Role: §3.3 “compile-time dimensional checks inside selected Rust kernels”, with §8’s dynamic registry authoritative.

Capability inventory

What the blueprint binds to

What we deliberately do not use

• uom never sees a user-defined quantity. Package-authored quantity types (§6.2, §8.1) exist only at runtime; they have no uom type and must not acquire one.
• uom is not the unit-inference engine. §8.3’s inference runs over the dynamic registry against pse.dimension_vector; uom checking inside a kernel is a second, independent guard on hand-written code — a belt-and-braces check, not the mechanism.

Gaps and risks

• Dimension-basis mismatch. pse.dimension_vector (§4.4) is 8-dimensional — the seven SI base dimensions plus currency. uom’s pre-built SI system does not carry currency, so any kernel mixing cost with physics cannot be typed by the stock SI system; it would need a custom system!. Since costing (§19.5) is relational rather than kernel-resident, the practical answer is likely “uom covers physics kernels only, costing stays outside it” — open item to confirm.
• Deciding which kernels get uom typing is unresolved; §3.3 says “selected” without a selection rule. Propose: kernels whose inputs are fixed SI quantities and whose bodies are hand-written (EOS, correlations), not generated adapters.

9. Domain providers (optional) — feos-core/feos, diffsol (C8)

Both are optional capability providers. This cluster contains the document’s most consequential compatibility finding.

C8.1 feos-core — native Helmholtz/SAFT/cubic thermodynamics

Proposed anchor: feos-core 0.10.1 (released 2026-07-24) [docs.rs:feos-core@0.10.1]. context7 has no coverage — FeOs resolves to unrelated libraries [c7 resolve: FeOs] — so this section is docs.rs-sourced. Role: §9.8 — “optional provider crate under KernelSpec for SAFT and cubic models written over num-dual, giving derivatives natively”; §3.3 — “capability providers under KernelSpec; coverage and conventions validated, not assumed”.

⚠ Compatibility finding: num-dual version split

feos-core 0.10.1 depends on num-dual ^0.14 [docs.rs:feos-core@0.10.1], while the current num-dual is 0.15.0 [docs.rs:num-dual@0.15.0]. For a 0.x crate these are semver-incompatible, so Cargo will resolve two copies of num-dual into the graph if pse-kernels takes 0.15 and pse-kernels-ext takes feos-core.

This is not a build-size annoyance — it is a type-identity failure of exactly the kind §3.1 forbids for Arrow majors. DualNum from num-dual 0.14 and DualNum from 0.15 are distinct traits over distinct types. §18.5’s whole premise (“the same body monomorphized over num_dual::DualNum types”) and §9.8’s “giving derivatives natively” both assume one dual-number vocabulary spanning platform kernels and FeOs models. Two copies break that silently at the type level.

Resolution options, in order of preference:

1. Pin num-dual to 0.14 workspace-wide so FeOs and platform kernels share one vocabulary. Cost: forgo 0.15 additions — importantly including whatever changed in the implicit_derivative family (C7.1).
2. Adopt a newer feos-core if one exists that tracks num-dual 0.15 — verify at cargo add; 0.10.1 was the version read here.
3. Keep them separate and accept that FeOs kernels are opaque at the KernelSpec boundary, converting values at the edge rather than sharing dual types. This costs the native-derivative benefit that motivates FeOs in the first place.

Add num-dual to §3.1’s pin table and add cargo tree -d coverage for it alongside the existing Arrow check. This is the actionable item of the cluster.

Boundary

§3.3 and §9.8 already say it: FeOs is a capability provider under KernelSpec, its coverage (property kinds, conventions, reference states) is declared per kernel and validated by parity tests. Nothing about State, PhaseEquilibrium or EquationOfState becomes a platform type — §9.5’s phase equilibrium and §6.x material relations stay authoritative, with FeOs supplying kernel evaluations only.

Gap: the Cargo feature list and any Python-binding feature were not enumerated in the fetched content — open item, minor.

C8.2 diffsol — native DAE trajectory backend

context7 ID: /martinjrobins/diffsol (396 snippets). Version not pinned during this pass — open item. Role: §13.6 — “a native DAE integrator fed directly from the evaluation program (residual and Jacobian callbacks); it is a backend binding; the IR is unchanged”; §18.7 — an option for DAE_INTEGRATE; §25 phase 4.

Fit assessment

Boundary: unchanged — a backend binding lowered from the IR. nalgebra types (DVector, DMatrix) appear in diffsol’s trait signatures, so they enter at the backend edge only and must not propagate into pse-numerics’ own layouts (D11).

10. Identity and storage — blake3, object_store (C9)

C9.1 blake3 — content hashing and derived identity

Proposed anchor: 1.8.7 [docs.rs:blake3@1.8.7]. A 1.x crate — the only post-1.0 dependency in this document, and the only one whose API can be treated as stable. Role: §5.1 derived entity IDs (blake3_128(domain ‖ …)); §5.3 content_hash = blake3(ipc_bytes) and snapshot_id; §4.3 pse.contract.fingerprint; §20.2 manifest hashes; §4.4 the pse.content_hash extension type (FixedSizeBinary(32)). Re-sourced from blake3 1.8.7’s own rustdoc [rustdoc:blake3@1.8.7] and measured by PROBE 1 [probe].

Capability inventory

What the blueprint binds to

Measured (PROBE 1) — which 128-bit derivation, and is truncation sound?

§5.1 derives semantic IDs as blake3_128("pse:named:v1" ‖ package_id ‖ qualified_name) and never says how the 128 bits are obtained. There are two routes and they do not agree [probe]:

PROBE 1  material = "pse:named:v1|pkg-01|flowsheet.heater.inlet"
  hash(material)[..16]              = 221090e3e5fabe979c6d73507758c9b7
  derive_key(ctx, material)[..16]   = d19bb5f9d890907fab83f83e9cbb59a1
  the two routes agree              : false
  finalize_xof -> 16 bytes          = 221090e3e5fabe979c6d73507758c9b7
  xof(16) == hash[..16]             : true
  Hasher::new_derive_key == derive_key : true
  different context -> different bytes : true

Two things follow.

Truncation is sound, and it is not an accident. BLAKE3 is an extendable-output function: asking the XOF for 16 bytes returns exactly the first 16 bytes of the 32-byte digest. Taking a prefix is therefore a defined operation with the security of a 128-bit digest, not a hopeful shortening. That closes the “is 16-byte truncation sound?” half of the open question.

But the two routes give different bytes, so §5.1 must name one. The recommendation is derive_key(context, material), because §5.1 is already doing domain separation by hand — prefixing "pse:named:v1", "pse:symbol:v1", "pse:equation:v1" and so on to the hashed material. derive_key is BLAKE3’s purpose-built mechanism for exactly that, and the probe confirms a different context yields different bytes. Concatenating a prefix into the message achieves the same end less explicitly, and leaves the separator’s encoding as an unstated part of the identity contract.

Either choice is defensible; not choosing is not, because §5.1 IDs are permanent and the two routes are irreconcilable after the fact.

What we deliberately do not use

• Not keyed hashing. new_keyed is a MAC — identity here must be reproducible by anyone holding the same content (§20.4 reproduction), so a secret key would defeat the purpose.
• Not Hash’s constant-time equality for ordinary lookups. blake3::Hash compares in constant time (an anti-timing-attack property); semantic IDs are not secrets, and hot paths that index by ID should use the raw [u8; 16]/[u8; 32] inside Arrow FixedSizeBinary rather than round-tripping through Hash.

Gaps and risks

• Canonicalization, not hashing, is the hard part. §5.3’s five preparatory steps (PK ordering, batch concatenation, dictionary expansion, volatile-metadata stripping, NaN canonicalization with -0.0 preserved) are entirely platform code over Arrow; blake3 contributes only step 5. Test the canonicalizer, not the hash.
• Feature flags rayon and mmap are off by default — enable deliberately and record them in the workspace dependency table.

C9.2 object_store — the artifact store

Version note — settled, and the previous edition’s API description was wrong. The pin question is closed: DataFusion 55.1.0 requires object_store ^0.13.2, so 0.13.2 is not a choice but a constraint, and 0.14.1 must not be used. Revision 2’s §3.1 records this correctly; the companion DataFusion map carries the reasoning.

But re-sourcing this cluster produced an erratum. The previous edition described the trait surface from a local reference that has since been deleted — and that reference described a different version. At the pinned 0.13.2, object_store does not have the API the previous edition listed. Version 0.13.0 reshaped the trait: copy and copy_if_not_exists were merged into copy_opts, delete became delete_stream, rename became rename_opts, and put/get/head became put_opts/get_opts [docs.rs:object_store@0.13.2].

This is exactly the failure mode an unresolvable citation hides: a confident API list, checked against nothing, describing a version the design does not use.

Role: §20.1 artifact store layout, atomic and conditional writes, ref update protocol; §20.2 manifest.

Capability inventory

What the blueprint binds to

What we deliberately do not use

• Never a rename as a commit primitive — and at 0.13.2 the temptation is smaller than it was, because rename no longer exists; only rename_opts does [docs.rs:object_store@0.13.2]. The rule still holds and still belongs in §20.1: a rename is a copy-plus-delete on object stores, not an atomic move, so a commit must be a conditional write to the final path (PutMode::Create for content-addressed artifacts, PutMode::Update for the ref). §20.1’s protocol already does this; stating it prevents someone “optimising” it into a temp-file-and-rename.

  Recommended amendment J is therefore refined, not retracted: the advice is right, but it should name the mechanism (PutMode) rather than a method (rename) that the pinned version does not have.

• The snapshot protocol stays platform code. §3.3’s boundary holds: object_store gives single-object atomicity; multi-relation consistency comes from the write-artifacts → write-manifest → CAS-the-ref ordering, which is ours.

Gaps and risks

• The API erratum (above) is the actionable item in this cluster: any §20.1 pseudocode or prototype written against put/get/copy_if_not_exists will not compile at the pinned version.
• S3 multi-writer coordination. The docs reference S3 needing conditional-write support or DynamoDB-based commit coordination for some use cases [docs.rs:object_store@0.14.1]; the detail was not pinned down. Since §20.1 starts single-writer local, this is deferred — but it must be settled before any multi-writer or S3 deployment, because the ref CAS is the platform’s only serialization point. Open item.
• put_multipart is unused by the current design (artifacts are written whole); revisit only if relation artifacts grow beyond a comfortable single-put size.

11. Runtime and failure — rayon, tokio, tracing, thiserror, miette (C10)

C10.1 rayon and tokio — the thread budget

Re-sourced. tokio 1.53.1 and rayon 1.12.0, both confirmed current [crates.io:tokio], [crates.io:rayon] and resolved into the committed lockfile (§1.5). §3.1’s tokio 1.52+ is consistent — and tokio is the only crate in this entire map that §3.1 anchors at all (§1.1).

Role and boundary are almost entirely a platform concern, and §18.8 already states it well: one configuration owns the DataFusion tokio runtime, the rayon pool for batch kernels and pass parallelism, and the solver’s linear-algebra threads (HSL/MUMPS/PETSc); oversubscription is a configuration error, not a runtime surprise.

Three cross-cluster facts this document surfaces that §18.8 must account for, because each quietly consumes the rayon pool:

The rule §18.8 states (“defaults leave the solver single-threaded while a solve is running”) should be extended: hashing and diagnostics must not steal the pool during a solve either.

C10.2 tracing — structured observability

Role: §23.1 — spans per pass run, per rule evaluation, per plan stage, and per solve; “events carry the semantic IDs involved”; metrics (pass durations, row counts, cache hits, solver iterations) emitted with the same identifiers.

What the blueprint binds to

Two extensions the blueprint does not list — re-sourced, and the recommendation is now qualified [crates.io:datafusion-tracing], [crates.io:instrumented-object-store]:

Amendment D is currently unsatisfiable. Both crates exist and both are version-locked to the DataFusion release line — datafusion-tracing 55.0.0 and instrumented-object-store 55.0.0, both published 2026-08-24. Neither has a 55.1.0 release, and §3.1 pins the engine at 55.1.0. The previous edition hedged exactly this (“verify that release exists before depending on it”) on the strength of a reference that has since been deleted; verified, it does not. Adopting these means either moving the engine back to 55.0.0 — contradicting the owner’s decided pin — or running a plan-instrumenting crate one minor out of step with the plans it instruments, which is the least forgiving kind of mismatch. The companion DataFusion map reaches the same conclusion from the engine side and offers JoinSetTracer as the first-party alternative.

• datafusion-tracing — instruments DataFusion through its own extension points: a PhysicalOptimizerRule that wraps each physical node (instrument_with_spans! and level-specific variants), plus rule-phase instrumentation across analyzer/logical/physical optimizer phases (instrument_rules_with_spans!), with InstrumentationOptions/RuleInstrumentationOptions and pretty_format_compact_batch for batch previews. Version-locked to the DataFusion release (datafusion-tracing 55.0.0 would be required alongside DataFusion 55) — verify that release exists before depending on it.
• instrumented-object-store — spans for object-store operations, which is §20.1’s artifact store.

Both map onto the two subsystems §23.1 most wants visibility into, through supported extension points rather than custom wrappers. Recommend adding them to §3.3 (with the version-lockstep caveat).

What we deliberately do not use

• #[instrument]’s default “record every argument”. A pass takes a snapshot handle and possibly large inputs; blanket recording is both noisy and a way to leak whole structures into logs. Use skip(...) and name fields explicitly.
• Observability is never provenance. §23.1’s separation is load-bearing: provenance.* relations explain derivation and are content-addressed and reproducible; spans explain execution and are not. A field in a span is not a provenance record.

C10.3 thiserror and miette — the failure taxonomy

thiserror 2.0.20 [rustdoc:thiserror@2.0.20]; its surface (#[derive(Error)], #[error("…")], #[from], #[source]) is stable and unremarkable. The interesting half is miette.

miette role: §3.3 — “typed failure taxonomy with source anchors”; §23.2 — a failure-class table where “failures carry the relation rows and source spans involved; they are never flattened into ‘run failed’”.

What the blueprint binds to

What we deliberately do not use

• miette::Result in library crates. miette’s own documentation is explicit: use its Result throughout an application “but NOT your libraries! Those should always return concrete types!” [c7:/websites/rs_miette]. Every pse-* crate is a library and must return its own concrete error enums (thiserror + Diagnostic impls); only the CLI and the top-level driver return miette::Result and install a reporter. This also keeps §23.2’s classes typed and matchable rather than erased into a report.
• Not miette’s fancy graphical rendering as the machine-readable output. Rendered output is for humans at a terminal; runtime/provenance relations are what programs and §20.4 reproduction read.

Gaps and risks

• miette’s version was not pinned during this pass — open item, record an anchor at cargo add.
• The rows-versus-diagnostic design item above is the one substantive decision in this cluster.

12. Solver FFI — the Ipopt C API (C11)

Re-sourced from the header itself. The previous edition rested this cluster on a local reference that has since been deleted, and flagged one signature as read second-hand. Everything below now comes from IpStdCInterface.h at COIN-OR tag releases/3.14.16 [gh:coin-or/Ipopt@releases/3.14.16]. Every claim survived; one recommended amendment had the wrong function names.

The complete exported C surface is eleven functions, which is small enough to state in full: CreateIpoptProblem, FreeIpoptProblem, IpoptSolve, AddIpoptStrOption, AddIpoptNumOption, AddIpoptIntOption, OpenIpoptOutputFile, SetIpoptProblemScaling, SetIntermediateCallback, GetIpoptCurrentIterate, GetIpoptCurrentViolations. This section covers the Rust binding layer and the two capabilities §18.3 depends on. (The previous edition also pointed at two local documents on option semantics and metrics; both are deleted, and no claim in this map rested on either, so the pointers are removed rather than replaced.)

Crate decision: §3.3 specifies an own -sys crate. A search found no established Rust binding worth preferring — context7 resolves ipopt-sys only to the upstream C++ project /coin-or/ipopt [c7 resolve: ipopt-sys]. The blueprint’s decision stands.

What the blueprint binds to

Re-sourced (PROBE-free, from the header)

Two claims the previous edition could not fully support, now first-hand [gh:coin-or/Ipopt@releases/3.14.16].

Intermediate_CB’s exact signature — the previous edition read it “through the Java interface’s parameter list and the ChangeLog” and flagged it. It is twelve typed parameters:

typedef bool (*Intermediate_CB)(
   ipindex  alg_mod,              /* 0 is regular, 1 is restoration */
   ipindex  iter_count,
   ipnumber obj_value, inf_pr, inf_du, mu, d_norm,
   ipnumber regularization_size, alpha_du, alpha_pr,
   ipindex  ls_trials,
   UserDataPtr user_data);
/* "If this method returns false, Ipopt will terminate the optimization." */

Every field §18.3 says it parses — “objective, primal and dual infeasibility, mu, step size, regularization, restoration flag” — is a typed callback argument, not a value scraped from text. And the documented return-false semantics is exactly §18.3’s cancellation mechanism, confirmed at the source.

Recommended amendment H had the wrong function names. It proposed preferring Ipopt_get_curr_iterate / Ipopt_get_curr_violations. Those are the C++ TNLP method names (get_curr_iterate, get_curr_violations). The C interface exports them as GetIpoptCurrentIterate and GetIpoptCurrentViolations. The recommendation stands; the names are corrected.

Binding-layer rules (platform decisions this lookup surfaces)

• IpStdCInterface.h is the source of truth for typedefs, and the exact set at 3.14.16 is ipindex, ipnumber, plus the legacy aliases Index (int), Number, Bool (bool, i.e. C99 stdbool, not an int), UserDataPtr (void*), IpoptProblem (an opaque struct IpoptProblemInfo*), and enum ApplicationReturnStatus [gh:coin-or/Ipopt@releases/3.14.16]. Bool being a real bool matters for the -sys crate’s FFI declarations. Whether the -sys crate uses bindgen at build time or hand-declared extern "C" items is an open choice: bindgen tracks the installed header (safer across Ipopt builds), hand-declaration keeps the build hermetic and reproducible (§20.4 cares about reproducibility). Open decision — recommend bindgen with the generated bindings committed and diffed in CI, mirroring §4.2’s treatment of generated relation code.
• Index style. CreateIpoptProblem takes an index-style argument (0 = C style) [gh:coin-or/Ipopt@releases/3.14.16]; the sparsity pattern from compiled.incidence is 0-based, so C style is correct and must be asserted, not assumed.
• Never unwind through a callback. A Rust panic — or a salsa cancellation unwind (C5) — crossing the C boundary is undefined behaviour. Callbacks must catch, record the failure in the user_data state, and return false; the driver then converts that into solve.evaluation_error or runtime.cancelled (§23.2) after IpoptSolve returns. This is the single most important rule in this cluster and neither §18.2 nor §18.3 currently states it.
• Version floor. Ipopt_get_curr_iterate/Ipopt_get_curr_violations require Ipopt ≥ 3.14 [c7:/coin-or/ipopt]. §20.3 already records solver versions in the run environment; add a capability probe alongside the existing linear_solver = ma57 probe (§18.3) so an older Ipopt degrades to text-parsed iterations rather than failing.

Gaps and risks

• Linking and distribution. How Ipopt (and HSL/MUMPS) is located, linked and redistributed is untouched by the blueprint and by this lookup — static vs dynamic, pkg-config, vendored build. It determines whether pse-backend-native builds on a fresh machine. Open item, out of scope for a capability map but on the critical path.
• The exact Intermediate_CB C typedef was read through the Java interface’s parameter list and the ChangeLog [c7:/coin-or/ipopt]; take the precise C signature from IpStdCInterface.h at implementation time.

13. Pass 3 — the under-leverage sweep

Passes 1 and 2 both start from the blueprint, so neither can find a capability it never gestured at. This pass takes each library on its own terms and asks what it offers that bears on a named blueprint requirement and is not claimed. Charter §G and DM-58 apply throughout: a row naming no principle and replacing no identified work does not appear.

The denominator is §1.5’s extraction — 26 crates, 589 public traits. Most of that surface is irrelevant to this design and is dismissed by cluster rather than enumerated.

14. Principle-alignment register (supporting libraries)

Capabilities and disciplines that 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.

The previous edition had no register and cited no DM principle at all — the only one of the four capability maps in that position. Its findings were real; they were simply never connected to the charter. Numbering is local to this map.

Adopt

Evaluate

Reject, with reason

15. Acceptance-gate review (supporting libraries)

The earlier survey’s gates described revision 2. Current document-stage gates are assessed in the revision-5 review. The following are Proposed platform contracts; historical library receipts do not certify their implementation.

16. Leverage matrix

One row per blueprint requirement that rests on a supporting library. Read this first.

17. Evidence ledger

Every lookup performed, in order. c7 = context7 plugin; WebFetch = docs.rs/crates.io; rustdoc = the local extraction of §1.5; probe = a program compiled against the pinned crates.

Rows 1–52 are the previous edition’s. The five rows whose instrument read local cited files that no longer exist; each now records what replaced it, and none is load-bearing any more. Rows 53–64 are this edition’s.

18. Open questions, with recommendations

The earlier survey’s amendment requests are reconciled below. Evidence sections and receipts remain the original observations; this is a decision update, not a new full-library probe run. Current pins are owned by Cargo.toml and Cargo.lock.

Use plan 02 for the revision-5 implementation handoff. Unchanged specialized numerical/provider questions remain unverified until their actual consumer is implemented and exercised.