Governance & Honest Scope

The other five pillars are the language. This pillar is what makes the claims about that language trustworthy — a public marketing-claims ledger, numbered decision provenance, a documented multi-party council process, and an explicit Mirror-mode self-disclosure. Without it, the rest is specification without warrant.

The honesty triad

Honest scope at Arcana is three surfaces that have to be read together, not one:

1. What Arcana will not do

Explicit non-promises — capabilities deliberately kept out of the language layer, design directions rejected with documented rationale, scope boundaries we won’t cross. The non-promises are the same kind of artifact as the approved features: numbered, citable, durable.

Examples: Arcana does not annotate effect reversibility at the language layer (rejected by council — reversibility lives at SDK + policy layer instead); Arcana does not detect “rubber-stamping” of effect-widening reviews at the language layer (rejected as a noun-phrase product feature); Arcana does not promise PII-handling verification before deployment (the claim is moot — no shipped surface ever made it).

Each non-promise is surfaced inline at the relevant pillar with the decision-record pointer. The consolidated N-numbered record publishes publicly alongside the v1.x complete release.

2. The current honest state

A maintained KNOWN-ISSUES disclosure: scoped capabilities, partial layers, where our own process has limits. This is the document we surface first for any serious evaluator — what’s known to be partial or limited, before any other claim is read. The disclosure includes:

Taint analysis coverage gaps (per WP-34 §7.1).
Per-layer maturity of the four-layer safety stack (Layer 1 shipped; Layers 2-4 partial, named by mechanism).
Mirror-mode risk in the council governance cycle itself (AI-only review at present; honest disclosure).
Self-hosting state — codegen output production-quality, verification-harness migration in progress (see Self-Hosting).

3. Open intentions, not commitments

Open Intentions is the inverse-polarity counterpart of the non-promises. Where non-promises name what we deliberately won’t do, open intentions name what we want, don’t yet have, and explicitly will not promise.

The discipline here is precise: intent-without-commitment language only. Any phrasing along the lines of “will ship,” “coming in,” “planned for vY,” “by date,” “next release” is a hard violation. The whole point of the section is the absence of commitment.

Triple function (not just trust signal):

Credibility signal for human readers — “we want this, we’ll be honest that we don’t have it.”
Guardrail for AI code generation — tells generators which capabilities exist on the wish-list but NOT to generate code against them as if they were shipped.
Boundary-setting for future training data — ensures the next generation of AI tools sees these capabilities labeled correctly in their training corpus.

What backs the triad

A public marketing-claims ledger

Every claim Arcana makes externally is either explicitly approved (an A-class claim with a documented scope hedge) or explicitly rejected (an R-class entry the project commits to never using, even in negation). Approved claims pin to specific shipped mechanisms; rejected claims describe shapes that overclaim scope.

The ledger isn’t a thought experiment — it’s enforced by a pre-tag grep that fails the release build if a rejected phrasing slips into a release-candidate surface. See Claims Ledger for the canonical A-class / R-class list.

Decision provenance

A numbered record (D-prefixed entries — D001, D002, …) of every architectural decision the project has made, with full rationale, debate records when applicable, and amendment history. The record is searchable, citable, and durable. When a downstream evaluator asks “why does Arcana do X this way,” the answer points at a numbered decision rather than an oral history.

A documented multi-party council process

Major design decisions go through a structured council process — multiple perspectives, explicit convergence criteria, archived round notes. The process is itself a documented artifact (COUNCIL-PROCESS.md) rather than implicit practice. The current council format is a 16-perspective unbundled review (the 16P UNBUNDLED format) for substantive decisions, with founder ratification recording the binding choice. A council session iterates R1 → R2 → R3 until perspectives converge unanimously; the founder then ratifies the converged verdict, which lands in governance/DECISIONS-LOG.md with a D-number.

Council process limitations are themselves disclosed (see Mirror-mode below).

The council members

The 16 perspectives are role-typed AI reviewers, each scoped to a distinct review function. Each reviewer reads the same decision proposal independently and produces a per-perspective verdict; the convergence criterion is unanimous BARE PASS (no AWN — “approved with notes” doesn’t count toward convergence under the founder’s R3-doctrine). The roles are:

guardian — enforces founder-protected discipline (files and decisions the founder has explicitly locked from modification without re-ratification). Catches scope creep.
historian — verifies the proposal against prior decisions and amendment history. Catches contradictions with earlier ratifications and stale-claim drift.
formalist — checks machine-readable structure: schemas, JSON discriminators, EBNF grammar conformance, regex validity. Catches “looks right, isn’t parseable.”
vision-keeper — checks the proposal against the project’s stated brand and pillar structure. Catches drift from the locked launch narrative.
compiler-eng — reviews implementation feasibility against the actual compiler state. Catches “spec assumes something the compiler can’t do yet.”
mobile-practices — verifies multi-target codegen claims (iOS Swift, Android Kotlin emitter compatibility, mobile-specific effect parameterization). Catches mobile-codegen regressions before they ship.
security-auditor — reviews security claims and threat-model assumptions. Catches “this is more open than the prose admits.”
interface-designer — checks UI / DX / developer-affordance claims. Catches “this would confuse a real user at first encounter.”
performance-reviewer — checks claims about compile speed, runtime cost, codegen output size. Catches performance regressions disguised as features.
accessibility-auditor — checks accessibility claims (especially for the page / component multi-target codegen). Catches ARIA / contrast / keyboard-nav drift.
trajectory — checks whether the proposal’s roadmap commitments are coherent with the broader version trajectory. Catches version-anchor mismatches.
readability-reviewer — checks the prose and documentation for clarity. Catches “this is technically correct but unreadable.”
error-analyst — reviews the error-code register integrity. Catches duplicate / orphaned / mis-tier’d error codes.
impl-auditor — runs the spec-vs-impl symmetry check against the actual repo state. Catches “claimed shipped, not actually wired.”
pragmatist — checks for over-engineering. Catches “this is more discipline than the actual risk warrants.”
integration-checker — checks whether the proposal composes correctly with adjacent specs and prior decisions. Catches integration-level breakage that none of the per-component perspectives catch.

These are AI perspectives, not human PL experts. The Mirror-mode disclosure below explains the structural risk this creates and the mitigation path. Naming the roles explicitly is itself part of the discipline: a SecOps reader can see the council process isn’t a black box, can map a given decision’s verdict back to which perspectives approved it, and can identify which perspectives might be systematically blind to a given risk class.

An in-progress move toward release discipline that is verifiable

The current release-gate is a multi-mechanism gate (make release-gate) that checks for substantive items — spec ambiguity sweep, effect-soundness fuzzing, codegen golden tests, security review, messaging calibration, the KNOWN-ISSUES.md disclosure, response readiness. Moving the gate from attestation-of-presence to re-executable evidence (gate items running their stated checks at release time, not just signing off they ran) is a ratified roadmap item. Honest framing: the discipline exists; the automation of the discipline is filling in. See Claims Ledger for the current state.

Synthetic-violation test corpus + meta-process gate audit

The discipline above is backed by a structural mechanism: every blocking error code carries a synthetic-violation regression test that runs on every compiler change. A canary-of-canary sentinel fails the runner if the runner ever no-ops — so the project doesn’t just trust that “the gate fires”; the gate’s continued firing is itself audited. This is the same kind of compile-time-checked discipline Arcana applies to user code, applied recursively to its own release-gate. It’s an approved A-class claim in the marketing-claims ledger because the mechanism is shipped and the meta-process is operational, not aspirational.

Mirror-mode self-disclosure

Arcana’s own taxonomy includes a failure mode it names Mirror-mode — when an AI generator and an AI reviewer (both trained on overlapping corpora) close a review loop with hallucinated consensus, missing shared blind spots a human or off-corpus reviewer would catch.

The honest disclosure: the current Arcana council process is staffed by AI from a single model family. By Arcana’s own framework, this exhibits the structural conditions of Mirror-mode failure. The primary mitigation for this release is the public release itself — external human readers, security researchers, and AI agents from different model families evaluating the spec, the decision record, and the governance archive provide exactly the off-corpus review that Mirror-mode requires.

We are releasing specifically to get that review. We are not claiming the AI-only governance is “fine”; we are saying it exhibits a structural risk our own framework names, and the path to reducing the risk is publication + external review.

On formal external security review

Review during current development is AI-only; no formal external security review is in place. Our safety claims are deliberately hedged today — qualifying their scope, their gaps, and where they don’t apply. Those qualifiers stay until a formal external security review independently confirms that broader claims are defensible. We are not committing to when, or whether, such a review will take place — only that the hedges stay until then.

If you are an external security researcher reading this and would consider an informal review pass on the public artifacts (the spec, the decision record, the claims ledger, the KNOWN-ISSUES disclosure), that interaction is welcome at [email protected] — not as a substitute for formal review, but as a path toward one.

What this pillar gives every other pillar

Every claim in Compile-Time Safety, Effect Contracts, Batteries-Included, Runtime, and Self-Hosting is grounded by this pillar’s discipline. The hedges aren’t decoration; they’re the contract that lets the unhedged parts hold.