AEON GP Document v1

Convention identifier: aeon.gp.document.v1

Status

Draft document metadata convention

Purpose

aeon.gp.document.v1 defines a standard vocabulary for document-level metadata.

This metadata describes:

• authorship
• origin
• lifecycle
• classification
• discoverability
• machine handling hints

The convention applies to metadata stored inside the AEON header.

Location

Document metadata lives inside:

Example:

Metadata Container

All document metadata is stored in a document object.

This keeps metadata separate from processing fields.

Metadata Fields

Identity

Fields:

Authorship

Fields:

Copyright and Rights

Fields:

Document Lifecycle

Fields:

Classification

Fields:

Privacy and Handling

Example values:

The exact semantics may be defined by profiles.

Content Format

Examples:

• report
• message
• dataset
• contract
• log
• configuration

This field describes the conceptual type of document.

Generation Metadata

Example values:

This can help downstream consumers evaluate provenance.

Robot Handling

Examples:

• index
• noindex
• noai
• noarchive

This mirrors common web document conventions.

Cache Hints

Examples:

• cache
• no-cache
• no-store

This field is advisory and intended for systems distributing AEON documents.

Reference Information

Examples:

• internal id
• document reference number
• archival identifier

Example Complete Header

Design Goals

The document convention aims to provide:

• human-readable metadata
• machine-readable classification
• interoperability across tools
• minimal structural complexity

It is intentionally flexible so that different domains can extend or interpret the fields according to their needs.

Relationship to Other Conventions

This convention complements the AEON ecosystem:

Summary

aeon.gp.document.v1 provides a lightweight but structured vocabulary for describing AEON documents themselves, allowing tools and systems to understand authorship, classification, lifecycle, and handling policies without interfering with the document’s actual data structure.

====

Language Metadata

Purpose

The language field identifies the natural language used in the document.

This helps with:

• indexing
• translation
• search
• AI processing
• accessibility tools

Recommended Format

Use BCP-47 language tags, which are already used by:

• HTML
• HTTP
• XML
• many APIs

Example tags:

Example

If multiple languages appear:

Best practice is to list the primary language first.

Location Metadata

Purpose

The location field indicates the geographic context of the document.

This may represent:

• where the document was created
• where the subject matter applies
• geographic relevance

Recommended Structure

Location should be structured rather than a free string.

Example:

Using ISO-style identifiers where possible improves interoperability.

Geographic Codes

Recommended standards:

Coordinates (Optional)

If precise location matters:

This is useful for:

• geographic datasets
• environmental records
• sensor data
• field observations

Updated Example Header

Design Principle

The document convention should remain lightweight.

Good fields for this layer:

• authorship
• lifecycle
• classification
• language
• location
• handling hints

It should not try to model domain data, only the document itself.

Small Optional Addition (Nice Future-Proofing)

One more field that often proves useful:

This tracks document revision independent of the integrity envelope.

Where We Are Now

With this addition, your AEON ecosystem now has conventions covering:

Data interpretation

• aeon.gp.convention.v1

Context annotation

• aeon.gp.context.v1

Document metadata

• aeon.gp.document.v1

Security

• aeon.gp.security.v1
• aeon.gp.integrity.v1
• aeon.gp.signature.v1
• aeon.gp.encryption.v1

Advanced integrity (informative)

• Merkle subtree hashing
• tamper-evident event logs

That’s a very complete first-generation ecosystem.

===

separate the metadata container from the metadata vocabulary

In practical terms:

• aeon.gp.document.v1 should define the vocabulary
• but AEON should settle on one stable header metadata container shape

That keeps things simple now, but very extensible later.

The idea

Instead of every convention inventing its own top-level header layout, you standardize something like:

So:

• aeon:header = stable metadata container
• document = document metadata block defined by aeon.gp.document.v1

Why this is powerful

Because later you can add other metadata vocabularies without changing the outer shape.

Example:

That gives you a header metadata bus, basically.

Why it matters long-term

Without this, ecosystems drift into:

• document = {...}
• aeon:header = {...}
• info = {...}
• headerMeta = {...}
• properties = {...}

and then every tool has to special-case each shape.

With a stable container, you get:

• predictable tooling
• simpler validation
• clearer convention boundaries
• easier future growth

The deeper architectural benefit

It gives AEON a very clean layered model:

aeon:header

core processing metadata

aeon:header

document/header metadata container

named metadata sections

convention-defined vocabularies such as:

• document
• context
• future publication
• future provenance

So the improvement is really:

standardize the header chassis, not just the metadata fields

Minimal rule

You do not need much. Just something like:

Header metadata intended for conventions should be placed directly under aeon:header. Individual conventions define named sub-objects within that header.

That one rule keeps the whole system tidy.

Example final shape

Why I think this is the right move

Because it stays simple now, but prevents header chaos later.

So the long-term improvement is not “add more fields.” It is:

**make meta the stable metadata framework, and let conventions plug into it cleanly.**

That would make AEON’s metadata story much stronger.