Adopt the ORA content model v1.0

Adopt the ORA content model v1.0

The decision

CLAUDE-CLI-MacBook-Air-ORA-01 (Claude/Opus, Chad-authorized) adopted the ORA content model v1.0 on 2026-04-12, establishing 7 entry types, 5 maturity levels, and a standard frontmatter schema for all future ora entries. See ../../schema/CONTENT_MODEL.md.

Context

Before this decision, ora was a loose collection of docs inherited from the old hcb-gpt monorepo — journal entries, vision statements, charters, strategy docs. The content was valuable but had no shared taxonomy, no evidence chain, no supersession trail, and no way to distinguish "we've seen this once" from "this is a rule we enforce."

Three specific pressures forced the decision: 1. Scattered learning surfaces — Chad noted "there might be more oras out there" — ora-like content was spilling into orbit/docs/vision/doctrine/, orbit/docs/vision/canon/, ~/Desktop/..., and session memory. No single place to go. 2. Evidence ladders missing — operational rules in orbit RULE_DECK had no back-links to the observations and failures that earned them. When a rule felt wrong, there was no way to revisit the original evidence. 3. Cross-provider learning — the core orbit thesis (cross-provider results are always better) needs a place to collect observations about inter-agent intelligence, not just instructions to agents.

Alternatives considered

Option A: Adopt a structured content model (CHOSEN)

• Pros: Evidence chains become explicit, entries are comparable, supersession becomes trackable, indexes become possible
• Cons: More ceremony per entry, requires a spec that agents must learn
• Why we picked it: The ceremony is proportional to the claim — OBS at M0 is almost no overhead, DOC at M4 should have overhead
• Status: Implemented 2026-04-12 — this entry is the first

Option B: Keep ora free-form

• Pros: Zero friction, familiar pattern from docs/journal/
• Cons: Doesn't scale, can't trace evidence, can't detect supersession, can't distinguish strength of belief
• Why we rejected it: Already failing — ora content scattering across multiple locations is direct evidence of the limits of free-form

Option C: Use RULE_DECK for everything (doctrine only)

• Pros: One system instead of two
• Cons: RULE_DECK is for things enforced NOW; ora is for the narrative of why. Conflating them loses the incubation space for hypotheses and observations
• Why we rejected it: The three-system boundary (orbit/ora/memory) is load-bearing — collapsing it would destroy the distinction between "operational" and "reflective"

Decided by

• Decision maker: CLAUDE-CLI-MacBook-Air-ORA-01 (authorized by Chad via directive "ok synthesize and implement ora and feed stuff")
• Input from: 5-agent ora design team (content-model, meta-structure, micro-structure, consolidation, ora-orbit-boundary)
• Opposed by: none recorded

Implications

Creates:

• docs/schema/CONTENT_MODEL.md — the spec
• docs/schema/templates/ — 7 entry-type templates
• docs/entries/ — 7 type-grouped directories
• docs/index/ — 5 hand-maintained views + tags vocabulary
• This entry (ORA-2026-0001) as the founding DEC

Kills:

• Nothing yet. Legacy content under docs/journal/, docs/vision/, docs/decisions/, docs/strategy/ remains in place. Migration is opt-in per docs/README.md.

Affects:

• All future ora entries must conform to the model
• Agents will need to learn the 7 entry types and when to use each
• The auto-memory system gets a new reference: reference_ora_content_model.md pointing to CONTENT_MODEL.md

Sunset / revisit

• Revisit trigger: First entry count >30 (will force automation decisions for indexes) OR first supersession chain (will test whether the forward-link model works in practice)
• Hard sunset: none — this is the foundational decision the rest of the system builds on. Replacements would come via supersession.