SEMANTIC ATLAS
APIR 0.2 / EXPERIMENTAL
A contract for semantic compilation.
APIR is an experimental intermediate representation for source-grounded commitments. The specification separates canonical meaning, provider rendering, and assurance evidence.
A portable semantic layer needs explicit types, explicit omissions, and explicit limits more than it needs another universal prompt format.
04.1
The APIR document
An APIR document binds metadata, sources, commitments, relationships, render profiles, and provenance into one inspectable unit.
Stable identifiers let later stages refer to a commitment without copying or paraphrasing its source. Fingerprints allow integrity checks across transformations.
Canonical fields remain separate from codec extensions so provider-specific capabilities cannot leak into the meaning contract by accident.
- 01DOCUMENT
- 02SOURCES
- 03COMMITMENTS
- 04RELATIONS
- 05PROVENANCE
04.2
Commitment anatomy
A commitment describes what is asserted, required, prohibited, preferred, assumed, observed, unresolved, or expected as output.
Its kind, modality, criticality, status, source span, and dependencies are machine-readable. Human-readable content remains available for review.
The taxonomy supports precise loss reporting: dropping a preference is not equivalent to dropping a safety boundary.
- Kinds describe semantic role.
- Modality describes force or obligation.
- Criticality controls admissible omission.
- Status preserves uncertainty and conflict.
04.3
Receipt anatomy
The receipt records the transformation rather than narrating a success story.
It identifies inputs, selected commitments, omissions, target profile, renderer version, output fingerprint, checks, and assurance statuses.
A structurally complete receipt can still report unknown target uptake. That distinction is a required feature, not a caveat to hide.
- 01INPUT HASH
- 02SELECTION
- 03OMISSIONS
- 04OUTPUT HASH
- 05ASSURANCE VECTOR
04.4
Conformance is layered
Implementations should declare the exact level they support instead of claiming generic compatibility.
A parser can conform to the schema without implementing budgeting. A renderer can produce a candidate pack without proving target uptake. A verifier must name the properties it checks.
Public schema changes require examples, tests, version notes, and migration impact before they can be treated as complete.
- Schema conformance
- Canonicalization conformance
- Rendering profile conformance
- Receipt conformance
- Assurance evidence conformance