Using the AAMT Substrate: Integration Points and Wiring Status

WP-23 specifies what the .aamt substrate is — the binary format and the mechanisms built on it. WP-24 explains how the platform is architected and how that compares to other systems. Neither answers the question this paper exists to answer: given all of that, what do I actually call, in which language, and is it running anywhere yet? That last clause matters — a mechanism can be built, tested exhaustively, and exposed identically across four language bindings, and still not be called by a single production code path. This paper draws that line explicitly rather than letting “implemented” quiet mean two different things. As of this writing: four mechanisms are live (called by a real, running consumer today) — pack/query, soft routing, the Odu cross-session profile feeding WP-22's escape steering, and the lineage journal. Five are library-ready — built, exhaustively tested, exposed through the C ABI and all three bindings, called by nothing yet — mirror pairing, RS(15,13)/GF(16) redundancy, the composed RS+mirror read path (WP-23 §13.1), CRDT convergence with persisted replica identity (WP-23 §13.2), and columnar bulk export. One is research-only — echo refocusing, which validates an operator's math but has no measured evidence yet that any real subsystem needs it. Section 5's original framing — that wiring a library-ready mechanism in takes a real decision, not just a call site — has, for two of these, now been resolved rather than just stated: what a caller does with an unrecoverable mirror mismatch and how a second CRDT writer gets a safe identity are both implemented, tested policies as of this revision, not open questions. Section 2 is the audited table; section 3 is a working code snippet for each mechanism; section 4 is how to build each layer; section 5 is what integrating a library-ready mechanism would concretely require, stated as engineering decisions rather than “just call the function.”