Same subject matter as the architecture room, opposite direction of travel: what would have to be observed for the design claim to fail?
| Technical claim | Test |
|---|---|
| Rust deterministic verification | Same bundle, same result, in an independent environment |
| Portable verifier | Runs without the Rails plane |
| Python thin integration | External developer, minimal bespoke semantics |
| Canonical primitives | Three heterogeneous systems, one primitive set |
| Profile separation | Change method or profile without rewriting evidence |
| Rails commercial boundary | Paid operation without proprietary lock-in dependency |
| Artifact portability | Recipient uses the package outside the AgEvidence UI |
| Claim | Status | Falsifier |
|---|---|---|
| Thin-waist architecture can generalise | Open | A second or third independent source requires customer-specific core semantics. |
| Rust verification is portable | Demonstrated | The offline verifier requires proprietary hosted state to resolve a bundle. |
| Python integration can remain thin | Open | Every integration requires AgEvidence engineers to model the customer's domain. |
| One evidence chain can serve two uses | Open | The second destination requires the source evidence to be re-derived. |
Determinism is testable today. Heterogeneity and external reliance are not testable in-house at all — which is why they are gates, not milestones.
Is the capability specified, implemented, demonstrated, or independently reproduced? What command, fixture, export or third-party reconstruction supports it? What observation would show that a claimed boundary is fictional?
Technical diligence still identifies production-hardening work in parts of the trust boundary; a working path is not a finished trust boundary.
The native reading. Claim status, evidence burden, proof gates, falsifiers, contradictions, capital-to-proof, governance, downside, and explicit reasons to stop or narrow the thesis.