OCG Cognitive Handbook

Open Cognitive Graph · Handbook v1.0

Cognitive Handbook · First Edition

Contents

• Chapter 1: Why Cognition Needs Structure
• Chapter 2: The Minimal Unit of Cognition
• Chapter 3: How Cognition Becomes a System
• Chapter 4: How Cognition Is Used
• Chapter 5: How to Start

Chapter 1: Why Cognition Needs Structure

The most valuable human knowledge is not stored in databases

It lives in expert judgment, in researchers' chains of reasoning, and in evaluators' sense of why one answer is better than another. It exists implicitly. Because it is implicit, it cannot be reliably transferred, audited, or executed.

Imagine a situation: you need to evaluate whether an educational method truly develops higher-order cognition. You bring in a domain expert. The expert says, "This method is good." You ask why. The answer is, "An experienced person can tell."

That answer is not necessarily wrong. But it has a fundamental problem: it cannot be transferred. Another expert may reach a different conclusion. Another institution may apply a different standard. When the expert leaves, the judgment disappears.

This is not a problem with experts. It is a problem with how knowledge is expressed.

Existing knowledge systems, including knowledge graphs, primarily solve storage and retrieval. But the real challenge is rarely "Where is the knowledge?" The real challenge is "Why does this inference hold?"

A knowledge graph tells you that A and B are related, and what type of relation connects them. It is a map that describes the terrain of knowledge. But a map does not tell you under what conditions to take a route, what evidence supports a judgment, who made the assertion, or whether the same relation still holds in another context.

OCG addresses a different problem.

Knowledge Graph vs. OCG

This is not an incremental upgrade. It is a shift in level: from recording knowledge to running cognition.

Explication: OCG's core task

Higher-order human cognition, including expert judgment, research reasoning, and evaluative standards, has always existed. But it has existed implicitly inside human minds, without a form that can be externalized.

OCG does one central thing: it brings that structure out.

This process is called explication. Explication is not note-taking, summarization, or annotation. It gives reasoning structure a runnable form, turning judgment that used to depend on apprenticeship into a structure that can be transferred, audited, and executed by systems.

Once explicated, implicit cognition gains four new capabilities:

• Transferable: judgment structures can be shared across people and institutions
• Auditable: every step has source, context, and status
• Executable: structured reasoning can drive system behavior
• Cumulative: knowledge does not disappear when a person leaves; it can evolve

Tool-independent

OCG is a cognitive methodology, not a specific software system.

Any tool that can carry cognition can run OCG:

• Paper modeling: researchers manually draw domain cognitive structures
• Human collaboration: teams jointly construct and review reasoning records
• AI assistance: natural-language documents are converted into cognitive structures
• Automation: systems continuously update, validate, and execute graphs

The methodology is decoupled from implementation. OCG can begin in a researcher's notebook or run inside an institutional decision system. The entry barrier is understanding the grammar, not mastering a particular technology stack.

Where this handbook fits

Before reading further, it is useful to place this handbook within the OCG documentation system.

OCG has three kinds of documents, answering three different questions:

Cognitive Handbook: Why model this way? How should OCG's core concepts be understood? For researchers, institutional decision-makers, and domain modelers encountering OCG for the first time.

Formal Specification: Field definitions, type constraints, state machines, validation rules, APIs, and conformance classes. For engineers and standards contributors implementing OCG systems.

Domain Profile / Project Handbook: How does a specific domain, such as education, environmental assessment, medicine, or governance, implement OCG? It contains domain-specific relation vocabularies, context registries, and evaluation rubrics.

These documents form a stack: the cognitive handbook provides understanding, the formal specification provides constraints, and domain profiles provide implementation paths.

> Cognitive anchor > > The core challenge of knowledge is not storage or retrieval. It is the trustworthiness of reasoning. OCG gives implicit cognition a runnable structure through explication. It is a cognitive grammar, independent of any specific tool.

Chapter 2: The Minimal Unit of Cognition

Three basic objects

Before understanding CDC, we need to understand three basic objects in OCG. They form the vocabulary foundation of the system.

Concept: cognitive object

A Concept is a cognitive unit in OCG. It is not the same as a database entity, nor is it merely a noun label.

