We do not judge a program memory-safe from a few tests; we compile it
against a type system. Yet AI agents now govern what runs, what is
remembered, when review is required, and which instruction wins, while
their rules are still certified largely through finite evaluation. We
propose a comparable compiler target for the governance rule itself. A
semantic legitimacy kernel bundles five separately load-bearing runtime
obligations with graph diagnostics, a scaling witness, and an explicit
bridge contract; a concrete Lean instance proves that the class is
inhabited. Two machine-checked theorems give the object operational
force. An obstructed rule may go live only after declaring its forced
sacrifices, and a governed trajectory either preserves the kernel
invariant or emits an indexed sacrifice certificate. A companion
impossibility explains why the declaration is necessary: a rule that
reaches a scarce, peer-relative stage cannot keep the full diagnostic
package. On a constructed canonical claimant-interaction lift, a
shared-substrate theorem then prices that obstruction as a finite,
computable capability ceiling. All proofs are checked in Lean 4 with no
sorry, admit, or first-party
axiom. We reuse classical Arrow/Young/Thomson diagnostics;
the novelty is the typed compiler target and bridge contract. A bounded,
unverified Rust extractor turns real agent harnesses into graph models,
so current rejections are theorem-backed statements about those
extracted graphs rather than verdicts on live products. ##
Highlights
Object of the paper. A semantic legitimacy kernel is a typed artifact for a governance rule: runtime obligations + graph diagnostics + scaling witness + bridge contract. It is the spine; everything else in the framework either targets it or forces a property of it.
Inhabited, not merely defined. The five runtime obligations are carried by a concrete kernel instance in the Lean model (
permitKernel), so the object class is non-empty by construction, not by stipulation.permitKernelis a minimal non-emptiness witness: it discharges corrigibility on a zero-action-capability surface and compositional safety on an edge-free DAG; richer inhabitants such asboundaryExitKernel(an edged causal DAG) and a unit-capability threshold kernel relax each triviality on its own axis.
Evidence tier. Formal object and definitional decomposition over the Lean model; Rust extraction and source-derived graphs are artifact evidence unless promoted by a separate source-to-graph theorem.
Real-harness audit panel. Verdicts are theorem-backed statements about the extracted graph models; source-to-graph faithfulness is the declared trusted base (§6).
| Harness surface | Extracted graph | Verdict | Lean anchor |
|---|---|---|---|
| OpenAI Codex hooks | 16 nodes / 8 edges | rejected: monotonicity | codexHooksGovernanceAdmissibilityRejectsMonotonicity |
| Claude Agent SDK hooks | 22 nodes / 8 edges | rejected: monotonicity | claudeAgentSDKHooksGovernanceAdmissibilityRejectsMonotonicity |
| CrewAI hooks | 5 nodes / 1 edge | rejected: monotonicity | crewAIHooksGovernanceAdmissibilityRejectsMonotonicity |
| AutoGen approval gate | 1 node / 0 edges | legitimate | autoGenGovernanceAdmissibilityReviewRequiredLegitimate |
policy / source / fixture → bounded
extractor → governance graph →
runtime obligations + graph diagnostics + scaling witness →
semantic legitimacy kernel → declared
sacrifices + monitors
Artifact, data, and companion papers. This paper is one of the Legitimacy program’s manuscripts. The machine-checked artifact (Lean 4 theorem stack + Rust audit pipeline), the companion papers, and the claim ledger are in the project repository, github.com/abenenson/legitimacy; project page: adambenenson.com/projects/legitimacy. Verification code anchor:
v1.0.0. Dual license: MIT OR Apache-2.0.
Agentic AI systems need rule-layer checks in addition to behavior tests. This paper defines one such checkable object: the semantic legitimacy kernel.
The central question for many deployed AI systems is no longer only “did the model produce a good answer?” Many deployed systems now make decisions with lasting effects: they remember facts, call tools, route work, escalate to reviewers, refuse requests, and grant or withhold autonomy. Each of those is a governance decision. The system is deciding who gets a limited resource: tool access, memory, review time, priority, or authority.
This is the object paper, and the kernel is the spine of the framework. The kernel is the positive artifact: a typed bundle that an actual governance rule either inhabits or fails to inhabit. The companion results are organized around it. Paper 03 establishes the forcing impossibility (the argument that a kernel reaching a scarce peer-relative stage must declare a sacrifice), and Paper 04 studies the spectral scaling companion as a standalone capacity result. This paper defines the object that both of those target, and shows it is inhabited. The argument has four load-bearing pieces: the decomposition makes the bridge explicit, the inhabitant makes the class non-empty, the forcing theorem makes the sacrifice ledger mandatory, and the artifact makes the object checkable.
Throughout this paper, the running example is the Claude Agent SDK tool-use permission gate. The claimants are proposed tool invocations, users or developers requesting them, and governance layers that can approve, deny, or require review. The estate is the limited permission and review capacity available at that moment. A kernel asks whether the rule that grants, denies, or escalates those tool calls remains coherent when denied requests are removed, request-strength signals are uniformly rescaled by a positive factor, or one request receives stronger supporting evidence.
Once a system does that, ordinary behavioral alignment is necessary
but incomplete. A governance decision can fail in two ways. The first is
an output failure: it produces a bad outcome. The second is a legitimacy
failure: it produces an acceptable-looking outcome through a rule that
would not survive inspection, a rule whose verdict changes for one
claimant when an already denied claimant is removed (a consistency
failure), whose verdicts change when all claim strengths are scaled by
the same positive factor (a solidarity failure), whose reward for a
stronger claim is a Permit → Deny flip for some claimant (a
monotonicity failure), or whose individually permitted steps compose
into a forbidden global action (a composition-safety failure).
This paper defines a checkable object for that second failure mode: the semantic legitimacy kernel. Think of it as a compiler target for governance rules. We do not ask whether a program “seems memory safe” after running a few tests; we compile it against a type system and reject programs that violate the language’s safety discipline. A finite eval suite can show how a policy behaved on tested cases. It does not show whether the underlying rule behaves coherently across related cases. We should compile the governance rule itself against a typed legitimacy target and reject, monitor, or explicitly sacrifice obligations before the rule governs durable state.
The kernel starts after the system has fixed the governance vocabulary. A claimant is a party with standing in the rule. A valid claim is an admissible request or reason. A priority class says which claims are treated as peers. An estate is the scarce permission, memory, authority, or review capacity being allocated. Reduction operators remove irrelevant claims; shock models change shared capacity; claim orderings say when one claim has strengthened. In the Claude Agent SDK gate, those fields distinguish a shell command request, its policy basis, the review tier it belongs to, the available approval path, and the perturbations an audit may apply. The rule either behaves coherently across that declared family of related cases, or it does not.
| Claim | Evidence + Boundary | Formal anchor |
|---|---|---|
| Semantic kernel decomposes into runtime kernel + bridge | Lean theorem; decomposition, not derivation | isSemanticLegitimacyKernel_iff_runtime_and_bridge |
| Runtime kernel has five obligations | Lean object; does not solve value selection | IsLegitimacyKernel |
| The kernel class is inhabited | Lean instance; concrete bundle over a permit system; minimal non-emptiness witness | permitKernel |
| Bridge carries diagnostic and spectral layers | Unfolded Lean theorem; needs explicit bridge fields | semanticKernel_iff_runtime_diagnostic_spectral_layers_unfolded |
| Bounded extraction can target the kernel | Lean contract + Rust artifact; not arbitrary source semantics | BoundedExtractorContract |
| Source-derived case outputs are inspectable | Rust snapshots + parity tests; source-to-graph faithfulness is trusted base unless promoted | extractor reports |
Kernel decomposition, informal. A semantic legitimacy kernel is exactly a runtime kernel plus an explicit semantic bridge. The runtime kernel carries certifiability, observability, corrigibility, compositional safety, and non-vacuity. The bridge carries the graph-diagnostic and scaling obligations. In the Claude Agent SDK gate, this means a clean hook interface is only the runtime half; the bridge must also say how the permission graph behaves under denied-request removal, uniform positive strength scaling, claim strengthening, and capability scaling. Runtime checks alone do not imply the graph or scaling layers.
One umbrella, one footprint. The seven public spine statements — the spectral capacity threshold, the channel-capacity bound, the capability-scaling substrate, its shared cliff, the reachable peer-relative obstruction, the no-undeclared-sacrifice deployment gate, and the semantic-kernel decomposition — are tied together by a single umbrella theorem (
spineFootprint) so that an axiom-footprint check cannot quietly cover only a selected subset of the spine. The kernel decomposition and the forcing obstruction sit in the same footprint by design.
Scope and limitations. A semantic legitimacy kernel does not solve value specification, decide which claimants deserve standing, replace runtime safety, red-teaming, security review, interpretability, or behavioral evaluation, or prove that arbitrary source code compiles to a Lean-certified kernel. It defines the typed rule-layer artifact that such work should target: a checkable object for governance rules that allocate durable authority, memory, tool access, review capacity, or permission among competing claims.
Most alignment methods begin downstream of the governance question. RLHF, constitutional prompting, process supervision, red-teaming, and guardrail enforcement all shape or inspect behavior. These methods are valuable, but they do not by themselves answer whether the rule selecting, permitting, escalating, refusing, or preserving an action is entitled to govern.
That distinction matters because agentic AI systems now contain institutional machinery:
Each of these is a claims problem. There are claimants, scarce goods, admissible reasons, priority classes, and perturbations under which the rule’s reasons should remain stable. A memory consolidation policy should not make a hypothesis durable only because an irrelevant weaker hypothesis was present. When a valid action’s supporting evidence strengthens, a tool approval rule should not become less permissive toward it. An oversight allocator should not respond to a common capacity reduction by accidentally increasing one peer’s review budget while making others absorb the loss.
These are not unusual edge cases. They are the ordinary pathologies of allocation under composition. Social choice, apportionment theory, and mechanism design have long treated such pathologies as structural. AI governance should import that discipline at the rule layer, not only at the preference-aggregation layer.
For readers whose work is RLHF, Constitutional AI, debate, or AI Control: those methods shape and check the policy. This program audits the scaffolding around the policy — the rule layer that allocates authority, memory, tool access, and review among competing claims — a layer most safety cases currently assume rather than check. The two layers are complementary, and the boundary is deliberate: behavioral evidence cannot stand in for rule-layer coherence, and rule-layer coherence does not certify behavior.
The framing is conditional, not universal. If powerful agent systems are to govern without silent legitimacy degradation under composition, scaling, or self-modification pressure, they need some explicit layer that distinguishes merely executable control from legitimate authority. Compilation is the proposed name for that layer.
A semantic legitimacy kernel is a compiled artifact that packages
what the governance rule must carry in order to be auditable. In the
current formalization, the runtime layer has five obligations, and they
are not a wish-list: each is separately load-bearing, the bundle is
non-vacuous, and the whole bundle is inhabited by a concrete instance
(permitKernel) so that the object class is demonstrably
non-empty.
First, the rule must be certifiable: governed decisions need
checkable witnesses. Second, the rule must be observable: governance
state and decision-relevant structure must survive audit. The
strengthened observable-determinacy form is semantic rather than merely
operational: the formalization requires audit path-independence, so
legal audit traversals can be rearranged by independent local swaps
without changing the observable final-decision surface.1
Third, the rule must be corrigible: authorized supervision must preserve
the governance substrate while permitting intervention. Fourth, the rule
must be compositionally safe: local permissions should not compose
across the declared causal boundary into global violations. Fifth, the
rule must be non-vacuous: the governed system must actually govern
rather than collapse into empty graphs, permanent refusal, permanent
escalation, or deadlock. Each obligation is separately load-bearing: a
concrete witness shows that any one can fail while the other four hold,
so none is redundant scaffolding (witnesses
independent_certifiable,
independent_observable,
independent_corrigible,
independent_compositional_safety,
independent_nonvacuous).
Those five obligations are necessary but not sufficient. Runtime well-formedness alone does not imply legitimacy across denied-claimant removal, positive claim-strength scaling, or strengthened claims. The semantic target therefore strengthens the runtime kernel with graph diagnostics and a scaling witness. The graph-diagnostic layer tests whether the governance rule behaves coherently under changes that should not alter its justificatory structure. The spectral layer exposes how consistency vulnerability and capability pressure scale with the graph’s topology.
For the Claude Agent SDK gate, certifiability means the permission verdict carries an inspectable reason, observability means the relevant hook state survives audit, corrigibility means authorized review can intervene without corrupting the rule, compositional safety means individually permitted tool calls do not compose into a forbidden action, and non-vacuity means the gate governs a nonempty claim set with a genuine permit witness while avoiding permanent refusal, permanent escalation, and deadlock. Non-vacuity does not by itself require decision selectivity.
The kernel is not a scalar score but a product object:
semantic legitimacy kernel
= runtime obligations
+ graph-diagnostic obligations
+ spectral/scaling witness
+ explicit bridge contract
The bridge contract is load-bearing. It prevents a common overclaim: a clean runtime interface does not magically imply social-choice-style diagnostics or spectral robustness. Those layers must be carried explicitly.
Why should governance need a kernel at all? Because the kernel’s own diagnostic desiderata do not generally coexist, which is precisely what makes the kernel the right object. The impossibility forces the kernel rather than sitting beside it as a competing result. It tells a legitimate rule, on the surfaces where it actually allocates, that it cannot silently keep everything, and must instead declare what it gives up. The kernel records that declaration.
The formal obstruction applies when a real permission decision reaches a scarce peer-relative stage. In the Claude Agent SDK gate, this is the situation where a tool-use request is evaluated against other active requests or review demands, not only against its own local features. On that reachable-stage class, the bundled graph-level legitimacy properties cannot all hold.
The exact formal scope is stated in the companion theorem: the pipeline has a transparent prefix, a nontrivial symmetric scarce allocator that is actually reached, and a suffix that preserves the permits granted at that stage. Transparent pass-through stages include logging, observation, or normalization nodes that permit every claimant and therefore do not alter the decision surface. The complete first-effective peer-relative surface theorem is the special case where this reached stage is the first effective surface and the downstream tail is complete in the older sense.
The paper-facing diagnostic core has three graph-diagnostic
properties from the Arrow-Young-Thomson tradition named above.
Consistency says that removing a denied tool request should not change
any other request’s verdict. Solidarity says that scaling every claim
strength by the same positive factor should preserve every verdict.
Monotonicity says that strengthening one valid tool request should not
flip any claimant from Permit to Deny; the
obstruction witness is a peer-relative displacement case where another
request is denied. In the binary semantics formalized here, solidarity
plus monotonicity implies the relevant strategyproofness predicate, so
strategyproofness is a bridge-derived consequence rather than an
independent fourth diagnostic.
This theorem should be read neither too weakly nor too strongly. It
is stronger than a toy counterexample, because it is quantified over a
reachable behavioral class and machine-checked: the obstruction needs
only claimant symmetry, finite-estate coupling, and a scarce admissible
witness, and that class provably contains the canonical median-rule
gate, with each field necessary by countermodel. The sharper conclusion,
that consistency and monotonicity must each fail, holds on a narrower
rank-pinned structural subclass, and the two tiers are formally
separated by a max-rule witness that inhabits the broad class while
remaining consistent. It is also stronger than a syntactic-position-zero
result, because it covers peer-relative stages that occur after
transparent governance scaffolding. The older complete first-effective
result remains as a machine-checked special case. It has an explicit DAG
bridge: if a governed DAG system has a DAGToBinaryModelMap
to such a binary representative, the impossibility transfers back to the
governed system’s graph. It is weaker than the slogan “any governance
graph containing a peer-relative stage is impossible” — that slogan is
false, because an upstream deny-all gate can make a peer-relative stage
unreachable, satisfying the graph diagnostics without ever invoking it.
The theorem’s force lies in its named boundary.
The consequence is the compiler view, and it is what the kernel exists to carry. If a genuinely reached scarce peer-relative decisive stage, under the transparent-prefix and non-denying-suffix scope above, cannot keep the full diagnostic package, then the system must not pretend that an informal constitution, a reward score, or a finite eval suite has settled legitimacy. The rule must compile to the obligations it actually preserves and expose the obligations it sacrifices. The kernel is the object that records both. This forcing relation is one face of the kernel, not the headline: the kernel is the positive bundle; the impossibility is the reason the bundle must include an explicit sacrifice ledger rather than an implicit promise.
The full development of the forcing theorem — including the
typeclass-quantified pipeline form, the DAG-to-pipeline model-map
contract, the formal independence of the three diagnostics, and the
non-peer-relative escape collapse — lives in the companion paper A
Verified Impossibility Theorem for Peer-Relative Governance and in
lean/Legitimacy/Impossibility/.
Two machine-checked safety results turn the obstruction into an operational discipline, and they are what make the forcing relation actionable for the kernel. First, the deployment-honesty theorem says that a live obstructed artifact may run only if the forced sacrifices are declared.2 It goes past merely cataloguing paradoxes to define what honest deployment means for the obstructed class: a complete peer-relative surface cannot enter live status without its forced sacrifices declared.
Second, the trajectory-honesty theorem says that each governed trajectory either preserves the kernel invariant or exposes an indexed sacrifice certificate.3 The same invariant-or-certificate shape extends to covered stateful schedules, with intervention-aware, nondeterministic, and fair infinite-prefix variants.4 The result is deliberately scoped: it is a no-silent-degradation theorem for certified governance trajectories and schedules whose steps are explicitly governed or monitored, not a universal alignment theorem.
The two results are complementary, and they bracket the kernel’s life cycle. No-undeclared-sacrifice governs entry into live deployment: the compiled rule may sacrifice a diagnostic, but it must say so. Kernel reachability and stateful schedule safety govern motion after deployment: the execution may leave the invariant-preserving branch, but it must carry an indexed certificate rather than silently degrading. Together they define the operational meaning of running honestly: the kernel that the impossibility forces a rule to declare is the same kernel whose preservation the trajectory theorems then track.
A worked peer-relative fixture instantiates deployment honesty and trajectory honesty on the same concrete surface.5 The canonical singleton peer-relative graph has empty prefix and empty complete tail; a live compiled artifact over that graph is forced to declare consistency and monotonicity, while the emitted consistency certificate is replayed as an index-zero monitored sacrifice step whose reachability conclusion is supplied by the trajectory theorem. The paired runtime test rejects a peer-relative surface with an empty sacrifice ledger before activation.6
A legitimacy compiler should not produce a single moralized label. It should emit a structured governance artifact: which runtime obligations were discharged, which graph diagnostics passed or failed, which vulnerability quantities were measured, which evidence tier supports the result, and which future observations should trigger revision.
This broad output surface is the strongest reason to prefer the kernel framing over a sacrifice-forward framing. The kernel is the object; declared sacrifice is one field inside it. It contains the runtime witnesses, diagnostic verdicts, spectral/scaling quantities, protocol state, extraction provenance, and monitoring conditions that make a governance rule inspectable.
Declared sacrifice is one important output of this compiler, not the whole paradigm. Impossibility theorems are productive when they force design honesty. A governance rule may have good reasons to give up a property: monotonicity to maintain a scarce capacity constraint, solidarity because a priority class is intentionally lexicographic, or consistency because context coupling is part of a security boundary. But then the tradeoff should be declared, bounded, and monitored.
A tradeoff declaration should say:
The same compiler should also emit positive evidence: nondegenerate kernel witnesses, composition-safety proofs or counterexamples, protocol reachability facts, spectral vulnerability bounds, and extraction provenance. This matters because the goal is not to shame every system into declaring failure. The goal is to move governance from narrative compliance to typed evidence.
This changes the engineering culture around AI governance. Today, many systems use cohort-relative thresholds, approval chains, ranking rules, fallback policies, and override layers whose structural tradeoffs are not named. A legitimacy compiler makes those tradeoffs and invariants inspectable. It asks for the same discipline we expect from mature engineering: know which invariant you preserved, which invariant you gave up, why, and how you will detect drift beyond the declared envelope.
The object is not rhetorical and not merely defined. It is inhabited: the Lean development carries a concrete kernel instance, and the repository contains three kinds of evidence around it: Lean theorems, a bounded extraction contract, and a Rust audit pipeline.
First, the Lean development formalizes the kernel, its concrete
inhabitant, the diagnostic obstruction, the DAG-to-binary model-map
bridge, the semantic bridge, bounded extraction contracts, constructive
kernel examples, composition counterexamples, protocol state
transitions, spectral quantities, and selected adversarial stability
theorems. The kernel class is shown non-empty by exhibiting
permitKernel, a bundle that discharges all five axioms over
a concrete permit system, so the five obligations are jointly
satisfiable rather than merely jointly stated. The methodological point
is that the formalization separates runtime obligations, graph
diagnostics, spectral structure, protocol state, extraction contracts,
and empirical Rust behavior.7
Second, the Rust artifact implements an executable governance-audit
pipeline. It parses typed policy files and source-derived governance
surfaces into graphs, runs diagnostic checks, computes factor exposures
and spectral quantities, emits runtime outcome re-verification
certificates and audit reports, and tests byte-stable extraction
snapshots. The audit covers three surface types and treats each
separately. Typed TOML policy models constitute a modeled
governance surface. Open-source agent harnesses are walked end-to-end
against pinned upstream commits: the Codex Rust harness and the
MIT-licensed Claude Agent SDK. The proprietary Claude Code product
appears as metadata only, since its source is not redistributed. The
artifact boundary is explicit: Rust extraction over arbitrary source
code is heuristic and is not presently proved sound in Lean; Rust
protocol states store checked verdict data rather than Lean-equivalent
proof witnesses. The formal claim is a bounded extractor contract. The
implementation claim is deterministic, versioned, provenance-rich,
byte-stable evidence over committed fixture surfaces. Source-to-graph
faithfulness remains part of the unverified trusted base. The Lean
theorems govern the extracted GovernanceGraph model; the
extractor’s correspondence with raw syntax is supported empirically
rather than proved in Lean.
Third, current audits show why this object matters. Automatic
source-extraction rows over contemporary agent-governance surfaces find
monotonicity and non-vacuity failures in several synthetic structural
probes, with one observed-runtime lane showing a different profile. The
current extracted Codex, Claude Agent SDK, and CrewAI hook fixtures
include theorem-backed monotonicity rejections over the extracted graphs
(codexHooksGovernanceAdmissibilityRejectsMonotonicity;
claudeAgentSDKHooksGovernanceAdmissibilityRejectsMonotonicity;
crewAIHooksGovernanceAdmissibilityRejectsMonotonicity).8 Consistency and solidarity failures
appear only in specification-level examples, not in the automatically
extracted graphs; they are exploratory-tier evidence, not
theorem-backed. The AutoGen singleton fixture and the AI-Control
protocol fixtures pass with a legitimate verdict, so the
audit discriminates rather than rejecting every surface it touches. The
strongest reading is not “every system fails.” The stronger reading is
more useful: evidence tiers matter, extraction scope matters, and
governance artifacts need typed diagnostics precisely because informal
inspection misses structural failures and stale tooling can
overclaim.
That honesty is part of the contribution. A field that wants rigorous governance must be willing to say when a claim is theorem-backed, fixture-backed, observed-runtime-backed, specification-backed, or merely a hypothesis.
One alternative view is that alignment should remain behavior-first: if a system behaves well under sufficiently broad evaluations, the rule layer is secondary. The reply is that evals sample behavior, while legitimacy concerns the rule family. A governance rule can pass observed cases and still fail under denied-claimant removal, positive claim-strength scaling, strengthened claims, or composition. Those failures are invisible until the perturbation occurs, and by then the rule may already control durable state.
A second view is that natural-language constitutions are enough. They are legible to humans and flexible under context. The reply is that prose is valuable for deliberation but insufficient as a proof object. It does not define claimant types, reduction operators, priority classes, or admissible shock models with the precision needed for audit. Constitutional AI gets the instinct right by making principles explicit. A semantic legitimacy kernel pushes the same instinct to its engineering conclusion: the constitution should compile.
A third view is that formal legitimacy will be too brittle for real systems. The reply is that the compiler need not formalize all morality. It formalizes declared local justice properties of specific governance rules. When the formal target is too strict, the right output is not failure theatre but a typed account of what remains true, what fails, what is bounded, and what must be monitored.
A fourth view is that tradeoff declarations could normalize avoidable harms. The reply is that silent tradeoffs already exist wherever a system makes structural choices without naming them. A certificate is not permission to harm; it is an accountability object. It gives reviewers a concrete bound, monitor, and revision trigger to contest.
A fifth view treats the paper as only a theorem or systems artifact rather than as a conceptual contribution. The reply is that the paper’s primary contribution is a typed object: the semantic legitimacy kernel and its audit interface for rule-layer governance verification. The decomposition is definitional by design: its work is making the bridge fields explicit rather than implied; the inhabitant proves the class is non-empty; the forcing theorem proves why the object must carry an explicit sacrifice ledger; the artifact shows it is operationally checkable. Conceptual framing and theorem-backed object are not exclusive contributions. The formal object is the load-bearing claim.
The kernel definition suggests several concrete research tasks.
First, develop typed policy languages for agentic governance. These languages should express claimants, valid claims, estates, priority classes, reductions, shock models, claim-strength orderings, supervisory actions, and recompilation triggers.
Second, build verified kernel checkers. A checker should distinguish runtime well-formedness from graph-diagnostic legitimacy and from spectral scaling behavior. It should also produce machine-readable witnesses, vulnerability bounds, tradeoff declarations, monitoring plans, and recompilation triggers rather than a single pass/fail score.
Third, connect extraction to formal semantics. The near-term practical path is bounded extraction: parse a constrained source or policy surface, emit a canonical graph, and prove or test fidelity over named artifact classes. The longer-term path is a verified extractor or a restricted governance DSL whose operational semantics are formalized directly.
Fourth, standardize evidence tiers for governance audits. Synthetic structural probes, observed runtime corpora, reviewed reconstructions, specification-level models, formal parity fixtures, and full semantic proofs should not be collapsed into one credibility bucket.
Fifth, study adversarial governance. Agentic systems govern actors who adapt. A static kernel is the beginning, not the end. Mechanism design, strategic robustness, decomposition attacks, stateful adversaries, and recompilation protocols should become first-class parts of the legitimacy stack.
AI systems are becoming institutions in miniature. They allocate authority, memory, permission, risk, and oversight across time. When they do, alignment cannot be only a behavioral predicate. It must include legitimacy: whether the rule governing durable state is entitled to govern.
The practical proposal is simple. Make the constitution explicit. Give it a type system. Compile it to the kernel. The kernel is the positive object; if the rule cannot satisfy the full semantic legitimacy target, the forcing argument says so, and the kernel must declare the sacrifice and monitor the risk. This is not a retreat from alignment. It is a move to the layer where many alignment failures are born.
The constitution needs a compiler, and the kernel is what it compiles to.
[LegitimacyCompanions2026] Benenson, A. A Verified Impossibility
Theorem for Peer-Relative Governance; Which Governance Structures
Survive Unbounded Capability? Capacity and Stability Bounds for AI
Governance Graphs. Companion papers in the legitimacy repository,
verification code anchor v1.0.0, 2026.
[Arrow1951] Arrow, K. J. Social Choice and Individual Values. Yale University Press, 1951.
[Young1994] Young, H. P. Equity: In Theory and Practice. Princeton University Press, 1994.
[Thomson2019] Thomson, W. How to Divide When There Isn’t Enough: From Aristotle, the Talmud, and Maimonides to the Axiomatics of Resource Allocation. Cambridge University Press, 2019.
[Bai2022] Bai, Y., et al. Constitutional AI: Harmlessness from AI Feedback. arXiv:2212.08073, 2022.
[Burns2023] Burns, C., Izmailov, P., Kirchner, J. H., et al. Weak-to-Strong Generalization: Eliciting Strong Capabilities With Weak Supervision. arXiv:2312.09390, 2023.
Machine-checked artifact (Lean 4 + Rust): github.com/abenenson/legitimacy.