--- title: "C3 Research Deliverables Standard" short_title: "C3ResearchDeliverablesStandard" version: "0.1" status: "initial" artifact_type: "methodology" scope: "research repositories" --- # C3 Research Deliverables Standard **C3ResearchDeliverablesStandard** is a lightweight methodology for organizing research results into three distinct classes of durable deliverables: 1. **Compendium** — what we know. 2. **Catalog** — what we have identified. 3. **Concepts** — what we propose or explore. The standard is intended for research repositories that continuously collect evidence, synthesize knowledge, design new ideas, and revise their understanding over time. Its purpose is to keep three fundamentally different epistemic activities separate: > **describing the world, inventorying the world, and designing possible changes to the world.** The three classes deliberately share the letter **C**, giving the method its name: > **C3 = Compendium + Catalog + Concepts** --- # 1. Why C3 exists Research repositories tend to accumulate heterogeneous Markdown files: - literature reviews; - definitions; - taxonomies; - benchmark lists; - hypotheses; - design ideas; - source summaries; - proposed mechanisms; - research notes; - experiments; - datasets; - conclusions. Without a clear information architecture, these gradually become difficult to interpret. A polished speculative design may start to look like established knowledge. A catalog entry may acquire narrative interpretation and become difficult to process systematically. A compendium may become a dumping ground for every interesting fact. C3 separates durable research output by **epistemic purpose** rather than by topic. The standard asks three questions: > **What do we know?** > **What things have we identified?** > **What could we create or change?** Each question has one canonical home. --- # 2. The three deliverable classes ## 2.1 Compendium — What do we know? The **Compendium** contains synthesized research knowledge. A compendium document explains the best current understanding of a subject based on available evidence. It may integrate theory, definitions, literature, empirical findings, competing explanations, historical development, uncertainty, unresolved questions and conclusions. A compendium is not merely a collection of sources. Its purpose is to transform source material into an increasingly coherent model of a subject. ### Compendium question > **What is currently justified to believe about this subject?** ### Typical artifacts - `IntelligenceCompendium.md` - `EconomicsOfMachineIntelligence.md` - `TransformativeAICompendium.md` - `AgencyAndMotivation.md` - `HistoryOfConsumerOwnership.md` ### Compendium quality criterion A good compendium should make clear: - what is known; - how strongly it is known; - what is disputed; - what evidence supports the current view; - what remains unresolved. ### Directory ```text compendium/ ``` --- ## 2.2 Catalog — What have we identified? The **Catalog** contains structured inventories of identifiable entities, mechanisms, observations, patterns, sources or categories. A catalog is designed primarily for enumeration, comparison, retrieval, classification, coverage analysis and machine processing where useful. It should favor explicit fields and repeatable structure over long narrative prose. ### Catalog question > **What relevant things exist, and how can they be systematically described and compared?** ### Typical artifacts - benchmark catalog; - model catalog; - thinker catalog; - mechanism catalog; - policy catalog; - indicator catalog; - failure-mode catalog; - experiment catalog; - source catalog; - use-case catalog. Examples: ```text catalog/ ├── AIBenchmarkCatalog.md ├── EconomicIndicatorCatalog.md ├── ConsumerCapitalMechanismCatalog.md ├── ParticipationCapitalFailureModeCatalog.md └── ThinkerCatalog.md ``` ### Catalog quality criterion A good catalog should be: - systematically structured; - extensible; - internally consistent; - explicit about inclusion criteria; - suitable for comparison; - easy to update without rewriting the whole artifact. --- ## 2.3 Concepts — What could we create or change? The **Concepts** area contains proposed mechanisms, candidate architectures, designed interventions, hypotheses developed into concrete models, and possible solutions. Concept documents are intentionally allowed to be speculative. Their purpose is not to claim that something already works. Their purpose is to make an idea sufficiently explicit that it can be criticized, modeled, compared, simulated, prototyped or tested. ### Concept question > **What might work, and how exactly would it work if we built or adopted it?** ### Typical artifacts - `CustomerEarnedEquityDesign.md` - `IndividualParticipationCapitalAccount.md` - `AdaptiveTransitionBuffer.md` - `SovereignAIAssuranceNetwork.md` - `ConsumerParticipationDividend.md` ### Concepts quality criterion A good concept should make clear: - the problem it addresses; - its mechanism; - actors and incentives; - expected benefits; - assumptions; - design parameters; - trade-offs; - failure modes; - evidence level; - how it could be tested. ### Directory ```text concepts/ ``` --- # 3. The core epistemic distinction The three C classes represent different relationships to reality. ## Compendium > **Models of the world** The compendium tries to explain reality. ## Catalog > **Inventory of the world** The catalog identifies and structures relevant things in reality. ## Concepts > **Possible changes to the world** Concepts propose interventions, mechanisms and designed alternatives. This distinction is the heart of C3. The same topic may legitimately appear in all three forms: ```text compendium/ └── ConsumerOwnership.md catalog/ └── ConsumerOwnershipMechanismCatalog.md concepts/ └── CustomerEarnedEquityDesign.md ``` These files are not duplicates. They answer different questions. --- # 4. Directory standard A C3-compliant research repository SHOULD contain the following root-level directories: ```text repository/ ├── catalog/ ├── compendium/ └── concepts/ ``` These are the **normative C3 deliverable directories**. A larger research repository MAY additionally contain supporting directories such as: ```text repository/ ├── catalog/ ├── compendium/ ├── concepts/ ├── data/ ├── digests/ ├── research/ └── README.md ``` These supporting directories are not part of the C3 deliverable taxonomy itself. --- # 5. Supporting directories ## 5.1 `research/` Contains working research artifacts such as dated investigations, exploratory notes, source reviews, literature scans, hypothesis exploration and preliminary analyses. Research files may be temporary or durable, but they have not yet necessarily been normalized into C3 outputs. Typical form: ```text research/ └── 2026-09-14-transformative-ai-strategy-assessment.md ``` A research file may later update one or more C3 deliverables. ## 5.2 `digests/` Contains time-bounded summaries of change such as daily intelligence digests, weekly research digests, monthly policy updates and benchmark change summaries. Digests answer: > **What changed during this period?** They are chronological rather than epistemically canonical. ## 5.3 `data/` Contains raw or normalized research material intended for analysis, including CSV, JSON, YAML, benchmark observations, measurement exports and structured source metadata. Data supports C3 artifacts but is not itself a C3 deliverable. --- # 6. Placement decision rule When creating a durable research artifact, ask the following questions in order. ## Question 1 **Is the main purpose to explain the current state of knowledge?** If yes: ```text compendium/ ``` ## Question 2 **Is the main purpose to enumerate and compare identified things?** If yes: ```text catalog/ ``` ## Question 3 **Is the main purpose to design, propose or explore something that does not yet exist in established form?** If yes: ```text concepts/ ``` ## Question 4 **Is the artifact primarily an investigation, dated analysis, source review or working research result?** If yes: ```text research/ ``` until its results are incorporated into one or more C3 deliverables. ## Question 5 **Is the artifact primarily a time-bounded summary of recent change?** If yes: ```text digests/ ``` --- # 7. The C3 research flow C3 is not intended as a rigid pipeline. Research can move between all three classes. A common pattern is: ```text research ↓ compendium ↓ concept ↓ catalog / experiment ↓ evidence ↓ research ↓ updated compendium ``` A more abstract formulation is: > **Understand → Invent → Enumerate → Test → Learn** The important principle is that **concepts do not silently become facts**. Evidence generated by testing a concept must return through research and eventually update the compendium. --- # 8. Concept maturity Concept artifacts SHOULD declare their maturity explicitly. Recommended maturity values: ```yaml maturity: - hypothesis - exploratory - modeled - simulated - prototyped - tested - validated - operational ``` Meaning: - `hypothesis` — the core causal idea has been stated. - `exploratory` — the mechanism has been elaborated and alternatives considered. - `modeled` — actors, incentives and expected dynamics have been formalized. - `simulated` — the concept has been exercised in a simulation or analytical model. - `prototyped` — a working implementation exists. - `tested` — the concept has been tested against observations or experiments. - `validated` — multiple lines of evidence support the concept under specified conditions. - `operational` — the concept is used in a real system. A concept reaching `validated` or `operational` maturity may generate new compendium knowledge, but the concept document itself remains a concept artifact. --- # 9. Evidence maturity C3 artifacts SHOULD distinguish maturity of an idea from strength of evidence. A recommended evidence scale is: ```text E0 — intuition E1 — historical analogue E2 — observational evidence E3 — quasi-experimental evidence E4 — randomized evidence E5 — replicated cross-context evidence E6 — operational proof at meaningful scale ``` Example: ```yaml artifact_type: concept maturity: modeled evidence_level: E2 ``` A highly detailed concept may therefore remain weakly evidenced. Conversely, a simple mechanism may have strong empirical evidence. This distinction prevents sophistication of presentation from being mistaken for certainty. --- # 10. Recommended metadata C3 documents SHOULD include concise frontmatter. ## Compendium ```yaml --- title: "..." artifact_type: compendium status: active last_reviewed: YYYY-MM-DD evidence_level: E0-E6 --- ``` ## Catalog ```yaml --- title: "..." artifact_type: catalog status: active schema_version: "0.1" last_updated: YYYY-MM-DD --- ``` ## Concept ```yaml --- title: "..." artifact_type: concept status: active maturity: exploratory evidence_level: E1 last_reviewed: YYYY-MM-DD --- ``` Metadata should remain lightweight. C3 is intended to improve thinking, not create administrative overhead. --- # 11. Naming guidance C3 does not mandate one filename convention, but filenames SHOULD reveal artifact purpose. ### Compendium Use `...Compendium.md` or a plain subject name where directory placement is sufficient. ### Catalog Use `...Catalog.md`. Examples: ```text catalog/ ├── BenchmarkCatalog.md ├── MechanismCatalog.md └── IndicatorCatalog.md ``` ### Concepts Concepts SHOULD normally use the actual mechanism or design name. Examples: ```text concepts/ ├── CustomerEarnedEquityDesign.md ├── AdaptiveTransitionBuffer.md └── IndividualParticipationCapitalAccount.md ``` A suffix such as `Design`, `Architecture`, `Mechanism`, or `Model` may be useful where ambiguity exists. --- # 12. Cross-linking between C3 artifacts C3 artifacts SHOULD reference related artifacts from other classes when those relationships are meaningful. Example: ```yaml related_compendium: - ../compendium/ConsumerOwnership.md related_catalogs: - ../catalog/ConsumerCapitalMechanismCatalog.md related_concepts: - ./IndividualParticipationCapitalAccount.md ``` Narrative cross-links are equally acceptable. The objective is to make the knowledge graph visible without requiring a dedicated graph database. --- # 13. Example: Customer-Earned Equity The Customer-Earned Equity topic illustrates C3 well. ## Compendium ```text compendium/ └── ConsumerOwnership.md ``` Answers: - What forms of consumer ownership already exist? - What does research say? - What economic theory applies? - What effects are empirically supported? ## Catalog ```text catalog/ └── ConsumerCapitalMechanismCatalog.md ``` Enumerates patronage dividends, mutual ownership, customer shares, loyalty-to-equity programmes, profit participation, warrants and diversified customer funds. ## Concept ```text concepts/ └── CustomerEarnedEquityDesign.md ``` Designs eligibility, accrual rules, capitalization, dilution, matching, diversification, portability, rights, tax treatment and failure controls. --- # 14. Anti-patterns ## 14.1 The Everything Compendium Do not put every observation, source, idea and design proposal into the compendium. The compendium should represent synthesized knowledge. ## 14.2 The Narrative Catalog Do not let catalog entries evolve into essays. If extensive interpretation is needed, move it into the compendium. ## 14.3 The Concept Presented as Fact A concept SHOULD clearly state assumptions, maturity and evidence. A polished design is still a design. ## 14.4 The Research Note That Becomes Canon by Age Old research notes do not automatically become authoritative because nobody revisited them. Durable conclusions should be incorporated into the compendium. ## 14.5 Duplicate Truth Avoid maintaining the same canonical explanation in multiple places. Prefer: ```text compendium → canonical explanation catalog → canonical enumeration concept → canonical proposed design ``` Other artifacts should link to these. --- # 15. Lifecycle of a research result A typical result may evolve as follows. ### Stage 1 — Observation Captured in: ```text research/ ``` ### Stage 2 — Repeated evidence Structured in: ```text catalog/ ``` or synthesized into: ```text compendium/ ``` ### Stage 3 — Design implication Developed in: ```text concepts/ ``` ### Stage 4 — Experiment Recorded as research/data. ### Stage 5 — Validation or falsification Updates `compendium/`, `catalog/`, and/or `concepts/` as appropriate. The repository therefore accumulates knowledge without erasing its developmental history. --- # 16. C3 and research governance C3 supports three complementary forms of governance. ## Knowledge governance The compendium provides the current synthesized view. ## Coverage governance The catalog reveals what has and has not been systematically identified. ## Innovation governance The concepts directory exposes speculative ideas explicitly, making them reviewable without confusing them with established knowledge. This separation helps reviewers ask better questions: - **Compendium:** Is this conclusion supported? - **Catalog:** Is this inventory complete and consistently classified? - **Concept:** Could this mechanism work, and how would we know? --- # 17. C3 as an epistemic safety mechanism C3 is deliberately more than directory organization. It reduces several recurring research errors: - speculation becoming fact through repetition; - catalogs being mistaken for explanation; - source volume being mistaken for knowledge; - mature prose being mistaken for mature evidence; - proposed interventions being evaluated as if already validated; - experimental outcomes failing to update canonical understanding. C3 therefore acts as a lightweight **epistemic type system**. In programming terms: ```text Compendium : KnowledgeModel Catalog : StructuredInventory Concept : ProposedIntervention ``` Mixing those types should be treated as a design smell. --- # 18. Minimal C3 repository The minimum compliant structure is: ```text research-project/ ├── catalog/ ├── compendium/ ├── concepts/ └── README.md ``` --- # 19. Recommended research repository For continuously operated research systems such as `intelligence-radar`: ```text intelligence-radar/ ├── catalog/ │ ├── benchmarks/ │ ├── indicators/ │ ├── mechanisms/ │ └── sources/ │ ├── compendium/ │ ├── intelligence/ │ ├── economics/ │ ├── technology/ │ └── policy/ │ ├── concepts/ │ ├── economics/ │ ├── infrastructure/ │ └── governance/ │ ├── data/ │ ├── raw/ │ ├── normalized/ │ └── derived/ │ ├── digests/ │ ├── daily/ │ └── weekly/ │ ├── research/ │ └── YYYY/ │ └── YYYY-MM-DD-*.md │ └── README.md ``` Subdirectories SHOULD emerge only when volume justifies them. The three top-level C directories remain the stable semantic anchors. --- # 20. C3 placement lint Before accepting a new durable artifact, apply this quick check. ### Compendium lint - Does it synthesize rather than merely list? - Does it distinguish evidence from uncertainty? - Is it describing current knowledge rather than proposing a design? ### Catalog lint - Does it enumerate identifiable things? - Are entries structurally comparable? - Can new entries be added without rewriting the whole artifact? ### Concept lint - Is it proposing something? - Are assumptions explicit? - Are mechanism and actors clear? - Are failure modes considered? - Is maturity/evidence stated? If the artifact fails all three tests, it probably belongs in `research/`, `data/`, or `digests/`. --- # 21. Standard summary The **C3ResearchDeliverablesStandard** organizes durable research output into three semantic classes: | Class | Core question | Function | |---|---|---| | **Compendium** | What do we know? | Synthesize knowledge | | **Catalog** | What have we identified? | Structure inventories | | **Concepts** | What could we create or change? | Design possibilities | Supporting material remains outside the C3 taxonomy: | Directory | Function | |---|---| | `research/` | Investigations and working research | | `digests/` | Time-bounded change summaries | | `data/` | Raw and structured evidence | The fundamental rule is: > **Compendium = models of the world.** > **Catalog = inventory of the world.** > **Concepts = possible changes to the world.** Operationally: > **Understand → Invent → Enumerate → Test → Learn.** C3 is intentionally small. Its value comes from maintaining the distinction consistently.