A Concept is a semantically stable cognitive structure. Within a domain, experts share an understanding of what it means. It can participate in reasoning and can act as the subject or object of relations.

Examples:

• chronic insomnia is a Concept in sleep medicine
• variation transfer ability is a Concept in cognitive assessment
• VOCs is a Concept in atmospheric environmental assessment

A Concept does not exist in isolation. Its meaning depends on its domain. The same word may correspond to different Concepts in different domains.

Relation: cognitive mechanism

A Relation is the tool OCG uses to express cognitive mechanism. It is not a generic association. It describes why two Concepts are related and by what mechanism they are connected.

OCG defines several core relation families:

• Structural relations: is-a, part-of, includes, depends-on
• Logical relations: requires, implies, contradicts, not-a
• Analogical relations: analogous-to, maps-to, transfers-to
• Contextual relations: valid-in, constrained-by, interpreted-as, contested-in

The key point: in OCG, Relations are directional, typed, and must be bound to a Domain. A Relation without a Domain is incomplete.

Domain: the context in which a relation holds

Domain is one of OCG's most important designs and one of the sharpest differences from ordinary knowledge graphs.

A Domain states: under what conditions a Relation holds.

The relation causes means one thing in a diagnostic domain, another in a treatment domain, and something else again in a statistical-correlation domain. Domain turns a relation from a global assertion into a contextual assertion. A relation is valid only in the Domain where it is declared.

This design prevents reasoning from sliding across contexts. Every relation becomes an auditable, bounded expression of mechanism.

Domain format:

@{field}.{subdomain}.{framework}

Examples:

@subject.mathematics.algebra
@education.ai_literacy.teacher_education
@environment.atmospheric.emission_standard

How the three objects relate

Concept  --[Relation @ Domain]--  Concept

This is OCG's most basic expression. Two Concepts plus a Relation that holds in a specific Domain form a minimal semantic unit that can participate in reasoning.

When context declarations, evidence, and provenance metadata are added, this basic structure becomes OCG's core construct: the CDC.

What a CDC says

If the minimal unit of a knowledge graph is a node-and-edge statement, the minimal unit of OCG is a complete reasoning step. It is called a CDC: Context-Dependent Cognitive Unit.

Why a minimal unit is needed

Every runnable system needs atomic operations.

Mathematics has axioms. Programming languages have statements. Knowledge graphs have triples: subject, relation, object. The design of these atoms determines what a system can and cannot do.

The knowledge-graph triple A → relates_to → B expresses that A and B have some relation. But it cannot say under what conditions the relation holds, who asserted it, or what judgment it supports.

CDC starts from this gap. A complete CDC has the following structure:

CDC := ⟨ source concept, relation@domain, target concept, context, evidence, provenance ⟩

Six elements, each with a cognitive function. None is optional in a mature OCG record.

Core design: R@D

The most important design in CDC is R@D: Relation must be bound to Domain.

In ordinary knowledge graphs, relations are global. causes is simply causes, regardless of field or condition.

In OCG, relations are context-dependent. causes@diagnosis and causes@teaching are different relations because their conditions, meanings, and supported judgments differ.

This has a deep implication: OCG does not allow context-free relations. Every relation must declare the Domain in which it holds. This prevents reasoning from drifting across contexts and makes every reasoning step auditable.

CDC examples in three domains

CDC is cross-domain. The same grammar produces different cognitive value in different fields.

Medicine: diagnostic classification

Source: WHO ICD-11 definition of chronic insomnia.

Source concept:  chronic insomnia
Relation@Domain: causes @ functional_impairment
Target concept:  daytime functional impairment
Context:         ICD-11 diagnostic criteria
Source:          WHO ICD-11 · 7A00
Status:          accepted

The same text may also yield:

{ chronic insomnia  is_a        sleep-wake disorder  @ ICD-11 classification }
{ chronic insomnia  has_symptom difficulty sleeping  @ symptomatology        }
{ chronic insomnia  temporal    ≥3 nights/week       @ temporal constraint   }
{ chronic insomnia  temporal    ≥3 months            @ temporal constraint   }

A natural-language paragraph becomes multiple independent, auditable reasoning steps.

