AAT Part III
Signature and Theorem Boundary
Architecture Signature is a multi-axis diagnostic of selected obstruction families. Theorem boundaries state what a package can conclude and, just as importantly, what it does not conclude.
Architecture Signature
`ArchitectureSignature` records coordinates of selected obstruction families. Static, boundary, abstraction, projection or LSP, runtime, semantic, operation, extension, and analytic axes may all appear, but they do not collapse into one score.
ArchitectureSignature(X)
= coordinates of selected obstruction families of X
Measurement status
Every axis carries a status. `measured_zero`, `measured_nonzero(value)`, `unmeasured`, `out_of_scope`, `private_unavailable`, and `not_applicable` are different claim states. `unmeasured` is not simply a worse numeric value than `measured_zero`; it is a boundary on what can be compared.
- Structural coordinates Static, boundary, abstraction, projection, and operation-level obstruction readings.
- Semantic and runtime coordinates Observation and runtime exposure readings that require their own evidence.
- Empirical readings Cost and product outcomes are not required zero axes inside AAT.
Signature record
A signature coordinate is a typed claim, not just a number in a dashboard. The coordinate records the axis, the measured or unmeasured status, the claim level, the universe in which it was produced, the evidence that supports it, and the claims that are explicitly not being made.
SignatureCoordinate
= axis
+ measurement status
+ value when measured
+ claim level
+ universe / coverage boundary
+ evidence references
+ non-conclusions
This is why two reports cannot be compared merely because they both contain a value. The coordinate must be read together with its boundary and its axis-specific order.
Measurement semantics
A signature is useful only if its coordinates preserve the difference between value and status. The value says what was measured on an axis; the status says whether that measurement can be read as evidence for a claim.
- `measured_zero` The selected witness universe has a zero value for that axis under the recorded boundary.
- `measured_nonzero(value)` A selected obstruction or risk coordinate was measured and remains nonzero.
- `unmeasured` The axis has not been observed; this is not the same claim as zero.
- `out_of_scope` / `not_applicable` The axis is outside the selected universe or does not apply to the object being read.
This semantics lets AAT compare architectures without turning unknowns into zeros or forcing all axes into one total order.
| Claim | Current Lean status | Boundary | Non-conclusion | Source |
|---|---|---|---|---|
| Architecture Signature as multi-axis diagnostic | `defined only` / `proved` for required-axis bridge packages | Selected axes, measurement status, and explicit theorem boundary. | Does not rank architectures by one scalar quality value. | Lean theorem index, signature entries. |
| Measured zero versus unmeasured status | `proved` for current required-axis availability / zero bridges | Axis availability and exactness assumptions must be recorded. | `none`, missing, private, or out-of-scope evidence is not zero. | AAT Status and theorem index. |
| Empirical cost or product outcome reading | `empirical hypothesis` | Requires separate dataset, calibration protocol, and artifact boundary. | Not a Lean theorem and not a required zero-axis claim. | Proof-obligation ledger. |
Theorem boundary
A theorem boundary packages selected universe, required laws, invariant family, witness universe, coverage assumptions, exactness assumptions, operation preconditions, conclusion, and non-conclusions. It prevents a bounded formal result from being read as a global architecture claim.
TheoremBoundary
= selected universe
+ required laws
+ invariant family
+ witness universe
+ coverage assumptions
+ exactness assumptions
+ operation preconditions
+ conclusion
+ non-conclusions
Static split does not imply runtime or semantic flatness, and absence of a selected witness does not imply global absence.
Claim levels
A signature coordinate is not only a number. It also carries a claim level and a measurement boundary. A formal coordinate is backed by a theorem boundary; a tooling coordinate is produced by an extractor or validator; an empirical coordinate belongs to a dataset or calibration protocol; a hypothesis is a future research claim.
- formal A Lean-backed or theorem-boundary-backed statement under explicit assumptions.
- tooling An artifact produced by a scanner, validator, report, or workflow with its own evidence boundary.
- empirical / hypothesis A repository, operation, or outcome claim that is not promoted to theorem status.
Comparison rules
Signature comparison is axis-local. Two reports are comparable only where the same axis is present on both sides, measured under compatible assumptions, and equipped with a meaningful order. Missing evidence, private evidence, or a changed measurement universe breaks that comparison rather than contributing a numeric zero.
ComparableAxes(S1, S2)
+ MeasuredOnBoth(axis)
+ AxisOrder(axis)
+ compatible boundary
-> compare selected measured axes
Non-conclusions
`ArchitectureSignature` does not rank architectures by one scalar quality value. It does not make unmeasured axes safe, turn private evidence into measured zero, infer runtime or semantic flatness from a static split, or claim empirical cost reduction from a formal zero-axis theorem.
The public site treats Signature as a multi-axis diagnostic. Any product, cost, or workflow reading must preserve the theorem boundary and the artifact boundary that produced the coordinate.