Skip to content

Specification as Safety

§0 The answer in one screen

A specification cannot make a simulation safer. A specification that something else enforces can. FCC currently ships the first and calls it the second.

That is the finding, and it is measured on both sides.

The external evidence is unusually one-directional. Writing a constraint into an agent's prompt does not reliably produce the constrained behaviour. Personas in system prompts produce no accuracy improvement across 162 personas and 2,410 questions (arXiv 2311.10054, retrieved 2026-09-04). Models given explicit rules in the system prompt "struggle to follow scenario rules, even on straightforward test cases" (RuLES, arXiv 2311.04235). Agents given explicit domain policy pass all eight of eight repeated runs in under 25% of retail tasks (τ-bench, arXiv 2406.12045). Meanwhile the same idea — specify the constraint — enforced as executable predicates at runtime prevents >90% of unsafe executions in code agents and 100% of safety-constraint violations in autonomous driving, at millisecond overhead (AgentSpec, arXiv 2503.18666, ICSE 2026). The variable that matters is not whether the constraint is written. It is whether something refuses to violate it.

FCC is on the wrong side of that line, and it is not close. FCC's hard_stop is 400 unique English sentences (§1.2). Its only enforcement code is a substring matcher that tries a 3-word, then 2-word, then 1-word keyword (constitution_registry.py:167). Run against a real violation of "Never fabricate research sources or citations" it returns no violations; run against a compliant sentence that merely quotes the rule it returns a violation (§2.2). 287 of 389 checkable rules bottom out on a single common verb — any text containing the word "deploy" trips 32 of them (§2.3).

Two of FCC's three regulatory surfaces are structurally incapable of failing. FindingStatus.FAIL is never assigned anywhere in auditor.py — it appears only at line 317, where it is counted. Executed against the shipped catalogue, 131 personas × 242 requirements produce 31,702 findings, 100% PASS, zero failures (§3.2). The CLEAR+ "Assurance" dimension — the safety score — is return 1.0 if total == 0 else 1.0 (runner.py:313): every branch, including the exception handler, returns 1.0 (§3.5). And the AI Act classifier's first rule is "≥3 hard-stops → HIGH"; every core persona has ≥3, so all 131 classify HIGH and the remaining four rules are unreachable (§3.4).

But the honest inverse is also true, and it is the reason this Find is not simply a demolition. FCC holds three things the guardrails landscape does not have and is not building:

  1. Stable, addressable identity for every rule. The vocabulary store gives all 1,299 rules an FQN — fcc:constitution:hard_stop_never_hardcode_secrets_or_credentials_in_application_code — with a back-reference to the personas that carry it (§7.1). Nothing else surveyed does this. Anthropic's constitution is a 23–26k-word essay with no rule IDs and no schema (anthropic.com/constitution); OpenAI's Model Spec likewise (github.com/openai/model_spec); MLCommons publishes its normative hazard definitions in a Google-Drive-hosted PDF (github.com/mlcommons/ailuminate). A rule you cannot cite is a rule you cannot audit.
  2. Hand-curated regulatory anchoring. vertical_risk_profiles.yaml maps all 45 vertical personas to an EU AI Act risk category with a rationale, 21 of them to a named Annex III clause (§3.6). This is the one piece of FCC's compliance surface that is real analysis rather than a structural artifact.
  3. A published consumer contract that a runtime actually gates on. archetype-persona-agent-binding.md:35 states hard_stop is mandatory for a runnable agent — and a consumer enforces it. That is the correct architecture: FCC declares, the runtime refuses. It is the AgentSpec pattern, drawn at the right seam.

And the gap is where the safety claim would have to be strongest. All 45 vertical personas ship hard_stop: [] — measured directly in the committed catalogue, docs/catalog/v2.2.0/catalog.jsonl, 176 records, 45 empty (§6.1). 19 of them FCC itself classifies HIGH risk, including Patient Safety Engineer, Medical Device Software Engineer (IEC 62304 / ISO 13485 / EU MDR), HIPAA Compliance Officer, NERC CIP Compliance Officer and Grid Model Manager (§6.2). The 131 personas that do carry hard-stops are the ones where a hard-stop is least consequential — documentation quality, schema versioning, code review. FCC's guardrails are populated exactly where they do not matter and empty exactly where they do.

The safety content is not missing, though. It is in the wrong field. All 45 verticals carry riscear.constraints — 244 strings — and the energy ones are markedly more specific than any core hard-stop: "No BES Cyber Asset change may bypass CIP-010 Part 1 configuration baseline and Part 2 change authorization." Only 34 of 244 are in prohibitive form today, so this is a rewrite, not a copy (§6.3).

Position reached (§10): specification-as-safety is a real contribution and FCC's current implementation of it is governance theatre, and these are not in tension — they describe the declarative layer and the enforcement layer respectively. The defensible claim is narrow and this Find recommends adopting it verbatim: FCC publishes citable, versioned, regulation-anchored constraint identities that a runtime can gate on, and it can prove a runtime does. Everything past that — that the spec makes agents safer, that it satisfies Annex IV, that the audit means anything — is unearned, and three of those claims are currently made in shipped FCC documents.

§1 What FCC actually has

1.1 The primitive

The three-tier constitution is a frozen dataclass with three string tuples — hard_stop_rules, mandatory_patterns, preferred_patterns (constitution_registry.py:19-31) — read out of persona.doc_context["constitution"] (:74-82). to_tier_model() (:33-60) converts them to ConstitutionRule objects with generated ids ({persona_id}-HS-{i:03d}) and tiers 1/2/3.

That is the whole model. A rule is a string. There is no predicate, no trigger, no subject, no object, no severity beyond the tier, and no enforcement mechanism attached to the rule itself.

1.2 The measured shape of the corpus

Executed against the shipped registry at HEAD b368c1df:

count
core personas 131
core personas with zero hard-stops 0
hard_stop strings 400
mandatory strings 506
preferred strings 396
distinct hard_stop strings 400 (no duplication)

Distribution is strikingly uniform: 125 personas carry exactly 3 hard-stops, 5 carry 4, 1 carries 5. That uniformity turns out to be load-bearing — it is what makes the AI Act classifier degenerate (§3.4).

The rules are prose. Length 30–100 characters, mean 62.4. 375 begin "Never", 14 begin "No", 11 begin with neither. Only 11 of 400 contain a digit at all, and most of those are not thresholds ("Never adjudicate an EIF appeal — route it to PAOM"). Representative sample:

[RC]   Never fabricate research sources or citations
[QLS]  Never deploy RL agents without safety constraint verification
[BC]   Never modify production specifications without audit trail
[PHV]  Never absorb upstream code without verifying license and provenance
[IA]   Never exceed 3-level navigation depth for primary user journeys

These are good sentences. A competent engineer reading them would know what to do. That is not the same property as a runtime being able to check them, and §2 measures the difference.

1.3 The schema does not know the constitution exists

This is the structural fact that explains everything downstream.

persona.schema.json declares required: [id, name, fcc_phase, role_title, riscear, collaboration]. The string "constitution" does not appear in the file at all. The constitution rides inside doc_context, which the schema defines in full at line 150 as:

"doc_context": { "type": "object", "description": "Documentation metadata for template rendering" }

No properties, no required keys, no constraints. vertical.schema.json likewise contains no mention of constitution.