Education: capability assessment

Source: systematic observation of learner responses.

Source concept:  high accuracy on routine tasks + low accuracy on transfer tasks
Relation@Domain: indicates @ reasoning_and_transfer_ability
Target concept:  insufficient variation transfer ability
Context:         mathematical concept mastery assessment
Source:          learner performance data
Status:          proposed

This CDC turns an evaluator's implicit judgment, "this learner can solve routine tasks but cannot transfer," into a structured claim that can be reviewed, contested, and updated by later data.

Environmental assessment: impact pathway

Source: industrial emission standards and atmospheric chemistry mechanisms.

Source concept:  coating process uses organic solvent
Relation@Domain: emits @ atmospheric_environment
Target concept:  VOCs
Context:         industrial emission assessment
Source:          GB emission standards / atmospheric chemistry
Status:          accepted

This CDC is the beginning of an impact pathway:

{ VOCs  reacts_with  NOx  @ atmospheric_photochemistry  → forms O₃ }
{ O₃    causes       photochemical smog  @ regional_atmosphere }

Three CDCs chained together form a reasoning path from process decision to environmental impact.

What the six CDC elements do

Source: the starting point of the reasoning step. It may be a concept, ability, event, or observed signal.

Relation@Domain: the mechanism of inference. R@D is OCG's core design: a relation must be bound to a domain to become mechanism, not merely connection.

Target: the endpoint of the reasoning step. The step moves from source to target and expresses a directional cognitive claim.

Context: the interpretive frame. The same CDC can mean different things in different contexts. Context prevents misreading.

Evidence: the support for the claim. It may be literature, expert judgment, experimental data, standards, or observed performance.

Provenance: the responsibility chain. Who created this CDC? When? Through what review process? Provenance makes reasoning traceable.

CDC status: reasoning is alive

Every CDC has a status field that reflects its current epistemic standing:

draft → proposed → accepted → validated → contested → deprecated

This means reasoning in OCG is not static. A CDC can be contested, revised, deprecated, or replaced. Knowledge evolves, and so does reasoning structure. This is a key design of OCG as a living system.

> Cognitive anchor > > OCG's three basic objects are Concept, Relation, and Domain. CDC adds context, evidence, and provenance to form a complete reasoning step. R@D ensures every relation is a context-bound mechanism. CDC is cross-domain: the same grammar produces rigorous reasoning structures in medicine, education, and environmental assessment.

Chapter 3: How Cognition Becomes a System

From one inference to a runnable cognitive structure

A single CDC is the minimal unit of reasoning. But real-world cognition is never isolated. Judgments depend on other judgments. Reasoning connects to reasoning. Eventually, these connections form structures that can support decisions and actions.

This chapter explains how OCG organizes CDCs into a runnable system.

Reasoning graph: a network of CDCs

When multiple CDCs depend on and support one another, they form a Reasoning Graph.

A reasoning graph is a directed graph. Its nodes are CDCs, and its edges express dependency: this reasoning step depends on that reasoning step. Reading a reasoning graph means reading the path by which cognition moves toward a final judgment.

An educational-assessment reasoning graph may look like this:

[ Learner answered a Why question ]
        ↓ identify @ assessment
[ Answer shows boundary-analysis ability ]
        ↓ maps_to @ capability
[ Learner has L3 conceptual differentiation ]
        ↓ requires @ curriculum
[ Learner should enter higher-order content sequence ]
        ↓ triggers @ teaching
[ Personalized learning path is generated ]

Each step is a CDC. Each step has context, source, and status. The whole path moves from a learner response to a teaching action, fully traceable and auditable.

Four-layer system architecture

An OCG system consists of four layers, each with a distinct cognitive function.

Layer 1: Cognition Layer

This is the layer that understands the world. Reality is compressed into Concept, Domain, and Relation. Modelers work here, translating domain knowledge into the language of CDC.

Output: concept space, domain space, relation vocabulary.

Layer 2: Graph Layer

This is the layer that organizes reasoning. Individual CDCs are connected into reasoning graphs, impact pathways, and domain subgraphs.

Output: cognitive graph structures that can be queried and traversed.

Layer 3: Execution Layer

This is the layer where reasoning activates judgment. It contains two core modules:

