intelligence-radar/C3ResearchDeliverablesStandard.md

title	short_title	version	status	artifact_type	scope
C3 Research Deliverables Standard	C3ResearchDeliverablesStandard	0.1	initial	methodology	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

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:

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

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:

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:

repository/
├── catalog/
├── compendium/
└── concepts/

These are the normative C3 deliverable directories.

A larger research repository MAY additionally contain supporting directories such as:

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:

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:

compendium/

Question 2

Is the main purpose to enumerate and compare identified things?

If yes:

catalog/

Question 3

Is the main purpose to design, propose or explore something that does not yet exist in established form?

If yes:

concepts/

Question 4

Is the artifact primarily an investigation, dated analysis, source review or working research result?

If yes:

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:

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:

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:

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:

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:

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

---
title: "..."
artifact_type: compendium
status: active
last_reviewed: YYYY-MM-DD
evidence_level: E0-E6
---

Catalog

---
title: "..."
artifact_type: catalog
status: active
schema_version: "0.1"
last_updated: YYYY-MM-DD
---

Concept

---
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:

catalog/
├── BenchmarkCatalog.md
├── MechanismCatalog.md
└── IndicatorCatalog.md

Concepts

Concepts SHOULD normally use the actual mechanism or design name.

Examples:

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:

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

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

catalog/
└── ConsumerCapitalMechanismCatalog.md

Enumerates patronage dividends, mutual ownership, customer shares, loyalty-to-equity programmes, profit participation, warrants and diversified customer funds.

Concept

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:

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:

research/

Stage 2 — Repeated evidence

Structured in:

catalog/

or synthesized into:

compendium/

Stage 3 — Design implication

Developed in:

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:

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:

research-project/
├── catalog/
├── compendium/
├── concepts/
└── README.md

---

19. Recommended research repository

For continuously operated research systems such as intelligence-radar:

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.