So JSON-Schema validation structurally cannot detect a missing or malformed hard-stop, and no CI guard compensates — grepping .github/, Makefile and scripts/ for hard_stop returns one unrelated hit in a frontend generator. tests/test_new_personas.py:244 asserts >= 2 hard-stops, but only for one fixture, not the catalogue.

That is why 45 personas can ship without a constitution and pass every gate FCC has (§6).

1.4 riscear.constraints — the other, larger constraint surface

RISCEARSpec.constraints is a plain list[str] (models.py:126), required by the schema, and carries 573 strings across the 131 core personas — more than the 400 hard-stops. It reaches the model: action_engine.py:73-75 renders it into the system prompt under ## Constraints, alongside hard-stops at :85-92.

The binding contract classifies it as "advisory / folded into mandatory" (paom-sentinel-coordination.md:21). So FCC maintains two constraint surfaces with different governance status and no mechanical distinction between them: both are lists of English sentences, both go into the prompt, one is called authoritative and one advisory. §6.3 shows this distinction is where the vertical gap actually lives.

§2 What the enforcement code actually does

2.1 There is exactly one enforcement function

ConstitutionRegistry.validate_persona(persona_id, content) -> list[str] (constitution_registry.py:148-172) is the only code in FCC that checks content against a constitution. Its docstring is candid: "Uses keyword extraction from rules starting with 'No' or 'Never'."

The algorithm:

for rule in pc.hard_stop_rules:
    rule_lower = rule.lower()
    if rule_lower.startswith("no ") or rule_lower.startswith("never "):
        phrase = ...                       # text after the negation
        words = phrase.split()
        for length in range(min(3, len(words)), 0, -1):   # :167
            keyword = " ".join(words[:length])
            if keyword in content_lower:
                violations.append(rule); break

Three properties follow, and all three were confirmed by execution rather than reading.

2.2 It produces false negatives on real violations and false positives on compliant text

Persona RC (Research Crafter) carries Never fabricate research sources or citations.

Measured false negative. Input: "I invented a plausible-looking citation (Smith 2021) that does not exist." — an unambiguous violation of the rule.

violations = []

Measured false positive. Input: "Our policy is that we never fabricate research sources; every claim is cited." — a statement of compliance.

violations = ['Never fabricate research sources or citations']

Second measured false positive, showing the 1-word degradation. Persona SQC carries No SELECT * on tables exceeding defined row thresholds. Input: "SELECT id, name, email FROM users" — contains no SELECT *, does not violate the rule.

violations = ['No SELECT * on tables exceeding defined row thresholds']

The loop at :167 tried "select * on", then "select *", then fell through to "select", which matched.

The checker is not merely weak. It is anti-correlated with the property it claims to check: text that violates a rule without naming it passes, and text that names a rule while complying fails.

2.3 287 of 389 checkable rules bottom out on a single common verb

Because the loop descends to length == 1, every rule's ultimate trigger is the first word after the negation. Measured distribution across the 389 rules that begin No/Never:

trigger word rules it fires
deploy 32
bypass 27
publish 26
skip 26
allow 23
approve 13
omit 13
modify 11
report 10

287 rules share a trigger word with at least two others. Any content containing the word "deploy" is flagged against 32 distinct hard-stops.

2.4 Eleven rules are never evaluated at all

The startswith guard means any rule not phrased as a negation is silently skipped — it can never be violated. Measured: 11 of 400, and they are among the most operationally specific in the corpus:

[ISP]  Authentication required for all external system integrations
[ISP]  Rate limiting required on all outbound API calls
[ISP]  Input validation required before any data transmission
[ASC]  Error handling required (set -euo pipefail or equivalent)
[POR]  Retry logic required with minimum three attempts and exponential backoff
[SQC]  CTE decomposition required for queries with more than two joins
[SFBI] The canonical reconciliation table is the single source of truth — no ad-hoc renaming

These are the rules closest to being mechanisable — several name a concrete, checkable technical condition — and they are exactly the ones the checker ignores, because they are phrased as requirements rather than prohibitions.

2.5 The test suite validates only the happy path

tests/test_constitution_registry.py:258-260 is the entire adversarial coverage:

def test_validate_violation_detected(self, registry):
    violations = registry.validate_persona("SQC", "SELECT * FROM large_table")
    assert len(violations) >= 1

A literal substring hit. There is no test for a semantic violation, no test for a false positive, and no test that the 11 non-negation rules are unreachable. The mechanism has never been tested against an input designed to defeat it — which is why §2.2 took one attempt.

§3 The compliance chain

3.1 The requirement corpus is real

eu_ai_act_requirements.yaml carries 256 requirements spanning Articles 1–55 plus Annexes, with article, sub_article, title, description, risk_category, checks, nist_crosswalk, annex_refs and recital_refs. Article coverage is genuine and proportionate: Art. 9 → 15 requirements, Art. 10 → 14, Art. 15 → 13, Art. 14 → 11, Art. 17 → 11, Art. 11 → 10, Art. 13 → 10, Art. 5 → 14. nist_ai_rmf_mapping.yaml carries 29. Together the 256 EU requirements contain 926 individual check strings.

This is a substantial, careful piece of codification and nothing below is a criticism of it. The problem is entirely on the consuming side.

3.2 The auditor cannot emit a failure

_check_persona_requirement (auditor.py:263-308) builds two evidence items — one saying how many constitution rules the persona has, one saying whether R.I.S.C.E.A.R. is complete — then decides status:

if remediation_items:
    status = FindingStatus.WARNING
elif evidence_items and all(e.confidence >= 0.8 for e in evidence_items):
    status = FindingStatus.PASS
else:
    status = FindingStatus.PASS      # :301

Both branches of the confidence test return PASS. The confidence check is dead code.

And remediation_items is always empty. It is populated only when a requirement's check string contains the substring "constitution" or "riscear" (:284-294). Measured: zero of the 926 EU check strings contain either word. The WARNING branch is unreachable for persona audits.

FindingStatus.FAIL is never assigned anywhere in auditor.py. Grepping the file returns assignments at lines 91, 102, 112 (PASS), 125, 155, 236 (NOT_APPLICABLE), 143 (PASS/WARNING), 297 (WARNING), 299 and 301 (PASS) — and one further occurrence at line 317, inside _build_report, where failed is counted. ComplianceReport.failed is structurally always zero.

Executed against the shipped catalogue — 131 personas × 242 applicable requirements:

findings: 31,702
status distribution: {'pass': 31702}

An audit with 31,702 findings and no possible failure is not an audit.

3.3 The evidence is identical for every article

Sample finding, verbatim:

requirement: EU-AI-ACT-ANNEX-I-1   status: pass
  evidence: constitution_registry | Persona RC has 10 constitution rules (3 hard-stops). | conf 1.0
  evidence: persona_spec          | R.I.S.C.E.A.R. specification is complete for RC.     | conf 1.0

Those two strings are the evidence for all 242 requirements — the same text for Article 5 (prohibited practices) as for Annex IV (technical documentation) as for Article 12 (logging). The auditor never reads the requirement's content. It checks two structural properties of the persona and reports them against everything.

