Skip to content
CoherenceResearch

Frequently Asked Questions

Updated2026-04-12

Common questions about the Structural Coherence Anchor Specification (SC-AS) and Coherence Research. For the formal specification, see the Standard page.

What is the main failure mode when AI works with formal specs?

The primary failure mode is mimicry over enforcement: an AI system reads a formal axiomatic spec and starts generating from it — producing new admissibility conditions, extending the axiom chain, deriving theorems that aren’t in the spec.

The output looks structurally grounded but is hallucinated structure wearing the spec’s language. The AI is mimicking the spec’s output rather than enforcing its constraints.

This is not a minor precision issue — it produces architecturally dangerous outputs that appear formally valid while violating the actual structural conditions.

The correct instruction prevents this: treat every admissibility condition as a hard constraint, every axiom as a boundary, not a starting point. When the spec doesn’t cover a case, state that explicitly. Gaps are gaps — not invitations to extend.

What is the correct way to instruct AI when working with SC-AS?

The correct posture is conformance checking, not derivation.

Feed the admissibility conditions as hard constraints on architectural proposals — not as a derivation chain to reason forward from. For every proposal, instruct the AI to ask: “Does this design satisfy the declared admissibility conditions?” — not “What else follows from the axioms?”

For every proposal evaluated, the AI should:

  • Check whether it satisfies the declared admissibility conditions
  • Identify which condition fails if it doesn’t
  • Return a conformance verdict: pass, fail, or underdetermined

A complete AI ingestion prompt with usage notes is available on GitHub: SC-AS-AI-INGESTION-PROMPT.md

Can I use AI to work with the spec?

Yes — SC-AS is explicitly designed for AI ingestion. The specification uses a machine-readable structure with formal derivation chains and self-contained conformance criteria, so AI systems can reason from the spec directly rather than just referencing it as documentation.

However, the instruction posture matters critically. See the questions below on how to correctly instruct AI when working with SC-AS.

How do I cite SC-AS?

Standard citation format:

Carroll, J. (2026). Structural Coherence — Anchor Specification (SC-AS), v1.0. Coherence Research. https://coherenceresearch.com/standard

Zenodo DOIs for persistent archival citation:

Can I fork or create derivative specifications?

You may not distribute modified versions of the canonical SC-AS documents — that is the NoDerivatives restriction in CC BY-ND 4.0.

However, you can build downstream specifications that reference and extend SC-AS, provided they are clearly distinguished from the canonical documents and do not present modifications as canonical.

The CC-BY-ND license protects the integrity of the published standard while leaving implementation entirely open. This is a deliberate structural choice: open to build, not to fork.

Can I implement SC-AS commercially?

Yes. SC-AS is published under the Creative Commons Attribution-NoDerivatives 4.0 International License (CC BY-ND 4.0).

Independent implementation — including commercial implementation — is unrestricted. You can build products, services, and tooling on SC-AS without restriction or royalty.

The only restrictions are: you must attribute Coherence Research when sharing or citing the spec, and you may not distribute modified versions of the canonical documents.

What comes after SC-AS?

SC-AS is the anchor of a growing derivation chain. From its axioms, Coherence Research derives a family of open specifications — each formally audited before publication:

  • SC-FCALC (Published) — formal operational theory: algebraic properties and convergence proofs
  • SC-CALC (In development) — verification calculus: the σ-step function, convergence loop, and regime-indexed computation
  • SC-PCF (In development) — Presence/Connection/Flow framework for structural diagnosis and intervention
  • SC-PSID (In development) — formal structural addresses for positions in concept space

All derived specifications pass the Five Rigors before publication.

How do I verify a document’s integrity?

Every canonical document carries a SHA-256 hash in its header, computed per SC-HDR §3.2 Rule 7. To verify:

  1. Open the .md source file
  2. Blank the SHA-256: value (line ends at the colon)
  3. Compute SHA-256 over the UTF-8 bytes with LF line endings
  4. Compare against the hash in the header

