This document defines the constrained vocabulary of Outcomes-Driven Development. It governs how language is used before elevation to Canon — ensuring precision at the point of origin, not retroactive clarification.
Why This Exists
Language drifts. Terms get overloaded. Meanings blur under repetition.
In ODD, ambiguous language creates:
- misaligned expectations
- false confidence in shared understanding
- governance that sounds rigorous but isn't
This document exists to:
- constrain vocabulary — fewer terms, tighter meanings
- disambiguate collisions — clarify where everyday usage differs from ODD usage
- establish boundaries — define what terms do NOT mean
Namespace Ontology
ODD vs Canon
| Namespace | Role | Contains |
|---|---|---|
odd/ | Discipline, operating system, rules of motion | How thinking and work happen |
canon/ | Elevated truths distilled from experience | What survived that process |
Key relationships:
- ODD feeds Canon, but does not live inside it
- Canon may reference ODD
- ODD is not canon, and not subordinate to it
- Language governance (this document) belongs to ODD — it constrains canon formation
Why this matters:
If terminology lived under canon/, language would appear post hoc. ODD would look like a justification layer. By keeping it under odd/, we're saying: "This discipline governs how meaning is formed — before truth is elevated."
Core Terms
ODD (Outcomes-Driven Development)
ODD meaning: Outcomes-Driven Development — an approach to building software that prioritizes real-world results over artifacts. In an AI-accelerated environment, the limiting factor is no longer production speed; it is clarity of intent, quality of verification, and the ability to choose among outcomes. ODD makes those constraints explicit.
Not: A framework, a fixed workflow, or a claim that outcomes can be fully predicted.
Core thesis: The primary job of development is not writing code. It is defining outcomes, enforcing constraints, and verifying reality. AI accelerates execution; governance preserves trust.
Test: Are decisions governed by verifiable outcomes, or by artifacts and activity?
See: /odd/README.md for the public introduction, /odd/manifesto.md for the extended operational framework.
Outcome
ODD meaning: A verifiable state of reality that can be demonstrated, not just described.
Not: A deliverable, artifact, feature, or checkbox.
Test: Can you show it working? If explanation is required to prove it exists, it's not an outcome yet.
Evidence
ODD meaning: Observable proof that an outcome occurred. Must be reproducible or recorded.
Not: Explanation, confidence, or expert assertion.
Test: Could a skeptic verify this independently?
Artifact
ODD meaning: A byproduct of work — code, documents, diagrams. Ephemeral by default.
Not: The goal. Not proof of value.
Test: If this disappeared, would the outcome still be demonstrable?
Elevation
ODD meaning: The deliberate act of promoting a verified truth from working memory to Canon.
Not: Filing, archiving, or organizing.
Requirements:
- Evidence exists
- The insight has survived stress
- The statement is stable enough to govern future decisions
Canon
ODD meaning: The curated body of truths that have earned permanence through verification and survival.
Not: A knowledge base, wiki, or documentation dump.
Test: Does this statement constrain future decisions? If not, it's reference material, not canon.
Attempt
ODD meaning: A bounded execution against a defined goal. Has a start, an end, and produces evidence.
Not: A try, experiment, or vague effort.
Requirements:
- Explicit goal
- Bounded scope
- Evidence captured (success or failure)
Lane (Historical)
ODD meaning: A parallel track of work with its own lifecycle, evidence, and maturity state. Lanes were a structural concept in ODD v1–v2 that prescribed directory conventions (products/<lane>/). As of v3.0.0, ODD is structure-agnostic — the concept of independent project evolution remains, but "lane" as an organizing primitive has been retired in favor of dynamic epistemic routing via OddKit.
Not: A branch, feature, or workstream in the general sense.
Key property: Projects can evolve independently while sharing governance.
Maturity
ODD meaning: The phase of a project that determines appropriate rigor level.
Phases:
- PoC (Proof of Concept) — Learning, speed, disposable artifacts
- Pilot — Proof, repeatability, early governance
- Production — Trust, durability, handoff readiness
Not: Quality, completeness, or age.
Disambiguation Table
| Common Term | ODD Meaning | Common Misuse |
|---|---|---|
| "Done" | Evidence exists proving outcome | Code merged, ticket closed |
| "Works" | Verified under realistic conditions | Passed tests, "looks right" |
| "Documented" | Captured for future governance | Written down somewhere |
| "Tested" | Stress-tested against failure modes | Happy path confirmed |
| "Shipped" | Outcome delivered and verifiable | Artifact deployed |
Anti-Patterns in Language
Confidence as Evidence
"I'm confident this works" is not evidence. Confidence is a feeling. Evidence is observable.
Explanation as Proof
"Let me explain why this is correct" is not proof. Explanations can be fluent and wrong. Demonstrations are harder to fake.
Activity as Progress
"I worked on this for hours" is not progress. Time spent is input. Outcomes are output.
Artifact as Outcome
"The code is written" is not an outcome. Code is an artifact. The outcome is what the code enables when verified.
Boundary Conditions
What This Document Does NOT Define
- Domain-specific terms — Each product/project may extend vocabulary within its scope
- Implementation details — How tools or systems work internally
- Opinions — This is constraint, not preference
When to Extend
New terms may be proposed when:
- Existing vocabulary cannot express a necessary distinction
- The term has been used consistently across multiple attempts
- Ambiguity has caused actual confusion or failure
Extensions follow the same elevation process as any canon candidate.
Usage Guidelines
For Authors
- Use terms as defined here, not as commonly understood
- When a term might be ambiguous, link back to this document
- If you need a word not defined here, check if an existing term suffices first
For Reviewers
- Flag terminology drift — when ODD terms are used with non-ODD meanings
- Distinguish between "this word is wrong" and "this concept needs a new word"
For Canon Documents
- Canon documents should link here when term precision matters
- Do not duplicate definitions — reference, don't repeat
Evolution Process
This document evolves through:
- Observation — A term collision or ambiguity causes friction
- Proposal — A clarification or new term is suggested
- Stress test — The proposal is used in practice
- Elevation — If it survives, it enters this document
Changes require evidence of the problem being solved.
Language is not neutral. The words we use shape what we can think.
ODD constrains vocabulary not to limit expression, but to increase precision where it matters.