audit_workflow (:83-116) is worse: it selects requirements by keyword-matching the requirement title for "transparency", "oversight"/"human", or "record"/"logging", then emits unconditional PASS with hardcoded evidence strings — "Workflow graph structure is transparent and documented." It never inspects the WorkflowGraph passed to it. audit_simulation:143 is the only place in the module where data affects an outcome (has_start and has_end), and its worst verdict is WARNING.

3.4 The risk classifier is a constant function for core personas

AIActClassifier.classify_persona (classifier.py:78-120) applies five rules in order. Rule 2 (:99-103):

if constitution and len(constitution.hard_stop_rules) >= 3:
    return RiskCategory.HIGH

Every core persona has ≥3 hard-stops (§1.2). Measured over all 131:

core risk distribution: {'high': 131}

Rules 3, 4 and 5 — the governance-category check, the decision-keyword check, the mandatory-pattern downgrade — are unreachable for every persona in the catalogue. card_generator.py:395-413 duplicates the same >= 3 → HIGH heuristic independently, so model cards inherit the same constant.

The consequence is not that the classification is wrong — it is that it carries no information. A classifier whose output is determined by a uniform structural property of its input has not classified anything. And it is worth naming what the heuristic actually encodes: "this persona is high-risk because someone wrote three sentences about it."

3.5 CLEAR+ Assurance is a literal constant

BenchmarkRunner._compute_assurance (runner.py:297-315) sums hard-stop counts into total, then:

# In mock mode no content to validate → 100% assurance
return 1.0 if total == 0 else 1.0     # :313

Both branches return 1.0; the enclosing except also returns 1.0 (:315). The comment explains the mock-mode case and the code applies it universally. The "Assurance — confidence / safety score" dimension of FCC's evaluation framework (metrics.py:25) is unconditionally 1.0.

FCC therefore has never measured the safety property it benchmarks, which is why could_not_establish item (2) is unavoidable.

3.6 The one part of the chain that is real

vertical_risk_profiles.yaml is different in kind. It is hand-authored, its header explains why it exists as a separate mapping layer, and it maps (persona_id, domain) to a risk category:

  • 45 of 45 vertical personas covered — no gaps.
  • 45 of 45 carry a written rationale.
  • 21 of 45 carry a named annex_reference.
  • Distribution: 20 high, 23 limited, 2 minimal — genuinely differentiated.
persona_id: PSE, domain: healthcare, risk_category: high
rationale: "Patient safety engineering oversees life-critical systems and triggers adverse-event reporting workflows."
annex_reference: "III.1 (safety components in medical devices)"

This is the analysis the automated classifier only appears to perform. It is also FCC's strongest existing claim to regulatory traceability, and it is worth noting that it was produced by a person, not a heuristic.

Which yields the sharpest structural irony in the codebase. The 131 core personas have constitutions but a degenerate risk classification. The 45 vertical personas have a curated, Annex-III-anchored risk classification but no constitution. Neither half of the catalogue has both, and the half operating in regulated domains is the half missing the guardrails.

build_compliance_evidence_graph links personas to requirements at evidence_graph.py:87-90:

persona_findings = [f for f in findings
                    if any(pid in (e.content or "") for e in f.evidence)]

pid is a 2–4 character persona id — 16 ids are 2 chars, 102 are 3, 13 are 4 — matched as a bare substring against evidence prose. 25 ids are substrings of other ids: (RC, RCHM), (BC, BCHM), (DE, SDE), (DE, DEO), (DE, VDE), (IA, CIA), (IA, PIA), (FA, FAR), (UG, UGCH)…

Measured, pooling audits for RC and RCHM as the real code path does:

pooled findings: 484
matched to pid 'RC':   484      <- should be 242
matched to pid 'RCHM': 242

RC acquires exactly double its true GOVERNS edges, absorbing every finding belonging to RCHM.

Separately, the constitution node (:104-115) carries only counts — hard_stops, mandatory, preferred as integers. Not the rule text, not rule ids. No edge anywhere in the graph connects a specific rule to a specific article. The "evidence graph" therefore contains no rule-level traceability at all, which is the one thing a compliance evidence graph exists to provide.

§4 What the rest of the field actually ships

The question "is a specification portable and enforceable?" has been answered many times by people building runtimes, and the answers cluster.

4.1 The landscape splits on two axes

Enforced (blocking) Advisory / training-time
Declarative data OpenAI Guardrails JSON · AP2 Mandates · agentgateway CEL · MS declarative agents · Bedrock Guardrails MCP tool annotations · A2A AgentCard · OASF · AGENTS.md
Code / prose OpenAI Agents SDK guardrails · Guardrails AI validators · NeMo Colang · Llama Guard (caller must act) Claude's Constitution · OpenAI Model Spec · Bai et al. CAI

No surveyed system is simultaneously declarative, portable across vendors, and enforced. FCC sits in the bottom-right cell — declarative prose, advisory — and aspires to the top-left.

4.2 Constraints as code (not portable)

  • OpenAI Agents SDK guardrails are Python callables decorated @input_guardrail/@output_guardrail, returning tripwire_triggered: bool; a tripwire raises and halts the run. Blocking, but bound to the SDK object graph — the documentation describes no serialization (openai.github.io/openai-agents-python/guardrails, retrieved 2026-09-04).
  • Guardrails AI validators are Validator subclasses registered via @register_validator. There is no declarative validator. Guard.to_dict() serializes to JSON, but the validator id is an opaque registry key whose semantics live in Python — and when a referenced validator is not installed the runtime emits a warning and returns validation_passed: True with the output unmodified. A serialized policy shipped to a host missing one validator silently enforces nothing and reports success. The project is also in wind-down: the Guardrails Hub distribution channel was retired 2026-08-25 and hub.api.guardrailsai.com no longer resolves (github.com/guardrails-ai/guardrails/issues/1560, retrieved 2026-09-04).
  • NeMo Guardrails / Colang is a genuine DSL with .co files and an event-driven flow engine, and NVIDIA states configs are portable between the library and the microservice (v0.24.0, released 2026-08-26, github.com/NVIDIA-NeMo/Guardrails). But flows invoke execute <action>, and actions are Python functions the host supplies — a non-trivial third-party config carries an implicit code dependency. And nothing outside NeMo parses Colang.

4.3 Constraints as prose (portable, not enforced) — including "constitution"

This is where the vocabulary must be kept straight, because FCC uses the word "constitution" for something categorically different from the literature.

In Bai et al. (arXiv 2212.08073, retrieved 2026-09-04), a constitution is a training-time artifact. 16 principles for the supervised stage and 16 for RL, consumed by randomly sampling one principle per critique-and-revision step to generate SFT data, and by sampling a principle to produce an AI preference label that trains a preference model. The constitution's influence is thereafter frozen into weights. There is no inference-time step anywhere in the pipeline — no rule engine, no evaluator. The only reader of the constitution is an LLM prompt during data generation.

Anthropic's published constitution (January 2026) is prose, and deliberately so. ~23–26k words of narrative, CC0, source Markdown at github.com/anthropics/claude-constitution — no YAML, no JSON, no rule IDs, no schema, no API (anthropic.com/constitution, retrieved 2026-09-04). Anthropic rejects the rule-engine framing explicitly: "If we want models to exercise good judgment across a wide range of novel situations, they need to be able to generalize — to apply broad principles rather than mechanically following specific rules." Note the direction of travel: the 2023 constitution was ~50 enumerated bullets directly consumable by the CAI sampling loop; the 2026 one is an essay. Anthropic moved away from list-shaped principles.