Card, the decision unit: rules operate over reasoning structures to produce judgments. Is this project compliant? What capability level is this learner at? What risk does this plan contain?

Action, the execution unit: judgments trigger actions, such as reports, tasks, alerts, approvals, or remediation plans.

Layer 4: Feedback Layer

This is the layer where the system evolves. Execution outcomes are written back to the graph, updating CDC status and optimizing reasoning rules. The system learns through use.

The execution core: Card mechanism

Card is the bridge between reasoning structure and system behavior.

Card is consumed by the system, not necessarily displayed directly to users. Users may never see an interface element called "Card." But the system uses Cards to transform graph reasoning into judgment outputs, and those outputs then trigger Actions.

A Card structure:

Card = {
  input:  (concept, relation, domain)
  logic:  judgment rule
  output: status / risk / category / trigger condition
}

Card types correspond to different judgment needs:

• Identification: What is this? What class does it belong to?
• Risk: What risk is present? What level is it?
• Compliance: Does it satisfy a standard? Where is the gap?
• Trigger: Under what condition should a process start?
• Prediction: Given the current structure, what is likely to happen next?

Card is not a hard-coded rule library. Its judgment logic comes from the reasoning structure in the graph. When the graph updates, Card judgments update as well. This is a fundamental difference between OCG systems and traditional rule engines.

From implicit cognition to execution

Putting the four layers together, a complete OCG run looks like this:

real-world input
  → concept extraction (Cognition Layer)
  → relation binding R@D (Cognition Layer)
  → graph generation (Graph Layer)
  → Card computation (Execution Layer)
  → Action trigger (Execution Layer)
  → Outcome writeback (Feedback Layer)
  → structure update (Cognition Layer)

This is a closed loop. It begins with reality, passes through structured cognitive processing, produces action, and feeds results back into the system so that the structure can evolve.

Users do not consume internal structure

OCG interfaces should not expose internal terms such as CDC, Relation, and Domain as the primary user experience. Users consume:

• Domain maps: the core concepts in a domain and how they relate
• Impact pathway diagrams: how a decision or event produces effects
• Project evaluators: structured reports generated from an input project
• Execution centers: tasks, alerts, approvals, and reports in one place
• Outcome tracking: what happened after action, and how the graph updated

The structure runs behind the interface. Users experience judgment and action. This is OCG's design principle of consumability: hide complexity inside the system and surface value through usable interfaces.

> Cognitive anchor > > OCG systems have four layers: cognition, graph, execution, and feedback. Card is the bridge from reasoning to action. Users do not need to see internal structures; they consume judgments, maps, reports, and actions.

Chapter 4: How Cognition Is Used

Three roles, one system

OCG systems involve three kinds of users. They do different work and receive different value. Understanding these roles is the starting point for understanding how OCG is used.

Role 1: Modeler

The modeler compresses reality into OCG.

The modeler's work is to identify the core concepts in a domain, define the relations between them, declare the domains and contexts in which those relations hold, and explicate judgments as CDC records.

The modeler does not have to be a technical expert. What they need is domain knowledge and structured thinking: the ability to answer "under what conditions does this relation hold?"

Inputs include domain literature, expert interviews, curriculum standards, policy documents, experimental data, and any material that contains domain cognition.

Outputs are structured CDC records that form the basis of a domain cognitive graph.

Questions a modeler asks:

• What are the core concepts in this domain?
• What are the most important mechanism relations between these concepts?
• In what domain does each relation hold? What are the boundary conditions?
• What is the source of this judgment? How reliable is it?

Role 2: User

The user obtains judgments and action recommendations from an OCG system.

The user does not need to understand the internal graph structure. They interact with execution-layer interfaces: domain maps, evaluation reports, impact pathways, and action recommendations.

The value is that the user receives judgments supported by source, context, and reasoning chain, rather than an untraceable conclusion.

Typical scenario:

An institutional leader needs to evaluate a new teaching project. They enter a project description into the OCG system. The system matches it to the domain graph and generates a structured evaluation report. Every judgment in the report has a traceable reasoning chain. For example: "This method is classified as L2 cognitive development because it involves examples but does not reach boundary analysis."