The Constitutional Release bundle includes verify_bundle.py — a zero-dependency Python script that independently verifies every SHA-256 hash, recomputes the Merkle root, validates RCC target coupling, and checks bundle composition.

Current hashes and the Merkle root are published on the Standard page.

What is the difference between SC-AS and governance frameworks like NIST AI RMF or ISO 42001?

NIST AI RMF and ISO 42001 are management system standards — they specify processes, roles, and organizational practices for managing AI risk. They operate at the policy layer.

SC-AS operates at the structural layer below that — it specifies the formal admissibility conditions that structural configurations must satisfy before policy applies. It addresses a different and earlier question: not “how do we manage risk” but “what configurations are structurally permitted to exist at all.”

The two layers are complementary, not competing. Policy frameworks assume their structural foundations are sound. SC-AS is the discipline for making that assumption checkable.

What is structural admissibility?

Structural admissibility is the core governance mechanism in SC-AS. A configuration is admissible if it satisfies the declared structural conditions — independent of what the system encounters or what failure modes are anticipated.

This is fundamentally different from probabilistic risk management. Admissibility conditions don’t require enumerating failure modes. They don’t assign probabilities. They establish what configurations are permitted to exist at all — before the system operates.

The gate holds because of structural properties of the system, not because failure modes were catalogued in advance.

How do I read the spec?

The specification uses a rigorous term schema (T0–T7) where every definition carries explicit scope, dependencies, necessity witness, minimality proof, and admissibility interface.

Recommended reading path:

  1. SC-SCOPE — understand what the specification does and does not claim
  2. SC-CORE — the formal kernel: primitives, conditions, rules
  3. SC-AXIOM — the axiomatic consequences derived from the Core
  4. SC-HDR — how documents are structured and verified

All four canonical documents are available as markdown source and rendered PDF on the Standard page.

Is this a consulting framework or a formal standard?

SC-AS is a formal axiomatic standard — not a methodology, consulting framework, or best-practices guide.

A configuration either satisfies the axioms or it doesn’t. Every claim CR makes traces its provenance to this foundation. The specification does not ask you to trust the framework. It asks you to test it.

Implementation and advisory services are offered separately through Coherence Foundry. The steward of the standard does not sell the implementation.

Who is SC-AS for?

SC-AS is designed for anyone building systems where structural failure at scale is unacceptable:

  • AI researchers and engineers building systems that must hold structural commitments under inference, fine-tuning, and deployment
  • Founders and executives scaling organizations where structural integrity is existential
  • Governance architects designing systems that must remain steerable under adversarial conditions
  • Researchers working across disciplines who need a representational discipline that survives translation without flattening structural depth

The specification is designed to be readable by both humans and AI systems.

What is SC-AS?

SC-AS — the Structural Coherence Anchor Specification — is the foundational open standard published by Coherence Research. It is the constitutional anchor of an open formal standards family.

SC-AS defines structural coherence as three verifiable conditions:

  • Identity that persists — what must remain invariant for a system to remain itself
  • Interaction that stays bounded — adjacency and composition relationships that carry coherence across boundaries
  • Change that stays admissible — redistribution that preserves structural integrity

Every term traces to explicit primitives. Every axiom carries a necessity proof. The spec defines its own conformance criteria internally — you can audit it without trusting the people who wrote it.

SC-AS v1.0 was published as a Constitutional Release in March 2026.

What is Coherence Research?

Coherence Research is an independent organization that publishes open formal standards for structural coherence — the discipline of making structural integrity formally describable, independently verifiable, and freely available.

Founded by Jason Carroll, Coherence Research exists to address a structural gap: most of what the world builds on has never been formally checked. As AI and complex systems scale, unchecked foundations become an existential liability. CR publishes the formal discipline for addressing it.

The work is offered freely under open license. Implementation and advisory services are provided separately through Coherence Foundry.

Looking for the full specification? Read the Standard → | Start with the Overview → | About Coherence Research →