Even Constitutional Classifiers do not evaluate the constitution at runtime. arXiv 2501.18837 (2025-01-31) trains classifiers on synthetic data generated by prompting LLMs with the constitution; the deployed artifact under ASL-3 is a neural net that streams token-level predictions. "The constitution can rapidly be adapted" means: edit the prose, regenerate the corpus, retrain. Anthropic cannot hot-load its own constitution either.

OpenAI's Model Spec is more structurally regular (explicit rules vs overridable defaults, a platform > developer > user chain of command) but still Markdown with no JSON, no schema, no formal rule IDs — and OpenAI concedes "production models do not yet fully reflect the Model Spec" (github.com/openai/model_spec, CC0, retrieved 2026-09-04).

Llama Guard blocks nothing. The MLCommons hazard taxonomy is injected as prose between <BEGIN UNSAFE CONTENT CATEGORIES> markers; the model emits safe or unsafe\nS1,S10 as generated text and the caller decides what to do. There is no machine-readable, versioned taxonomy spec — the normative definitions live in a Google-Drive-hosted PDF, and github.com/mlcommons/ailuminate contains only a README, an SVG, and two CSVs of prompts. No cross-vendor crosswalk to OpenAI's disjoint 13-category scheme exists (all retrieved 2026-09-04).

FCC's usage sits closer to Anthropic's prose constitution than to anything enforceable — with the important difference that Anthropic's is consumed by a training process that demonstrably changes behaviour, and FCC's is consumed by a substring matcher.