The user can accept the judgment or contest it. If contested, the system exposes the supporting CDC chain. The user can inspect the source behind each reasoning step.

This is the fundamental difference: judgments are readable, not black-box outputs.

Role 3: Evaluator

The evaluator uses OCG to measure cognitive ability.

In OCG, assessment is not abstract scoring. It is based on two mutually supporting frameworks: WBCA (Why-Based Cognitive Assessment) and HCB (Human Cognitive Benchmark).

WBCA: Why questions as cognitive assessment

Why Why questions reveal cognition

Assessing cognition faces a basic difficulty: knowledge can be retrieved, but reasoning cannot. A learner who fluently recites a definition and a learner who truly understands the boundary of a concept often look identical in standard tests.

Why questions address this problem.

A well-designed Why question does not ask "What is this?" It asks "Why is X not the same as Y?" It creates a cognitive conflict between two concepts that are often confused. That conflict cannot be resolved by retrieval alone; it requires reasoning.

This means a learner's answer to a Why question directly exposes the structure of their reasoning. Answer quality depends less on how much they know and more on how deeply they reason.

WBCA turns this insight into an assessment framework: by designing structured cognitive-conflict questions, the reasoning process becomes observable and assessable.

Nine levels of Why questions

Not all Why questions measure the same depth of cognition. WBCA classifies cognitive-conflict Why questions into nine levels, from local to systemic.

The higher the level, the broader the cognitive frameworks that must be integrated and the stronger the demand for systemic reasoning.

L0-L4: five levels of reasoning depth

For any Why question, WBCA uses the same ruler to evaluate reasoning depth, regardless of the question level.

The key difference between L3 and L4 is not answer length. It is whether reasoning reaches conceptual boundaries and continues beyond them.

Example Why question: "Why does being able to use AI tools not equal AI literacy?"

L1 answer: "AI literacy includes understanding how AI works, its limitations, and its ethical impacts."

L2 answer: "You can be good at prompt writing but still not understand why AI gives its outputs or when not to trust it."

L3 answer: "Prompt skill is operational and domain-specific. It optimizes interaction with a system whose internal logic is opaque. AI literacy requires epistemic access: the ability to evaluate AI output as a reasoner, not merely as an operator. The boundary condition is that a highly efficient prompt user who cannot detect AI's overconfidence when wrong does not possess AI literacy in any meaningful sense."

L4 answer: Building on L3: "This distinction reflects a broader pattern: the gap between tool fluency and domain understanding. A more interesting question is what the minimum epistemic threshold of AI literacy should be, and whether existing educational frameworks even attempt to define it."

These answers correspond to observable and recordable differences in reasoning depth.

HCB: what cognition should be measured

WBCA provides the assessment tool: Why questions and the L0-L4 rubric. HCB answers another question: what human cognitive capabilities should be measured in the age of AI?

HCB's core claim is that as AI systems perform more knowledge tasks at lower cost, the most differentiated human capabilities are those AI cannot reliably replace: monitoring one's own cognition, evaluating the quality of reasoning, and thinking and designing within complex systems.

HCB organizes these capabilities into three domains and twelve nodes.

Domain 1: Epistemic Regulation

Core question: Do I really understand this, or am I merely repeating it?

This domain measures the ability to monitor and govern one's own cognitive process before engaging complex claims.

Node 1.1 Cognitive awareness: accurately identifying one's current cognitive state, including the difference between genuine understanding and fluent repetition, or evidence-based judgment and intuition.

Node 1.2 Conceptual differentiation: identifying and expressing the boundary conditions of a concept: not only what it includes, but what it excludes and when it applies.

Node 1.3 Tolerance of uncertainty: representing, maintaining, and reasoning effectively under real uncertainty; resisting premature closure and treating "I do not know" as a legitimate epistemic state.

Node 1.4 Blind-spot recognition: identifying systematic patterns in one's cognitive limitations, such as recurring assumptions, ignored perspectives, or invisible viewpoints created by training and experience.

Domain 2: Inferential Reasoning

Core question: Is this conclusion actually supported, and how do I know?

This domain measures the ability to evaluate reasoning quality, both in others' reasoning and one's own.

