Zero Trust

AEON only makes guarantees it can actually verify.

Validity is not truth.

AEON aligns with zero-trust architecture by refusing to assume that a document is true, authoritative, or safe to materialize merely because it is well-formed.

An AEON processor can observe syntax, structure, type declarations, validation rules, and canonical representations. It cannot directly observe author intent, source authority, external-world state, or whether a claim is true.

Principle

AEON operates with epistemic humility.

The practical rule is simple: do not claim knowledge you do not possess. A parser can confirm that a value is present and shaped correctly; it cannot confirm that reality matches the value.

temperature:number = 25

ObservableAEON can verify that the document is syntactically valid, the value is a number, and the structure conforms to an adopted schema.

Not observableAEON cannot verify that the temperature is actually 25 degrees, that the sensor was calibrated, or that the reading is current.

BoundaryThose questions exist outside the transport layer and require external evidence or authority.

Form Not Truth

AEON validates form; truth requires evidence outside the document.

Form asks whether the text is valid AEON, whether it conforms to schema, whether declared types are compatible, and whether the document can be processed safely under the chosen policy.

Truth asks whether a measurement is accurate, a statement is honest, data is current, or reality matches the claim. AEON does not answer those questions by itself.

Form:
- Is this valid AEON?
- Does it conform to the schema?
- Are declared types compatible?
- Can the document be processed under the selected policy?

Truth:
- Is this measurement accurate?
- Is this statement honest?
- Is this data current?
- Does external reality match the claim?

Trust Layers

Each layer answers a different trust question.

Implementations should never assume that success at one layer implies success at another. A valid document is not automatically intact, authentic, authorized, or true.

Validity

Definition
Is this a valid AEON document? Verified by the parser and validator. Result: the document can be processed under that layer's rules.

Integrity

Definition
Has the document been altered? Verified by hashes or digital signatures. Result: received content matches the content that was hashed or signed.

Authenticity

Definition
Who created or signed this document? Verified by identity systems, certificates, public keys, or trust chains.

Authority

Definition
Is this source permitted to make this claim? Verified by business rules, governance systems, trust policies, or domain authority.

Truth

Definition
Is the claim actually correct? Verified by independent evidence, audits, observation, corroboration, or measurement.

Signatures

Digital signatures establish provenance, not truth.

A signature can prove who signed a document and that the signed bytes were not modified after signing. It does not prove that the signer was honest, competent, authorized, or correct.

temperature:number = 25

If a weather station signs that document, the signature proves that the station reported 25. It does not prove that the temperature was actually 25. The sensor may be broken, misconfigured, stale, or outside its authority.

Transport

AEON should be treated as zero-trust transport.

Every claim inside an AEON document starts as untrusted. The document can carry the claim clearly, and the consumer can then choose which checks, schemas, policies, evidence, or materializers to apply.

user:email = "alice@example.com"

The document claims that the value is an email address. A consumer may verify the format, check that the mailbox exists, confirm ownership, or apply business rules. AEON itself does not perform those external checks.

Non-Executable

AEON avoids executable behavior inside the data stream.

Many formats blur data and instructions through embedded scripts, runtime expressions, dynamic imports, network lookups, reflection, or object instantiation. Those features require the system to trust claims made by the data stream itself.

AEON intentionally avoids that behavior. The document describes data. The consumer decides what actions, if any, should be taken.

Implementation

Implementation guidance: keep claims and conclusions separate.

Incorrect:
- The document is valid, therefore the information is true.
- The document is signed, therefore the information is true.
- The document came from a trusted organization, therefore every claim is true.

Correct:
- The document is valid.
- The document was signed by the expected source.
- The document has not been modified.
- Additional verification is required before trust can be established.

AEON deliberately limits its guarantees to what can be directly verified: deterministic parsing, structural validation, type validation, safe transport, and unambiguous representation.

It does not guarantee authenticity, authority, accuracy, or truth. Those concerns belong to systems with the necessary context and evidence.

Conclusion

AEON transports assertions; it does not establish truth.

A valid document may be false. A signed document may be false. A document from an authoritative source may be false. Determining truth requires evidence beyond the transport layer.

By refusing to make claims it cannot prove, AEON remains predictable, composable, and compatible with zero-trust architectures.

View as Markdown