&ND v2

+++document/meta
schemaVersion = "1"
id = "aeon-gp-convention-v1"
title = "AEON GP Convention v1"
description = "Draft convention-authoring template for creating focused AEON general-purpose conventions."
family = "conventions"
group = "General-Purpose Conventions"
standing = "official"
lifecycle = "draft"
normativity = "informative"
license = "CC0-1.0"
path = "specification/conventions/aeon-gp-convention-v1"
order = 30
publish = true
keywords = ["AEON", "general-purpose convention", "authoring template", "governance"]
related = ["aeon-conventions-overview"]
+++


# AEON GP Convention v1 [# aeon-gp-convention-v1]

Convention identifier: [$ aeon.gp.convention.v1]

---


## 1. Purpose [# purpose]

[$ aeon.gp.convention.v1] is a focused template for designing new AEON conventions.

It does not define a broad shared vocabulary.
Instead, it describes the shape a convention specification should follow so independently authored conventions remain
predictable and interoperable.

Use this template when creating a new convention such as:

~~~$ text
aeon.gp.measurement.v1
aeon.gp.document.v1
org.example.finance.v1
~~~$

---


## 2. Convention Design Rule [# convention-design-rule]

A convention should define one coherent interpretation domain.

Good convention scopes:

- document metadata
- measurement labels
- temporal values
- collection semantics
- security envelope structure
- domain-specific finance labels

Avoid mixing unrelated vocabularies into a single convention.

---


## 3. Recommended Document Structure [# recommended-document-structure]

A convention specification should include:

1. Purpose
2. Scope
3. Design goals
4. Non-goals
5. Reserved vocabulary
6. Processing or interpretation rules
7. Unknown-key behavior
8. Validation posture
9. Examples
10. Relationship to other conventions

Not every convention needs every section, but each convention should make its scope and non-goals explicit.

---


## 4. Vocabulary Guidance [# vocabulary-guidance]

Reserved keys defined by a convention should be:

- lowercase ASCII identifiers
- narrowly scoped
- stable within the version
- descriptive rather than imperative

Unknown keys should remain opaque unless a schema, profile, processor, or another convention defines them.

---


## 5. Processing Guidance [# processing-guidance]

Conventions define interpretation agreements.

They should not:

- alter AEON core syntax
- redefine canonicalization
- create hidden execution semantics
- require processors to infer behavior not declared by the convention

If behavior depends on policy, algorithms, trust, or runtime choices, define that behavior in a profile or processor
specification rather than in the base convention.

---


## 6. Dependency Guidance [# dependency-guidance]

If a convention depends on another convention, state that dependency explicitly.

Example:

~~~$ text
aeon.gp.signature.v1
requires
aeon.gp.integrity.v1
~~~$

Dependencies should be narrow and justified.

---


## 7. Example Convention Skeleton [# example-convention-skeleton]

~~~$ markdown
# AEON Example Convention v1

Convention identifier: `org.example.topic.v1`

# 1. Purpose

Define the interpretation domain.

# 2. Scope

State what is covered and what is not covered.

# 3. Reserved Vocabulary

List reserved keys or structures.

# 4. Processing Rules

Describe how consumers should interpret the vocabulary.

# 5. Examples

Show minimal and realistic examples.
~~~$

---


## 8. Relationship to the Overview [# relationship-to-the-overview]

General rules for declaring conventions, convention modes, naming, versioning, and processing belong to the AEON
Conventions Overview.

Individual convention documents should focus on the vocabulary and behavior they define.