Application as Data Representation Standard (AADR)
AADR is an emerging Aptlantis standard for application-as-data representation records, component maps, relationship maps, and related architecture documentation.
:::info Status Candidate v1.0.3. :::
Document Suite
| File | Purpose |
|---|---|
Application as Data Representation Standard.md | Primary AADR specification wrapper. |
AADR.manifest.toml | Standard manifest. |
Adoption-Guide.md | AADR adoption procedure. |
Validation-Checklist.md | AADR readiness checklist. |
CHANGELOG.md | AADR version history. |
Existing source material remains under AptlantisEcosystem/Standards — see Aptlantis Ecosystem for context on that product and its preserved reference copies.
SFDS Suite Model
AADR.manifest.toml describes AADR as a standard suite. The templates in templates/ and preserved source materials describe representation records governed by AADR.
Scope
AADR governs emerging application-as-data representation patterns, architecture records, composable application descriptions, and related ecosystem documents.
:::note Does Not Govern AADR does not govern desktop release evidence, CLI command output, workspace root placement, or visual theme contracts. :::
Required Artifacts
- Primary specification.
- Representation examples.
- Adoption notes.
- Compatibility notes.
- Changelog.
- Representation record.
- Source architecture references.
- Known limits.
Core Philosophy
AADR treats application structure as data that can be inspected, transformed, reasoned about, and preserved.
The goal is not to replace source code. The goal is to create durable representation records that describe application components, relationships, artifacts, and intent in a form that humans and agents can recover.
Relationship to WGS and SFDS
WGS registers where an application or representation project lives. SFDS governs AADR as a standard suite. AADR governs representation records that describe applications or systems as structured data.
Representation Record Requirements
An AADR representation record should identify:
- Representation target.
- Purpose.
- Components.
- Relationships.
- Inputs and outputs.
- Artifacts.
- Runtime or execution model when relevant.
- Source architecture notes.
- Compatibility limits.
- Known gaps.
- Maintainer and review date.
Representation Levels
| Level | Meaning |
|---|---|
sketch | Target and purpose are known, but structure is incomplete. |
mapped | Components and relationships are recorded. |
usable | Record can guide implementation, generation, audit, or migration work. |
validated | Examples or tooling prove the representation can be consumed. |
archived | Record is preserved for historical or recovery use. |
Compatibility Rules
Representation records must state:
- Which application or system version they describe.
- Whether the representation is descriptive or executable.
- Whether it is complete or partial.
- Which consumers or tools are expected to understand it.
- What changes would make the representation stale.
Validation
A representation is ready when another maintainer or agent can:
- Identify the target.
- Understand the component map.
- Follow relationships.
- Find source references.
- Recognize known limits.
- Avoid mistaking a partial representation for a complete one.
Adoption Blockers
AADR adoption is blocked when:
- Representation target is unclear.
- Components are unnamed.
- Relationships are missing.
- Source architecture notes are absent.
- Compatibility limits are not recorded.
- The record implies executability when it is only descriptive.