4.4 The interop standards carry no behavioural constraints

  • A2A v1.0.0 (2026-04-09, Linux Foundation). The complete AgentCard field set from the normative proto is name, description, supported_interfaces, provider, version, documentation_url, capabilities, security_schemes, security_requirements, default_input_modes, default_output_modes, skills, signatures, icon_url. Not one field expresses a permitted-action set, a prohibition, or a policy. AgentSkill is self-described as "behaviors that the agent is likely to succeed at" — a capability claim, not a limit. The one proposal that would change this (issue #1628, trust.signals[] with a governance_attestation covering "what an agent is permitted to do") is open, unaccepted, and has no schema.
  • MCP (revision 2026-07-28) states that tool annotations are advisory and that "descriptions of tool behavior such as annotations should be considered untrusted." Maintainers published a post titled in part "What Hints Can and Can't Do": "They aren't enforcement. An untrusted server can claim readOnlyHint: true and delete your files anyway" (blog.modelcontextprotocol.io, 2026-03-16, retrieved 2026-09-04).
  • NIST COSAiS plans SP 800-53 overlays for single-agent and multi-agent AI systems, but as of 2026-09-04 only the Predictive AI annotated outline has shipped (2026-01-08). The agentic overlays are not drafted (csrc.nist.gov/projects/cosais). There is nothing for a multi-agent framework to align to.

This matters directly for FCC: a2a_card.schema.json contains neither "constitution" nor "hard_stop", and ask_service.py:251-260 returns a2a_card = None for vertical personas. FCC's guardrails do not travel over the one open interoperability protocol FCC implements — but §4.4 shows that is a property of A2A, not a defect FCC introduced.

4.5 The existence proof FCC should study

AP2 Mandates (Agent Payments Protocol, donated to the FIDO Alliance 2026-04-28) is the one system surveyed that fully passes the third-party-authored-and-independently-enforced test. Its authorization model opens with a sentence FCC could have written:

"Due to their non-deterministic processes, even well-behaving Agents need to have their behavior tightly constrained above what a normal authorization model would require of human users."

Mechanically: a user approves Mandate Content on a trusted surface; the signed Mandate (SD-JWT VC, versioned vct schema id such as mandate.checkout.1) travels with the agent; and a Verifier with no relationship to the agent's framework evaluates it. Constraints are typed objects with normative evaluation semantics:

{"type": "checkout.allowed_merchants", "allowed": [...]}

"Evaluation: The Merchant MUST be present in the revealed elements of allowed."

(google-agentic-commerce/AP2, agent_authorization.md, retrieved 2026-09-04.) Scoped to payments today, and AP2 says the model "could be applied more generally in the future."

The shape to copy is: typed constraint + normative MUST-level evaluation rule + versioned schema id + independent verifier. FCC has the versioned identity (§7.1) and the independent verifier (§7.3). It has neither the type nor the evaluation rule.

§5 Does specification improve outcomes? The evidence, including what is absent

5.1 The direct study does not exist

No study was found testing whether giving each agent in a multi-agent system a written per-persona behavioural specification improves safety versus not doing so. This is stated first and plainly because it is the crux of the operator's question and because the temptation to paper over it with adjacent citations is exactly the failure mode this Find exists to avoid. If anyone claims the proposition is empirically established, they are over-claiming.

5.2 The adjacent evidence runs against prompt-level specification

Intervention Study Result
Persona in system prompt → accuracy arXiv 2311.10054, Findings of EMNLP 2024; 162 personas, 2,410 questions, 4 LLM families No improvement over no-persona control. Oracle persona selection helps, but automatic selection is ~chance.
Explicit rules in prompt → rule adherence RuLES, arXiv 2311.04235; 14 scenarios, programmatic violation detection "Almost all current models struggle to follow scenario rules, even on straightforward test cases"; simple attacks sharply increase violations.
Policy guidelines supplied → consistency τ-bench, arXiv 2406.12045 gpt-4o succeeds on <50% of tasks; pass^8 < 25% in retail. Authors call for methods to "follow rules reliably."
Behavioural spec present → agent safety AgentHarm, arXiv 2410.09024, ICLR 2025 "Leading LLMs are surprisingly compliant with malicious agent requests without jailbreaking."
— HAICOSYSTEM, arXiv 2409.16427; 1,840 simulations, 92 scenarios SOTA models "exhibit safety risks in over 50% [of] cases."
— ToolEmu, arXiv 2309.15817; 36 tools, 144 cases The safest agent still failed 23.9% of the time.

(All retrieved 2026-09-04.)

5.3 The closest thing to the right experiment — and its verdict

MAST, arXiv 2503.13657 annotated 1,600+ multi-agent traces across 7 frameworks into 14 failure modes, then ran interventions:

  • ChatDev: improving agent role specifications → +9.4% success rate.
  • AG2 MathChat: adding high-level task-objective verification → +15.6%.

Two things must be carried with those numbers.

First, the authors' own verdict: "Although first step interventions lead to performance gains, not all failure modes are resolved, and task completion rates still remain low." They conclude robust multi-agent systems need "combinatorial changes ranging from agent system organization to model level improvements" — not better specifications.

Second, and more pointed for FCC: in their failure taxonomy, "disobey role specification" accounts for 1.5% of failures. Failures cluster in step repetition (15.7%), reasoning-action mismatch (13.2%), unawareness of termination conditions (12.4%), disobeying task specification (11.8%), and incorrect or absent verification (9.1% + 8.2%) — that is, in control flow and checking, not in role definition.

A framework whose primary investment is richer per-persona role prose is optimising the 1.5% category. FCC ships 176 personas with 10-component R.I.S.C.E.A.R., discernment matrices, 56 persona dimensions and design-target factors. The evidence says the leverage is elsewhere: in verification, termination conditions, and enforcement.

5.4 What does work — and both mechanisms are downstream of the spec

Training on a specification works. Constitutional AI (2212.08073) produces a harmless but non-evasive assistant from a written list of principles. Deliberative Alignment (2412.16339) "directly teaches the model safety specifications and trains it to explicitly recall and accurately reason over the specifications before answering," reporting simultaneous gains in jailbreak robustness and reduced overrefusal.

A caution from the same literature that cuts against elaborate specification: arXiv 2310.13798 finds the largest models generalise from a single short principle to a helpful, non-harmful assistant — but "more detailed constitutions still improve fine-grained control over specific types of harms." Read onto FCC: 400 sentences of general professional conduct likely buy little; a small number of rules targeting a specific named harm in a specific domain is where detail pays. That is an argument for the 45 verticals and against expanding the core.

Runtime enforcement of specifications works, dramatically. AgentSpec, arXiv 2503.18666 (ICSE 2026) defines a lightweight DSL of triggers, predicates, and enforcement mechanisms applied at runtime:

  • code agents: prevents >90% of unsafe executions
  • embodied agents: eliminates all hazardous actions
  • autonomous driving: 100% compliance with safety constraints
  • overhead: milliseconds

This is the report's decisive contrast. Same underlying idea as FCC's constitution — write the constraint down — but enforced as executable predicates rather than trusted to a model or a substring match. >90–100% versus RuLES' "almost all models struggle." The variable is enforcement, not authorship.

5.5 The documentation-as-accountability precedent is weaker than FCC assumes

FCC's model cards cite Mitchell et al. and Gebru et al. as precedent. Both are worth reading precisely.

Neither paper contains efficacy evidence. arXiv 1810.03993 and arXiv 1803.09010 are normative proposals with templates and worked examples. The founding artifacts of the documentation-as-accountability literature are not empirical results.

Adoption is real and shallow. Of 74,970 Hugging Face repos, 32,111 (44.2%) had model cards, accounting for 90.5% of download traffic. But section fill rates: Training 74.3%, Limitations 17.4%, Evaluation 15.4%, Environmental Impact 2.0% (arXiv 2402.05160). The ethically load-bearing sections are the empty ones.

The one causal result measures the wrong outcome. The same authors wrote detailed cards for 42 undocumented models; the treatment group gained +29.0% weekly downloads (95% CI [10.6%, 47.5%], p = 0.01) in batch 2, with batch 1 null. The best-evidenced effect of writing a model card is increased downloads — an adoption outcome, not a safety or accountability one.

External ranking moves behaviour; the effect decays. FMTI rose from an average 37/100 (2023) to 58/100 (2024), with developers disclosing on average 16.6 previously non-public indicators (arXiv 2407.12929). By 2025 it had fallen to 40.69 (arXiv 2512.10169), with the residual effect being that companies score better when they engage with the scorer.

And the transparency community has named FCC's implicit assumption a fallacy. arXiv 2601.18127 (2026-01-27), authored from inside the Stanford transparency camp, identifies three: the comprehensibility fallacy (disclosed ≠ understood), the efficacy fallacy (transparency alone drives behavioural change — the causal link "remains unestablished"), and the accountability fallacy (disclosure treated as equivalent to accountability, creating "compliance theater rather than substantive safeguards").

There is one counterweight worth keeping. Retrospectively datasheeting BookCorpus surfaced likely copyright violations, thousands of duplicated books, and severe genre skew (arXiv 2105.05241). Documentation does surface real problems — when it is actually performed. That it went unperformed for years on one of the field's most consequential datasets is the other half of the lesson.

5.6 What the EU AI Act would actually require

The regulatory reading is more forgiving than §5.5 but still bounded. (Article texts from artificialintelligenceact.eu, an unofficial but widely used mirror — re-verify against EUR-Lex before relying on any of this legally.)

Where a per-persona specification is a plausible input to an Annex IV technical file:

Annex IV / Article What it asks for Why a persona spec is responsive
Annex IV §2(b) "design specifications, logic, algorithms, key design choices" A declarative constraint spec is a design specification.
Annex IV §2(e) "assessment of the human oversight measures" (Art. 14) Per-persona escalation, hard-stop and handoff rules map directly.
Annex IV §2(f), Art. 13(3)(c) pre-determined changes A versioned spec with a governed change process is exactly this artifact.
Annex IV §3 human-oversight and input-data specifications Directly addressed.
Art. 17(1)(m) "an accountability framework setting out responsibilities of management and staff" A per-role responsibility model maps cleanly.

Where it does not reach, and where the over-claim would occur:

  • Annex IV §2(g) — validation and testing procedures with metrics and test reports/logs, dated and signed. A specification is not test evidence. This is the largest gap: the Act repeatedly demands measurement, not declaration.
  • Annex IV §4 — justification that the chosen performance metrics are appropriate. Empirical argument required.
  • Annex IV §5 / Art. 9 — the risk management system as a continuous, iterative, documented process with post-market feedback. A static spec is not a process.
  • Art. 12 — automatic event logging is a runtime capability. No document satisfies it.
  • Art. 14(4)(e) — the system must be designed so an overseer can interpret, override and stop it. A sentence saying "the persona escalates to a human" is not that interface.
  • Annex IV §8, §9 — declaration of conformity; post-market monitoring plan.

Two further cautions FCC must not skip.

First, for the large majority of Annex III high-risk systems, conformity assessment is provider self-assessment under Annex VI (Art. 43) — no notified body reviews the technical documentation. The accountability comes from market surveillance, post-market monitoring, incident reporting and penalties, not from anyone checking the file at the gate. A conformance artifact nobody independently examines buys less than it appears to.

Second, and more fundamental: a framework of design-process personas is unlikely to be a high-risk AI system under Annex III at all. Annex IV obligations attach to a provider placing a high-risk system on the market. Framing persona specs as "Annex IV artifacts" for a framework outside scope is a category error independent of the sufficiency question.

The timeline has also moved. Regulation (EU) 2026/1744 (the "Digital Omnibus on AI"), in force 2026-07-27, postponed Annex III standalone high-risk obligations to 2 December 2027 and Annex I embedded high-risk to 2 August 2028. GPAI obligations (2 Aug 2025) and Art. 50 transparency (2 Aug 2026) were not delayed (eur-lex.europa.eu/eli/reg/2026/1744/oj/eng; corroborated by Hunton, 2026-07-28, retrieved 2026-09-04 — the EUR-Lex fetch returned an empty body, so this date should be re-verified before being relied on).

NIST AI RMF adds no counterweight. It is "intended for voluntary use", its 56 subcategories are explicitly "not a checklist", and no certification mechanism was found (nist.gov, airc.nist.gov core). There is no conformance status documentation could earn. FCC's 29 NIST subcategory mappings cannot make anything compliant, because there is nothing to be compliant with.

§6 The 45-vertical gap

6.1 The measurement

fcc catalog export --format jsonl --include-verticals produces 176 records. The committed docs/catalog/v2.2.0/catalog.jsonl is byte-consistent with it:

records: 176        records with empty hard_stop: 45
by domain: finance 11, healthcare 11, energy 6, government 6, insurance 6, legal 5

The cause is structural, not editorial. VerticalPersona has no doc_context attribute at all — its fields are id, name, role_title, category, domain, compliance_frameworks, riscear, risk_category, dimension_profile, display_name_i18n, riscear_role, has_nested_riscear. grep -c constitution src/fcc/data/verticals/*.yaml returns 0 for all six files. The catalogue's hard_stop: [] is manufactured by _enrich (cli.py:2341-2346) defaulting an absent key, not by anyone writing an empty list.

And per §1.3, nothing catches it: vertical.schema.json does not mention constitution, and no CI guard requires one.

6.2 Which personas this switches off

19 of the 45 are personas FCC itself classifies as HIGH risk under the EU AI Act — and they carry zero hard-stops:

domain id persona frameworks
healthcare PSE Patient Safety Engineer HIPAA, FDA 21 CFR Part 11
healthcare MDS Medical Device Software Engineer IEC 62304, ISO 13485, EU MDR
healthcare HCO HIPAA Compliance Officer HIPAA
healthcare CTR Clinical Trial Researcher FDA 21 CFR Part 11, HIPAA
healthcare GMR / CIE Genomic Medicine Researcher / Clinical Imaging Engineer HL7 FHIR, DICOM, IMDRF SaMD
energy NCP NERC CIP Compliance Officer NERC CIP
energy GMM Grid Model Manager IEC 61970 CIM, IEC 61968, ENTSO-E CGMES
energy DRP Demand Response Planner FERC Order 2222, NERC CIP
finance SCA / CCR / MRV SOX Compliance Auditor / Counterparty Credit Risk / Model Risk Validator SOX, Basel III, SR 11-7
government NIE / GPIA / DIA NIEM Architect / Privacy Impact Assessor / Digital Identity Architect NIST SP 800-53 Rev 5, FedRAMP, Privacy Act 1974
insurance IUW / CFD Underwriter Analyst / Claims Fraud Detection ACORD, Solvency II, NAIC GDL-1690
legal LDPA / GCA2 Legal Data Privacy Analyst / GDPR Compliance Architect GDPR

A further 16 of the 45 carry no risk_category at all; 10 are limited.

Set this against §3.4: the 131 personas that do carry hard-stops are all classified HIGH by a heuristic that fires on everything, and their rules govern documentation quality, schema versioning and code review. FCC's guardrails are fully populated where a hard-stop is boilerplate and entirely absent where a hard-stop is a safety claim. For the purposes of §5.4's finding — that detail pays only on specific named harms — this is precisely inverted.

6.3 The safety content exists; it is in the field the contract calls advisory

This is the part that changes the remediation from "write 45 constitutions" to "promote and rewrite existing material."

All 45 vertical personas carry riscear.constraints — 244 strings: healthcare 61, finance 55, government 36, energy 30, insurance 30, legal 32. And they are markedly more specific than any core hard-stop. NCP's, verbatim:

No BES Cyber Asset change may bypass CIP-010 Part 1 configuration baseline
   and Part 2 change authorization
Every Reportable Cyber Security Incident triggers the CIP-008 one-hour
   E-ISAC notification clock
CIP-013 vendor controls must be verified before procurement of any BES Cyber
   System hardware or software
Interactive remote access must traverse an Intermediate System with
   multi-factor authentication per CIP-005 R2
Physical access to Medium/High Impact BES Cyber Systems must be logged and
   reviewed per CIP-006

Compare the median core hard-stop — "Never skip quality review before downstream handoff." The vertical constraints name a standard, a clause, and in one case a one-hour clock. These are closer to AgentSpec triggers-and-predicates than anything in the core corpus.

But the contract classifies flat constraints[] as "advisory / folded into mandatory" (paom-sentinel-coordination.md:21), so none of it counts toward runnability.

The honest scope of the remediation. Only 34 of 244 (14%) are in prohibitive form today — energy 4, finance 6, government 6, healthcare 15, insurance 1, legal 2. The other 210 are phrased as requirements ("must be verified", "triggers the clock") and would need rewriting, not relocating. This is a domain-expert task in six regulated fields, and §5.4's warning applies with force: a wrong NERC CIP hard-stop is worse than an absent one, because it would make a runtime confidently permit something it should refuse.

6.4 FCC's own documents still assert the opposite

Three shipped artifacts state a claim §6.1 falsifies. Commit 329e1883 ("correct a false runnability claim") fixed some of them; it touched CLAUDE.md, docs/developer/public-api.md, paom-sentinel-coordination.md and tests/test_public_api.py — and missed the rest.

  1. archetype-persona-agent-binding.md:41-44 — the binding contract itself, the artifact whose entire purpose is to tell a consumer what to expect: "A persona without constitution.hard_stop is not runnable… As of v1.9.1 every FCC persona carries a hard_stop." The first sentence is the contract. The second is false for 45 personas. :52-55 compounds it: "Both core and vertical personas bind. The catalog export covers core (131) + vertical (45) = 176 personas."

  2. paom-sentinel-coordination.md:21 — inside the file that 329e1883 corrected. Decision row 4 still reads "(PAOM rejects personas without it — all FCC personas carry one as of v1.9.1)", while lines 32-40 of the same file carry the corrected 131/176 split and quote SENTINEL catching the error. The file contradicts itself 11 lines apart.

  3. src/fcc/contributions/dossier.py:76 — in code, in the artifact FCC publishes to report its own ecosystem contribution: 

    paom_runnable=persona_count,  # all personas carry hard_stop as of v1.9.1
    persona_count is incremented once per catalogue line (:64), so this reports 176 PAOM-runnable while reading records 45 of which carry constitution.hard_stop: []. The fix is one line — count records whose hard_stop is non-empty.

A specification project's credibility rests on its documents being true. Three of them are not, in the exact place where the safety claim is weakest. This is the most immediately fixable finding in this Find and the one a skeptic would reach for first.

6.5 The model cards propagate it to readers

docs/model-cards/personas/patient_safety_engineer.md — the card for a persona operating under HIPAA and FDA 21 CFR Part 11 — contains under Ethical Considerations, in full:

This persona operates within the FCC framework's constitution and governance tiers. Review hard-stop rules before deployment.

PSE has no hard-stop rules. The card is byte-identical boilerplate to the core cards. It also has no Risk Category section, despite vertical_risk_profiles.yaml classifying PSE as high under Annex III.1.

Against the precedent FCC cites: model_card.schema.json requires only [model_name, model_version, model_type, owner, intended_use, last_updated] — no evaluation data, no quantitative analyses, no disaggregated performance, no caveats section, which are the substance of Mitchell et al. Given §5.5's measured fill rates (Limitations 17.4%, Evaluation 15.4%), FCC's cards land in the majority pattern: present, and empty where it counts. docs/model-cards/index.md also still reports 173 cards / 147 persona / 102 core, stale against 176 / 131.

§7 What FCC has that is genuinely portable

Having been unsparing, the inverse must be equally precise, because it is where the actual contribution lives.

7.1 Every rule has a stable, citable identity — and nobody else does this

The Train-7.0 vocabulary store (ADR-018) assigns all 1,299 deduped rules (400 hard_stop / 505 mandatory / 394 preferred) a two-layer FQN:

fqn         fcc:constitution:hard_stop_never_hardcode_secrets_or_credentials_in_application_code
catalog_fqn FCC_v2::Constitution::HardStop::HardStopNeverHardcodeSecretsOrCredentialsInApplicationCode
payload     {"tier": "hard_stop", "text": "...", "personas": ["AMK"]}

Set that against §4.3: Anthropic's constitution has no rule IDs; OpenAI's Model Spec has no formal rule IDs; MLCommons' taxonomy is a PDF on Google Drive; A2A has no constraint field at all. FCC has done something none of them has: made every individual behavioural rule addressable, versioned, and back-referenced to the personas that carry it.

That is not a safety property. It is the precondition for one. A runtime that refuses an action can cite fcc:constitution:hard_stop_… in its refusal; an auditor can ask which personas carry that rule and get an answer; a regression can be expressed as "rule X stopped firing." None of that is possible with a 26,000-word essay.

Two honest qualifications.

First, identity is derived from the rule text. build.py:198 computes base = f"{tier}_{fqn.slugify(text, max_len=60)}". Rewording a rule changes its FQN. For an identifier whose purpose is stable citation across versions, that is a defect — and it is latent rather than theoretical: the slug truncates at 60 characters, so two rules differing only after that point collide and are disambiguated by an iteration-order-dependent _2 suffix. Measured today: 0 collisions. The mechanism is one long rule away from producing one.

Second, the shared vocabulary is a fiction. Dedup takes 1,302 strings to 1,299. Only 3 rules are shared by more than one persona, and zero hard-stops are shared by more than one persona. The constitution namespace is described as "Reusable governance rules" (build.py:179); in practice it is 400 single-use sentences with identifiers attached. There is no common safety vocabulary at the tier that matters — which is a missed opportunity rather than a defect, since a small shared set of enforceable rules would be far more valuable to a consumer than 400 bespoke ones.

7.2 Regulatory anchoring that is real analysis

Per §3.6: 45/45 coverage, 45/45 rationales, 21/45 named Annex III clauses, genuinely differentiated outcomes. Per §5.6, the fields this could legitimately feed are Annex IV §2(b), §2(e), §2(f), §3 and Art. 17(1)(m). This is a defensible traceability asset today, and it is the only part of FCC's compliance surface that survives §3's scrutiny.

7.3 A published contract that a runtime already gates on

archetype-persona-agent-binding.md:35:

constitution.hard_stop / mandatory / preferred | doc_context.constitution | FCC (authoritative) | the 3-tier guardrails; hard_stop is mandatory for a runnable agent

And :41-42: "A persona without constitution.hard_stop is not runnable — the consumer must reject it."

This is the right architecture, at the right seam. FCC declares; an independent runtime refuses. It is the AP2 pattern (§4.5) and the AgentSpec pattern (§5.4) applied to persona specification: the authoring party does not enforce, and the enforcing party did not author. It is also the only place in the entire FCC surface where a specification produces a refusal rather than a prompt.

Two bounds. The gate is presence-only — it checks that hard_stop is a non-empty list, never what the rules say, so it is satisfied by three arbitrary sentences. And PAOM's rejection behaviour is quoted, not observed (could_not_establish item 3).

7.4 The distribution surface exists

catalog.jsonl (176 enriched records: full R.I.S.C.E.A.R. + canonical archetype + PAOM-8 enum + constitution), paom_override_map.json (168 labels), plus SKOS and JSON-LD forms, published per version under docs/catalog/v<ver>/. ask_service.py:262-281 serves a paom_binding block carrying the constitution live.

The one gap, per §4.4: a2a_card.schema.json carries neither constitution nor hard_stop, and vertical personas get a2a_card: None anyway. But A2A has no field to put them in, so this is the standard's limitation and not FCC's — a point in FCC's favour, since FCC's bespoke binding surface carries strictly more than the open protocol can.

§8 The mechanism: how a spec could make ANY framework safer

Distinguishing, as required, what FCC has from what it would have to build.

8.1 What FCC has today

Mechanism Status Evidence
Citable rule identity a runtime can name in a refusal Have. 1,299 FQNs §7.1
Persona → EU AI Act risk category with Annex III rationale Have. 45/45, 21 clause-anchored §3.6
A published contract a consumer gates on Have, presence-only §7.3
Versioned machine-readable distribution Have. catalog.jsonl + override map §7.4
Prompt-time constraint injection Have — and §5.2 says it does not reliably work action_engine.py:73-92
Any enforcement of rule content Do not have. §2 —
Any rule → article traceability edge Do not have. §3.7 —
Any measurement that a spec changes behaviour Do not have. §3.5 —

8.2 What it would have to build — in dependency order

(1) A checkable form for the rules, modelled on AgentSpec. AgentSpec's three-part shape — trigger (an observable agent action), predicate (a checkable condition), enforcement (what to do) — is the demonstrated-effective structure (§5.4). FCC's rules would need to carry that structure alongside the prose, not instead of it.

Measured feasibility, which is the honest number here. Of the 400 hard-stops:

  • 98 (24%) name an observable, artifact-producing action verb (deploy, publish, commit, merge, expose, send, export, approve, hand off…).
  • 166 (42%) contain a condition clause (without, unless, that fails, exceeding, below, that violate).
  • 57 (14%) contain both — i.e. are already latent trigger+predicate pairs.

The 57 read almost as AgentSpec rules already:

Never deploy UI components without accessibility compliance verification
Never publish an event that fails its schema
Never approve a release that fails a mandatory governance gate
Never deploy to production without passing security scans

The other 343 do not, and several of the most important cannot be: "Never fabricate research sources or citations" has no observable trigger and no computable predicate. Roughly one in seven of FCC's hard-stops is mechanisable in its current wording. Stating this as "the constitution can be made enforceable" without the ratio would be the over-claim.

(2) A schema that requires what the contract requires. hard_stop must move out of the free-form doc_context (§1.3) into schema-required territory, in persona.schema.json and vertical.schema.json, with a CI guard. This is small, entirely within FCC's control, and would have made §6 impossible.

(3) Rule → requirement edges. Today the evidence graph carries rule counts (§3.7). A traceability chain means fcc:constitution:hard_stop_… → EU-AI-ACT-ART14-4 as a first-class edge, hand-authored the way vertical_risk_profiles.yaml was and reviewable the same way. Note §5.6: this supports Annex IV §2(b)/(e)/(f) and Art. 17(1)(m). It does not touch §2(g) test evidence, Art. 12 logging, or the Art. 9 process.

(4) A conformance suite a third-party framework can run. The portability claim is currently untested (could_not_establish item 4). What would substantiate it: a fixture set of (persona, candidate output, expected verdict) triples — including the adversarial cases in §2.2 — that any runtime can execute to demonstrate it honours FCC's constraints. That is what makes "framework-independent" a measurable property rather than an aspiration.

(5) Delete or quarantine what cannot be true. validate_persona (§2), _compute_assurance (§3.5), the >= 3 → HIGH heuristic (§3.4), the persona_findings substring match (§3.7), and the unconditional-PASS auditor (§3.2) each assert a capability the code does not have. Whatever else is built, shipping code that cannot fail is a larger liability than shipping no code at all, because it produces artifacts a reader will reasonably mistake for findings.

8.3 The mechanism stated plainly

FCC does not make a framework safer. FCC makes it possible for a framework to be held to something — by publishing constraints that are individually addressable, version-stable, regulation-anchored, and refusable, and by publishing a test that shows whether a given runtime honours them.

The safety is produced by the runtime's refusal. FCC's contribution is that the thing refused has a name, a version, and a citation. On the current evidence that is a real and unusual contribution (§7.1), and it is strictly smaller than "our spec makes things safer."

§9 What would make this credible to a skeptic

In ascending order of cost. Items 1–3 are entirely within FCC's control and require no partner.

  1. Fix the three false claims (§6.4). A specification project that misstates its own catalogue's contents has no standing to make claims about anyone else's safety. One doc edit, one contract-doc edit, one line of Python.
  2. Make the schema enforce the contract (§8.2 item 2), and add the CI guard. Then the vertical gap becomes a build failure rather than a research finding.
  3. Delete the mechanisms that cannot fail (§8.2 item 5), or gate them behind an explicit --advisory flag that names them as heuristics. A skeptic who finds return 1.0 if total == 0 else 1.0 in a safety metric will not read further, and will be right not to.
  4. Publish the six energy hard-stops as the worked example. Smallest scope, sharpest domain, source material already present and unusually specific (§6.3), and it takes runnable personas from 131 to 137. Run it through FCC's own Critique stage with a domain reviewer — §5.4 and §6.3 both warn that a wrong NERC CIP rule is worse than an absent one. Then publish the diff: here is what a hard-stop looks like when it is a safety claim rather than boilerplate.
  5. Ship the conformance suite (§8.2 item 4), including the §2.2 adversarial cases as fixtures. Demonstrate one non-FCC runtime passing it — agentgateway's CEL policies over MCP tool calls are the most plausible target, since a policy author is already a third party there (agentgateway.dev/docs, retrieved 2026-09-04).
  6. Run the ablation FCC is uniquely positioned to run. FCC owns a simulation engine, 33 scenarios, and 176 specs. Same scenario, same model, three arms: no persona spec / persona spec in prompt / persona spec with runtime enforcement of the mechanisable subset. Measure constraint violations, not task quality. The literature predicts arm 2 ≈ arm 1 and arm 3 ≫ both (§5.2, §5.4). If that replicates, FCC has the first direct evidence on the question §5.1 says nobody has answered, and the finding is publishable whichever way it lands. If arm 2 beats arm 1, that is a genuinely novel result and FCC found it. If it does not, FCC has earned the right to say what its specification is for — and the honest answer, per §8.3, was never "the prompt."

§10 Is specification-as-safety a real contribution or governance theatre?

The case for theatre

It is strong, and it is mostly built from FCC's own code.

The audit cannot fail (31,702 findings, zero possible failures, §3.2). The safety metric is a constant (§3.5). The risk classifier returns one value (§3.4). The enforcement checker flags compliant text and passes real violations (§2.2). The evidence graph doubles some personas' edges by substring collision (§3.7) and contains no rule-level traceability at all. Three shipped documents assert a runnability property 45 personas do not have (§6.4), and a model card for a Patient Safety Engineer instructs the reader to "Review hard-stop rules before deployment" when there are none (§6.5).

The external literature supplies the frame: this is the accountability fallacy — "disclosure treated as equivalent to accountability… creating compliance theater rather than substantive safeguards" (arXiv 2601.18127). And the efficacy fallacy: the causal link from documentation to changed behaviour "remains unestablished." Measured adoption data agrees — 44.2% of model cards exist, 15.4% document evaluation (§5.5) — and the one causal result measures downloads.

Worse for FCC's specific bet: MAST puts "disobey role specification" at 1.5% of multi-agent failures (§5.3). FCC's largest investment — 176 personas, 10-component R.I.S.C.E.A.R., 56 dimensions, discernment matrices — targets the smallest failure category the field has measured.

The case for real contribution

Also strong, and it survives the above.

Every mechanism that demonstrably works is downstream of a written specification. Constitutional AI needs the principles. Deliberative Alignment needs the safety spec to train on. AgentSpec needs the rules to compile into predicates. AP2 needs the Mandate content. You cannot train on, enforce, or verify a specification you have not written. The literature's negative results are about prompting with specs — a delivery mechanism, not the artifact.

And FCC has built the part nobody else has. Anthropic: no rule IDs. OpenAI: no rule IDs. MLCommons: a Google Drive PDF. A2A: no constraint field, and issue #1628 still unaccepted. MCP maintainers, in writing: "They aren't enforcement." NIST's multi-agent overlay is not drafted. Against that, 1,299 individually addressable, version-anchored, persona-back-referenced rules is a real artifact in a field that has none (§7.1) — and 45 personas mapped to Annex III clauses with written rationales is real analysis (§3.6).

The architecture is also correct. FCC declares, an independent runtime refuses (§7.3). That is exactly AP2's separation of Mandate author from Verifier, and exactly what makes AgentSpec effective. FCC drew the seam in the right place; it simply has not made the thing crossing it checkable.

Position

Both, and the two describe different layers.

  • The declarative layer is a real contribution, currently the strongest thing FCC ships, and undervalued by FCC itself. Rule identity, regulatory anchoring, a gated consumer contract, and a versioned distribution surface are genuinely scarce, and FCC describes them as plumbing while advertising the parts that do not work.
  • The enforcement layer is theatre and should be withdrawn. Not softened — withdrawn. validate_persona, _compute_assurance, the auditor's PASS-only verdicts, and the constant classifier are not weak implementations of a good idea; they are artifacts that a reader will mistake for evidence. §3.2's report says "31,702 checks passed", and a reasonable reader would conclude something was checked.

The defensible claim, and this Find recommends adopting it verbatim in place of the current framing:

FCC publishes citable, versioned, regulation-anchored constraint identities that a runtime can gate on — and can demonstrate that a runtime does.

Nothing in that sentence is unearned today except the last clause, and §9 item 5 earns it.

The claim FCC must stop making — in archetype-persona-agent-binding.md, in paom-sentinel-coordination.md, in dossier.py, and in every model card's Ethical Considerations block — is that the specification, by existing, makes anything safe. On the evidence assembled here it does not, nobody has shown that it could, and FCC's own instrumentation is incapable of noticing either way.

There is one thing that would change this, and FCC is unusually well placed to do it: run the ablation (§9 item 6). It is the experiment the field has not run, FCC owns every component needed, and the result is worth publishing in either direction.

§11 Honest bounds

Restating the four that most constrain how this document may be used:

  1. No safety claim about FCC's specification is made anywhere above, because none could be evidenced. The direct study does not exist (§5.1); the nearest evidence measures task success and reports its own insufficiency (§5.3); and FCC's own assurance metric is a constant (§3.5), so FCC has never measured it either. Any later document citing this Find as support for "FCC's spec makes simulations safer" is misciting it.
  2. PAOM's rejection behaviour is quoted, not observed. The 131/176 split is measured on FCC's side of the seam only.
  3. No third-party framework was tested against an FCC spec. §8's portability mechanism is a design argument, not a demonstration.
  4. Neither external survey was exhaustive — both exhausted their search budget and finished on direct fetches of known URLs. Every "no evidence found" means "not found in a moderately thorough search." Unverified external items are enumerated in the front matter and must not be hardened by later readers.