ORA

Schema

ORA Content Model

ORA = "what we have learned while building (primarily) orbit about inter-agent intelligence."

This is the authoritative spec for how ora entries are structured, classified, and evolved. Every new ora entry MUST conform to this model.

1. Purpose

ORA is not code. It is not session continuity. It is not operational rules enforced by runtime.

ORA is the durable narrative of what we learned and why. It exists because: 1. Fleet sessions produce insights that would otherwise evaporate 2. Operational rules in orbit need a trail back to the evidence that produced them 3. Hypotheses about inter-agent intelligence need a place to incubate before they become doctrine

2. The Three-System Boundary

SystemScopeDecay
orbitOperational rules enforced NOW. RULE_DECK cards, charter sections, TRAM protocol.Changes only via decision record.
oraThe narrative of why — observations, patterns, experiments, failures, the path from evidence to doctrine.Evolves via maturity levels + supersession.
memorySession continuity — who Chad is, what we're working on, recent context.Short-term; pruned aggressively.

Litmus test: If you want to enforce something tomorrow, it goes in orbit. If you want to remember why we enforce it, it goes in ora. If you want the next session to know it exists, it goes in memory.

3. Entry Types

ORA has 8 entry types. Every entry declares one in its frontmatter.

TypeCodeWhat it capturesExample
ObservationOBSA thing that happened. No interpretation yet."STRAT session 11 burned 3 agents on a dead lane before catching the collision."
PatternPATA recurring shape across ≥2 observations. Interpretation, not yet tested."Agents in parallel lanes converge on identical fixes when they lack shared lane awareness."
SynthesisSYNA cross-entry integration that names what several entries, artifacts, or operator directives mean together."Fleet antagonism dynamics elaborate six related doctrines into one operating frame."
HypothesisHYPA testable claim derived from patterns. Has a concrete falsification path."Adding lane-check to dispatch will reduce collision-driven rework by >50%."
ExperimentEXPA run against a hypothesis. Describes setup, metric, outcome."Ran lane-check dispatch on 2026-04-08. Collisions dropped from 4/day to 0."
DoctrineDOCA distilled rule with enough evidence to justify enforcement."Collision Guard: always git log --since before dispatching code work."
DecisionDECA choice Chad/STRAT/fleet made, with context and alternatives considered."Split hcb-gpt into 4 repos (orbit/camber/heartwood/ora) on 2026-04-12."
FailureFALA specific failure worth preserving — what broke, why, what we learned."Feed append clobbering incident on CAMBER FEED.md, 2026-04-08."

Invariant: Every DOC must trace to at least one EXP or FAL. Every EXP must cite a HYP. Every HYP must cite PAT or OBS. The chain OBS → PAT → HYP → EXP → DOC is the evidence ladder. A SYN entry is connective tissue: it can cite any entry type or source artifact, but it does not by itself promote evidence up the ladder unless a later PAT, HYP, EXP, or DOC cites it and names the promotion.

4. Maturity Levels

Entries progress through 5 maturity levels. An entry can stall at any level — that's fine, the level tells the reader how much trust to give it.

LevelNameMeaning
M0RawCaptured once, not yet corroborated. Default for new OBS and FAL.
M1CorroboratedObserved by ≥2 independent sources (different agents, sessions, days).
M2TestedRun through at least one EXP with a declared metric.
M3ProvenResults replicate. Evidence holds across ≥3 runs or extended observation.
M4CanonicalElevated to doctrine. Enforced somewhere in orbit (RULE_DECK, charter, boot protocol).

Who sets maturity: The author sets M0/M1. M2 requires a linked EXP. M3 requires a pass in the index. M4 requires a linked orbit enforcement artifact (e.g., a RULE_DECK card ID).

5. Lifecycle

Orthogonal to maturity, every entry has a status in its lifecycle:

StatusMeaning
draftIn progress, not yet reviewable.
reviewedAnother agent or Chad has read and signed off.
canonicalActive, load-bearing. Referenced by orbit or other ora entries.
supersededReplaced by a newer entry. Must link forward via superseded_by.