Node 2.1 Source tracing: reconstructing the source chain of a claim and tracing it back to its evidence base. Source tracing is not citation; it requires rebuilding the reasoning path.

Node 2.2 Assumption identification: surfacing the implicit premises on which an argument depends, especially value assumptions and structural assumptions that are rarely stated.

Node 2.3 Evidence evaluation: assessing how strongly evidence supports a specific conclusion; distinguishing correlation from causation, identifying confounders, and maintaining tension among conflicting evidence.

Node 2.4 Argument reconstruction: identifying structural defects in an argument and reconstructing a more rigorous version. It requires both analysis and construction.

Domain 3: Systems Thinking

Core question: What structure lies behind this, and can I design within it?

This domain measures the ability to understand, analyze, and design within complex adaptive systems.

Node 3.1 Dynamic evolution understanding: understanding a system's current state as a moment in an ongoing trajectory, including the forces that drive change and the feedback mechanisms that sustain or disrupt equilibrium.

Node 3.2 Multi-layer causal analysis: distinguishing proximate, structural, and root causes, and tracing the pathways that connect them. This is the reasoning foundation of effective intervention.

Node 3.3 Structural design: translating analysis into viable structural proposals that are incentive-compatible, robust to failure modes, and capable of evolution.

Node 3.4 Governance thinking: reasoning about multi-party coordination: interests, power relations, legitimacy claims, rule-making, contestation, revision, and cooperation under real conflict.

HCB output: capability profile, not a single score

HCB does not produce one total score. It produces a Capability Profile: a distribution of capability levels across twelve nodes.

A learner may reach L3 in source tracing while remaining at L1 in structural design. This differentiated profile is HCB's core output, because it points directly to where cognition is developing and where intervention is needed.

Capability profiles can be used at three granularities:

• Individual: track a person's capability development over time
• Institutional: map a group's cognitive capability distribution and guide curriculum design
• Policy: compare capability levels across institutions and identify systemic gaps

Cognitive structure is source-neutral

WBCA and HCB describe human cognitive assessment. But OCG's assessment framework has a deeper property:

It does not care where the cognitive output came from.

An expert report, an AI-generated reasoning chain, and a learner's answer to a Why question all face the same OCG question: what is the reasoning structure? Are the relations context-bound? Do the judgments have source and status?

Any output that can be structured can be modeled, constrained, and assessed in OCG.

This matters directly in the age of AI. When an institution uses AI-assisted decision-making, the question is not simply "Is this AI good enough?" The question is "Does this AI output have an auditable reasoning structure?" OCG provides the grammar needed to answer that question.

In other words: assessing cognition is not assessing humans or machines. It is assessing reasoning structure itself.

How the three roles relate

These roles are not isolated. Together they maintain the cognitive cycle of an OCG system:

Modelers explicate domain cognition into graphs. Users obtain judgments and actions from those graphs. Evaluators use WBCA and HCB to measure cognitive capability. Assessment results feed back into the graph and update its structure.

This is a cognitive ecology, not a one-way tool.

Cognitive triangle: OCG's underlying logic

The three roles reveal OCG's underlying cognitive structure:

Knowledge (reasoning)
      ↓
Behavior (capability)
      ↓
Judgment (decision)
      ↓
    Cognition

Knowledge is explicated through reasoning structure. Reasoning structure supports the expression of capability. Capability is transformed into measurable judgment through WBCA and HCB. Judgment drives decisions and actions.

CDC is the carrier of this triangle. It carries knowledge, behavior, and judgment at the same time. This is why CDC can be described as "data as reasoning": to read a CDC is already to perform a reasoning step.

> Cognitive anchor > > OCG's assessment system consists of WBCA and HCB. WBCA makes reasoning visible through cognitive-conflict Why questions. HCB defines twelve human cognitive capabilities that matter in the AI era. Together they provide a source-neutral assessment grammar: any cognitive output, human or AI, can be structured and evaluated. The object of assessment is reasoning structure itself.

Chapter 5: How to Start

The entry point is a domain problem, not a technology stack

Using OCG does not require building a system first or learning every concept in advance. The only requirement is this: you have a domain, and you want the core judgments in that domain to become visible, transferable, and auditable.

