CSM 2.0 Specification
Framework & Governance
The versioned, deterministic-by-design governance operating model for AI systems.
Why CSM 2.0 Exists
The original 2025 CSM publication defined four governance domains and sixteen components. It described what governance responsibilities exist but did not formalize how those responsibilities are evaluated, evidenced, transferred between teams or reopened when conditions change.
CSM 2.0 adds an operational specification layer: governance contracts, a determinism boundary, explicit state models, evidence and decision schemas, handoff contracts, reassessment triggers and a reference evaluator. The original domains, components and their names are preserved unchanged.
What Remained from V1
CSM 2.0 is based on and evolved from the original 2025 CSM publication. “Cognitive System Management: A Framework for Enterprise AI Project Governance” by Subodh KC, AI Governance on Medium, 2025-08-29.
Read original articleFour Governance Domains
CSM-Enterprise
Who has authority, who owns the outcome and risk, and what organizational boundaries apply?
CSM-Project
What evidence should justify continuing, changing, scaling or stopping an AI initiative?
CSM-Code
How should software engineering governance change when AI contributes to implementation?
CSM-UX
What do humans need to understand, supervise, challenge and appropriately use AI-supported outcomes?
Six Execution Functions
Purpose, Scope & Accountability
Question: What is the system for, who is accountable, and what boundaries apply?
System, Data & Dependency Mapping
Question: What components, data and dependencies comprise the system?
Risk, Evaluation & Monitoring
Question: What risks exist and how are they evaluated and monitored?
Controlled Delivery & Change
Question: How are changes controlled and delivered?
Human Oversight, Feedback & Learning
Question: How do humans oversee, provide feedback and learn from the system?
Compliance, Evidence & Assurance
Question: What evidence demonstrates governance and what compliance obligations apply?
Governance Contract Model
Every CSM component has a governance contract that formalizes its purpose, applicability, objective rules, human judgment points, evidence requirements, handoffs and reassessment behavior.
State Model
Requirement States (10)
NOT_ASSESSED
No evaluation has been performed for this requirement.
NOT_APPLICABLE
The requirement has been evaluated and determined not to apply to this system context.
REQUIRED
The requirement applies and has not yet been satisfied. Work has not begun.
IN_PROGRESS
The requirement applies and work is underway but not complete.
SATISFIED
All applicable objective rules pass and required evidence exists.
PARTIAL
Some but not all required evidence or rules are satisfied.
BLOCKED
A blocking condition exists that prevents progress.
EXCEPTION_APPROVED
An approved exception covers this requirement. The exception has a valid expiration.
HUMAN_REVIEW_REQUIRED
A human judgment point has been reached and requires explicit review.
REASSESSMENT_REQUIRED
A reassessment trigger has fired for this requirement.
Domain States (5)
NOT_STARTED
No applicable components have been assessed.
IN_PROGRESS
At least one applicable component is assessed but not all are satisfied or validly excepted.
READY_FOR_HANDOFF
All applicable required components are satisfied or validly excepted and no human review remains.
BLOCKED
At least one applicable blocking component is BLOCKED.
REASSESSMENT_REQUIRED
At least one applicable component requires reassessment.
System States (5)
ASSESSMENT_INCOMPLETE
One or more applicable components have not been assessed.
GOVERNANCE_BLOCKED
One or more applicable components are BLOCKED.
HUMAN_DECISION_REQUIRED
One or more human judgment points require explicit review.
READY_FOR_GOVERNANCE_DECISION
All applicable components are satisfied, validly excepted, or not applicable. No blockers or human reviews remain. A human authority may record an approval decision.
REASSESSMENT_REQUIRED
One or more reassessment triggers have fired.
Determinism Boundary
For a fixed CSM specification version, organizational policy configuration, explicit assessment date and normalized input record, objective CSM evaluation must produce the same computed requirement set and statuses.
Deterministic Decisions (10)
Human Judgment Decisions (10)
Human Review Boundary
When a rule cannot be resolved objectively, the evaluator returns HUMAN_REVIEW_REQUIRED and provides: the question requiring review, the responsible role, the evidence needed and the affected components.
The evaluator does not call OpenAI or another model to resolve human judgment decisions. A human authority may separately record APPROVED_FOR_<PURPOSE> as a decision record, not an engine inference.
Evidence Model
Evidence records are versioned, have explicit effective and expiry dates, and link to specific requirement IDs.
EvidenceRecord {
evidenceId, type, title, source, owner
createdAt, effectiveAt, expiresAt?
systemVersion?, artifactVersion?
uri?, hash?
relatedRequirementIds[]
status: active | expired | superseded
}
Hash is optional and supports integrity checking. An artifact with a hash is not called “immutable.”
Decision Records
DecisionRecord {
decisionId, requirementId, question
decision, decisionType
reviewer, reviewerRole, rationale
evidenceRefs[]
decidedAt, effectiveAt, expiresAt?
specVersion, policyVersion
}
decisionType distinguishes: objective_computation, human_approval, legal_review, exception, risk_acceptance
Exceptions
ExceptionRecord {
exceptionId, requirementId, reason
approver, approverRole
compensatingControls[]
issuedAt, expiresAt, scope
evidenceRefs[], reassessmentTrigger
}
Expired exceptions must not remain silently valid. The evaluator checks expiresAt against the explicit assessmentAsOf date.
Handoff Contracts
Handoffs are bidirectional feedback loops, not a waterfall.
Enterprise to Project
Project to Code
Code to UX / Operations
UX to Project
Project to Enterprise
Reassessment Triggers
18 triggers. Each specifies which domains and components reopen. Triggers do not automatically reopen all 16 components unless necessary.
Intended-use change
The intended purpose of the system has changed.
Scope expansion
The system scope has expanded beyond the approved use case.
Accountable-owner change
The accountable owner has changed.
Model change
The AI model has been changed or materially updated.
Model-provider change
The model provider has changed.
Material prompt/configuration change
Material prompt or configuration changes affect system behavior.
Major dataset or RAG-source change
Training data, retrieval sources or operational data have materially changed.
Tool/agent authority change
The tools or authority granted to an agent have changed.
New integration
A new integration has been added to the system.
Material dependency change
A material dependency has changed or been removed.
Significant security incident
A significant security incident has occurred.
Significant evaluation failure
A significant evaluation failure has been detected.
Material drift
Material model or behavioral drift has been detected.
User harm/complaint pattern
A pattern of user harm or complaints has been identified.
Jurisdiction/regulatory-context change
The regulatory or jurisdictional context has changed.
Major organizational policy change
Organizational AI governance policy has materially changed.
Approved exception expiry
An approved exception has expired or is about to expire.
Retirement/decommissioning
The system is being retired or decommissioned.
Governance Depth & Proportionality
BASELINE
ENHANCED
INTENSIVE
Proportionality Factors (10)
The framework supplies recommended factors. The organization defines actual policy thresholds. Once thresholds are configured, evaluation is deterministic.
Machine-Readable Specification
The CSM 2.0 specification is generated from canonical TypeScript source. No manually maintained duplicate JSON.
JSON Specification
JSON Schema
Reference Evaluator
A pure deterministic reference evaluator implements the CSM 2.0 rules. It uses no LLM calls, no randomness, no external API and no implicit clock.
The evaluator is a reference implementation. It is NOT HAIEC itself.
Example Test Scenarios
8 golden test fixtures covering representative scenarios. All are test fixtures, not real customers.
fixture-1
Low-impact internal AI assistant (BASELINE)
fixture-2
External customer-facing AI assistant (ENHANCED)
fixture-3
AI-assisted software-development workflow (BASELINE)
fixture-4
High-impact decision-support scenario (INTENSIVE)
fixture-5
Agent with tool authority (ENHANCED)
fixture-6
Expired governance exception (BASELINE)
fixture-7
Human/legal applicability review (INTENSIVE)
fixture-8
Material provider/model change (ENHANCED)
Limitations
CSM 2.0 is a practitioner-developed governance methodology, versioned for public scrutiny and implementation. It is not a regulatory standard, certification, peer-reviewed standard or legal framework.
Version History
Historical conceptual publication
2025-08-29Added:
- Four governance domains: Enterprise, Project, Code, UX
- Sixteen original components (four per domain)
- Cross-domain handoff visibility concept
- Implementation guidance (assessment, pilot, scale)
- Proportionality concept
Current specification
2026-08-10Added:
- Two-axis operating architecture (Domains x Execution Functions)
- Governance Contract schema for every component
- Objective rules vs human judgment points
- Determinism contract
- Explicit state model (requirement, domain, system)
- Evidence schema with versioning
- Decision record schema
- Exception contract with expiration
- Formal handoff contracts
- Reassessment engine with deterministic triggers
- Component dependency graph
- 4x6 operational mapping
- Governance depth / proportionality profiles
- Semantic versioning (spec, policy, assessment)
- Machine-readable specification design
- Informative NIST/ISO crosswalk
Expanded implementation examples
2026-08-11Added:
- Enterprise: vendor governance, provider data-processing review, model card requirements
- Enterprise: incident response authority, escalation protocol, breach notification procedure
- Code: agentic tool authority policy, agent sandbox boundaries, AI API key management, prompt injection defense
- UX: AI processing consent, opt-out and human review request, misuse detection monitoring, manipulation guardrail review
- Enterprise roles: vendor manager, incident response lead
- Code roles: platform engineer
- UX roles: privacy counsel
- Handoffs: Enterprise to Code (security incidents), Code to Enterprise (policy gaps), UX to Enterprise (user-reported incidents)
Original Publication Source
Cognitive System Management: A Framework for Enterprise AI Project Governance
CSM 2.0 does not produce legal compliance verdicts. It may produce governance requirements, evidence gaps, review requirements, decision records and framework mappings. Legal applicability or legal sufficiency must remain subject to qualified interpretation where needed.
Forbidden Output States
The evaluator must never produce these states:
The evaluator must never produce these score names:
NIST AI RMF & ISO/IEC 42001 Crosswalk
Informative Mapping. This crosswalk is informative. It does not constitute equivalence, certification, or a compliance guarantee. CSM 2.0 is an independent governance methodology. NIST AI RMF and ISO/IEC 42001 are separate frameworks with their own scopes, definitions and requirements. Organizations seeking certification or compliance with NIST or ISO should consult the original standards and qualified assessors.
| CSM Component | NIST Function | ISO Clause | Relationship |
|---|---|---|---|
| ENT-POLICY | Govern | Clause 5 - Organizational context, Clause 6 - Planning | supports |
| ENT-RISK | Map | Clause 6.1 - Actions to address risks and opportunities | supports |
| ENT-DATA | Map | Clause 7.3 - Data for AI systems | partially-maps |
| ENT-MANDATE | Govern | Clause 5.3 - Roles, responsibilities and authorities | supports |
| PRJ-BUSINESS | Map | Clause 8.1 - Operational planning and control | partially-maps |
| PRJ-TESTING | Measure | Clause 8.3 - AI system impact assessment | supports |
| PRJ-SCALE | Manage | Clause 8.4 - AI system change management | partially-maps |
| PRJ-PLAYBOOK | Govern | Clause 7.5 - Documented information | supports |
| CODE-STANDARDS | Manage | Clause 8.2 - AI system development controls | supports |
| CODE-SECURITY | Measure | Clause 8.2 - AI system development controls (security) | supports |
| CODE-HUMAN | Manage | Clause 8.3 - Human oversight | supports |
| CODE-TRACE | Measure | Clause 7.5 - Documented information (records) | supports |
| UX-IMPACT | Map | Clause 8.3 - AI system impact assessment | supports |
| UX-EXPLAIN | Manage | Clause 8.5 - Transparency and information for users | supports |
| UX-CAPABILITY | Govern | Clause 7.2 - Competence and training | partially-maps |
| UX-ADOPTION | Measure | Clause 9.1 - Monitoring, measurement, analysis and evaluation | supports |