An entry can be canonical at M1 (e.g., a well-documented failure that everyone agrees happened) or draft at M3 (e.g., evidence is strong but the write-up isn't polished). Status ≠ maturity.

6. Frontmatter Schema

Every entry begins with YAML frontmatter:

---
id: ORA-YYYY-NNNN
type: PAT
date: 2026-04-12
author: STRAT-01
author_provider: claude
confidence: 0.7
status: draft
maturity: M1
tags:
  - inter-agent
  - collision
  - dispatch
sources:
  - ORA-YYYY-AAAA
  - ORA-YYYY-BBBB
supersedes: null
superseded_by: null
related:
  - ORA-YYYY-RRRR
---

Required fields:

Optional fields:

Why provider matters: Ora is about inter-agent intelligence. Tracking which provider authored what lets us see patterns in how different models perceive and classify events. This is a chromatic verification hook — disagreement across providers is signal, not noise.

Doctrine tier semantics

tier is required on doctrine entries after the FLT-1340/FLT-1342 backfill lands. During the transition window, a missing tier on an existing doctrine means "unclassified legacy doctrine," not Tier 1 by default.

---
id: ORA-YYYY-NNNN
type: DOC
maturity: M3
tier: 2
---
TierNameLoading contractTypical shape
1Boot hot zoneEligible for inline provider boot surfaces. Capped at 5-7 active doctrines.Judgment shapers that should influence every task even before a narrower reference is loaded.
2Mechanical enforcementReferenced by ID plus validator/helper/runtime gate when possible.Rules that should be caught by feed-append, doctrine-parity-check, git hooks, launchd checks, templates, or other machinery.
3Reference libraryLoaded on demand by ID, tag, domain, or task trigger.Valuable doctrine for specific contexts that should not compete for every boot's active attention.

Changing the Tier 1 set is a governance change, not a drive-by edit. It requires a feed peer-sync addressed to Chad and the active ORA lane STRAT with an explicit response menu. Tier 2/3 classification can be applied mechanically once the Tier 1 list is acknowledged or the ticket's stated timeout expires.

7. Body Structure

After the frontmatter, every entry has a body. Minimum viable body:

# {short title}

## Summary
One paragraph. What is this entry about?

## Evidence
For OBS/FAL: what happened, when, where, who saw it.
For PAT: what observations point to this pattern.
For SYN: what sources are being integrated and what new frame or clarification emerges.
For HYP: what pattern this is testing, what the falsification looks like.
For EXP: setup, metric, result.
For DOC: the rule, plus links to the EXPs that earned it.
For DEC: the choice made, alternatives considered, who decided, when.

## Implications
What this means for fleet operations, orbit enforcement, or future work.

## References
Links to TRAM messages, git commits, feed posts, memory files, or external docs.

Type-specific templates live in schema/templates/.

8. ID Generation

IDs are monotonic within a year. To generate the next ID: 1. List entries/*/.md frontmatter ids 2. Filter to current year (ORA-YYYY-*) 3. Take max, add 1 4. Run scripts/ora-entry-id-guard.sh before committing so filename, frontmatter, and heading identity stay unique.

A helper script can automate this; manual is fine for now.

Reserved range: ORA-YYYY-0001 through ORA-YYYY-0099 are reserved for founding entries — things we retroactively import from old docs, CEO sessions, or vision statements. New live entries start at ORA-YYYY-0100.

9. Supersession Rules

When an entry is replaced: 1. New entry declares supersedes: <old-id> 2. Old entry is updated with superseded_by: <new-id> and status: superseded 3. Old entry is NOT deleted — it stays in place as history 4. The supersession chain is discoverable via index/supersession_chains.md

A superseded entry MAY be cited as a source — the fact that we used to believe X and later believed Y is itself evidence of how our understanding evolved.

10. What Does NOT Belong in ORA

11. Version

This content model is v1.2 (2026-05-03). Changes to the model itself are tracked as type: DEC entries with tags: [ora-meta].