That is enough.

Step 1: choose a domain problem

The best entry point is a judgment task you already perform but cannot make transparent.

Examples:

• We evaluate learners' higher-order thinking, but the standard exists only in reviewers' minds
• We analyze policy impact pathways, but the reasoning chain is not recorded
• We conduct compliance review, but the judgment basis is scattered across documents
• We design curriculum sequences, but "why this comes before that" has never been explicated

Any such scenario is an entry point for OCG modeling.

Step 2: identify core concepts and relations

In the chosen domain, identify the most important concepts and the key relations between them.

No exhaustive modeling is needed at the start. OCG's modeling principle is: start with the most important reasoning and expand gradually.

Ask:

• What concepts are central in this domain?
• What mechanism relations between these concepts matter most?
• Under what conditions does this relation hold? Under what conditions does it not?
• Where does this judgment come from?

Step 3: write the first CDC

Write your first judgment in CDC format. It does not need to be perfect. It needs to exist.

Source concept:  [your domain concept]
Relation@Domain: [relation type] @ [domain name]
Target concept:  [target concept]
Context:         [the context where this relation holds]
Source:          [evidence or basis for the judgment]
Status:          draft

Writing the first CDC often reveals hidden questions. Is this relation truly causal, or merely correlational? Does it hold in this domain but not another? Is the source an authoritative document, or simply a convention?

Those questions are already the value of explication.

Five stages for modelers

Cognitive explication is not a one-time action. It has stages, and each stage creates a different kind of value.

Modeling: turn implicit judgment into visible structure. Domain reasoning that once existed only inside experts' minds gains a transferable form.

Stabilization: give structure credibility. After review, source annotation, and status declaration, a CDC becomes a cognitive claim that can be cited, contested, and adopted by institutions.

Extension: let single reasoning steps grow into reasoning networks. Isolated CDCs connect into graphs. Impact pathways become visible. Cross-domain transfer becomes possible.

Verification: let reasoning meet reality. Cards and Actions turn graph reasoning into judgments and interventions. Outcome writeback shows where the structure is accurate and where it needs repair.

Iteration: let the cognitive system evolve. Reality changes, knowledge updates, and the graph updates with it. The value is no longer one correction, but an infrastructure that can update itself.

Together, these stages describe how a domain's implicit cognition becomes a runnable, transferable, evolving public asset.

Different entry paths

If you start from research:

Begin with a literature review. Choose one core paper and explicate its five most important reasoning steps as CDCs. Then ask how those steps depend on one another and connect them into a reasoning graph.

If you start from educational assessment:

Begin with a Why question. Design one cognitive-conflict Why question around a core concept, collect learner responses, map answer quality to L0-L4, and explain why. Those explanations are your first CDCs.

If you start from institutional decision-making:

Begin with an existing judgment workflow. Choose a repeated institutional task, such as compliance review, project evaluation, or capability rating. Explicate the judgment standard as Card: input, rule, output.

If you have AI tools:

Feed domain text, such as policies, standards, or research reports, into an AI system and ask it to extract core reasoning structures in CDC format. Treat the AI output as draft. Review, revise, and add source and context manually.

Connecting with the OCG community

OCG is an openly governed standard, not a closed product.

CDC records created through modeling can be submitted to the OCG public registry for community review and certification. Relation vocabularies are public. Anyone can propose additions or revisions.

Governance ensures that OCG's authority comes from process rather than any single institution: proposal, technical review, community comment, formal decision, and release record are all public and machine-readable.

This means OCG modeling work is not only your own knowledge asset. It can become public cognitive infrastructure for a domain.

A modest promise

OCG does not promise to give you a complete system immediately. It promises this: your first CDC is already a beginning.

Start from one judgment and write it clearly: under what conditions it holds, what supports it, and what action it licenses.

That act is already the core work of OCG: making implicit cognition visible.

> Cognitive anchor > > The entry point is a domain problem, not technical configuration. Start from the most important reasoning and write the first CDC. Different backgrounds have different entry paths. OCG's value begins with the first explicated judgment.

Appendix: Core Glossary

Appendix: Three Document Types

OCG Handbook v1.0 · Open Cognitive Graph · opencognitivegraph.org