846 lines
19 KiB
Markdown
846 lines
19 KiB
Markdown
---
|
|
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.
|