The Key to a Stable AI Governance Layer

10.2 Decision sovereignty

Decision sovereignty concerns who defines the problem, evidence, categories, metrics, thresholds, success, failure, deviation, and available permission states. A model may classify accurately relative to a task that should not have been defined in that way. Accuracy is internal to a defined task; decision sovereignty concerns who had authority to define it and under what justification.

10.3 Correction sovereignty

Correction sovereignty concerns who decides whether criticism, anomaly, harm, appeal, or feedback becomes a valid correction signal. A system may allow feedback while preserving a monopoly over what feedback counts. It is procedurally open where input is accepted and operatively open where valid input can change the regime.

10.4 Public-grammar sovereignty

Public-grammar sovereignty concerns the language and categories through which the decision becomes intelligible and legitimate. A risk score may become “risk,” a fit score “merit,” confidence “certainty,” compliance “safety,” or administrative priority “need.” Institutions cannot operate without abstraction. The problem arises when the model representation becomes institutional category and then public reality without preserving the epistemic boundary among them.

10.5 Civil corrective capacity

Civil corrective capacity is the ability of CIV to know that an AI-mediated process affected the decision, understand the relevant evidence and category, identify error or proxy substitution, present counterevidence, reach competent review, obtain a decision with reversal authority, trigger broader correction where patterns recur, and receive remedy where harm occurred.

It is not direct democratic control over every decision. It is preservation of a proportionate route from exposure to correction.

11. From Local Symptom to Failure Structure

AI governance often begins from a visible symptom: hallucination, bias, toxicity, over-refusal, under-refusal, prompt injection, drift, inconsistency, unauthorized tool use, unexplained ranking, repeated appeal, or weak explanation. These observations may be important. They do not by themselves identify the upstream failure structure.

PPDC distinguishes five levels:

Structured table:

Level: Observation

Meaning: A recorded event or condition

Level: Symptom

Meaning: A pattern suggesting that something may be wrong

Level: Failure event

Meaning: A bounded instance in which an intended condition was not met

Level: Failure mechanism

Meaning: The process producing or stabilizing the failure

Level: Structural condition

Meaning: A persistent configuration making the mechanism likely, invisible, or difficult to correct

An unsupported answer is an observation. Repeated unsupported answers under low-evidence conditions may be a symptom. A materially relied-upon false answer may be a failure event. Pressure to provide fluent completion despite evidence insufficiency may be a mechanism. A workflow that rewards answer production while no uncertainty signal can trigger HOLD may be a structural condition.

Symptom substitution occurs where a local observation is treated as the complete failure model. It may produce disclaimers, phrase bans, classifiers, additional reviewers, or policy language that reduce the symptom while preserving the mechanism.

For each governance-relevant symptom, the record should identify:

1. observed condition;

2. affected object;

3. relevant purpose;

4. interested parties;

5. candidate mechanism;

6. alternative explanations;

7. attribution evidence;

8. expected recurrence;

9. intervention point;

10. correction consequence.

11.1 Recursive evidence production

A particularly important structural mechanism is the ungoverned evaluation loop:

Recommendation → Ranking → Priority → Decision → Record → Future Evidence → Model Input

Prior predictions may shape enforcement data, prior hiring rankings may shape the profile of successful employees, and prior content recommendations may shape the engagement later used to validate the same recommendation system. Local bias or inconsistency may therefore be the visible symptom of recursive evidence production.

PPDC does not require one universal mechanism. The same observed failure may arise through technical design, data, incentive, authority fragmentation, cognitive shortcut, public grammar, burden transfer, or correction failure. It therefore distinguishes:

Constitutive Condition ≠ Causal Mechanism ≠ Observable Signal ≠ Outcome

Only after the upstream structure is explicit can observations be interpreted coherently as governance signals.

—

Part III — Evidence, Metrics, Thresholds, Authority, and Permission

12. Signals and Observability

A failure structure becomes governable only where relevant conditions can enter an evidence architecture. A real failure may be unobservable. Abundant data may fail to represent the relevant failure.

Observable Data ≠ Governance Signal

An observation is a recorded feature of an AI event, system state, workflow, institutional process, or external outcome. A governance signal is an observation, or structured set of observations, with a specified evidentiary relationship to a defined failure mechanism or permission-relevant condition.

Let:

s_j=(o_s,t_s,p_s,q_s,f_s,u_s)

where o_s is the observed object; t_s, time and period; p_s, provenance; q_s, evidence quality; f_s, linked failure hypothesis; and u_s, uncertainty and alternative interpretation.

A signal is governance-relevant only where the record identifies what was observed, how it was observed, what mechanism it may represent, which other explanations remain, which permission state it can affect, and what additional evidence is required.

12.1 Signal classes

Structured table:

Signal class: Direct event signal

Function: Records an output, action, release, permission change, or runtime condition

Signal class: Derived technical signal

Function: Results from a test, classifier, evaluator, or statistical process

Signal class: Institutional signal

Function: Records a policy conflict, authority failure, missed review, or implementation gap

Signal class: Affected-party signal

Function: Records complaint, appeal, counterevidence, or burden incidence

Signal class: Comparative signal

Function: Compares the configuration with a baseline, alternative, or prior version

Signal class: Persistence signal

Function: Indicates recurrence, drift, repeated failure, or correction latency

A mature architecture should preserve positive signals, negative signals, and conflict signals. Evaluator disagreement may indicate evidence insufficiency, divergent authority assumptions, inconsistent policy interpretation, different harm valuations, or unresolved tradeoffs. It should not always be erased through one synthetic score.

12.2 Absence, unobservability, and non-activation

Three states must remain distinct:

• Absent: evidence supports that the function or condition is not present.

• Unobservable: available evidence cannot establish presence or absence.

• Not activated: the relevant path existed but was not triggered during the period.

Public silence does not establish absence. A declaration that a process exists does not establish operation. Where evidence cannot establish or reject the condition, the correct result is Unobservable or Indeterminate.

12.3 Signal admissibility

Let Adm(s_j) denote admissibility. A minimum formulation is:

Adm(s_j) ⇔ O_j ∧ P_j ∧ F_j ∧ T_j ∧ Q_j

where O_j is object relevance; P_j, adequate provenance; F_j, failure-link specification; T_j, temporal relevance; and Q_j, minimum evidence quality.

Observability should be derived from the failure structure. For every mechanism, the analyst should identify where it leaves evidence, who can observe it, how quickly it becomes visible, what attribution limits remain, which decision it can influence, and what blind spots persist.

13. Metrics and Calibration

Signals do not interpret themselves. A metric is a structured rule converting one or more signals into a reproducible assessment relevant to governance.

m_k=φ_k(s_1,s_2,ldots,s_n| c,v)

where φ_k is the computation or interpretive rule; c, context; and v, metric version. Metrics may be scalar, categorical, ordinal, rule-based, conjunctive, human-coded, or mixed.

Every decision-bearing metric should specify identity, version, purpose, failure link, input signals, computation, scope, baseline, calibration, uncertainty, missing-data rule, failure behavior, threshold links, owner, and review date.

Metrics should be classified as:

1. External-outcome metrics, directly measuring the evaluative purpose;

2. Validated leading indicators, empirically linked to external outcomes;

3. Operational diagnostics, measuring system condition without proving purpose achievement;

4. Unvalidated proxies, convenient indicators whose relationship to the relevant outcome remains inadequately established.

The governing rule is:

Internal Indicator Alone ⇏ Continuation Authorization

13.1 Metric convenience drift

Metric convenience drift occurs when a metric is selected or preserved primarily because it is available, inexpensive, automatable, or institutionally familiar rather than because it represents the failure mechanism or purpose.

Available Signal → Convenient Metric → Institutional KPI → Decision Criterion → Public Reality

Simplicity is not itself a defect. The issue is whether convenience displaced validity.

13.2 Calibration, uncertainty, and missing data

Calibration asks whether metric values correspond adequately to the condition they represent. It should be specific to domain, population, system version, operating context, decision consequence, and time. A score calibrated for advisory use may be invalid for autonomous action.

Metrics should preserve measurement error, incomplete observability, label uncertainty, sampling error, population shift, evaluator disagreement, model instability, causal ambiguity, normative disagreement, and threshold uncertainty. States may include High Confidence, Moderate Confidence, Low Confidence, Contested, Incomplete, or Not Computable.

Missing-data behavior should be predeclared. Depending on risk and reversibility, missing information may be treated as uncertainty, require manual review, trigger RESTRICT or HOLD, or exclude the metric from the decision.

13.3 Metric minimality

Governance does not improve monotonically with metric count. Each metric creates collection cost, interpretation burden, maintenance, conflict, gaming opportunity, and configuration debt. A metric should remain only where it has identifiable decision value.

Metric Retention ⇒ Demonstrable Decision Relevance

14. Thresholds, Materiality, and Uncertainty

A metric becomes decision-bearing only where a rule determines when its value changes governance. A threshold connects a measured condition to a decision requirement:

Θ_k:m_k → (No Change,Review,RESTRICT,HOLD,ROLLBACK)

Thresholds may be hard, soft, conjunctive, disjunctive, comparative, temporal, authority-dependent, or reversibility-dependent. A soft threshold may create a presumption or mandatory review rather than automatic determination.

Materiality identifies when a condition is sufficiently consequential to justify governance change. It may consider severity, probability, irreversibility, scale, duration, rights impact, burden concentration, uncertainty, strategic dependence, correction cost, deadline, and affected-party vulnerability. Materiality is partly normative. PPDC does not eliminate value judgments; it requires them to be declared.

A justified threshold identifies the failure mechanism, consequence, evidence basis, uncertainty treatment, credible baseline, false-positive and false-negative costs, escalation path, review interval, and recalibration condition.

Threshold absence exists where a metric describes a condition but no rule determines what happens. A risk dashboard without escalation, a drift score without deployment response, or repeated appeal without a system-level trigger converts evaluation into observation.

Threshold gaming occurs where actors manipulate definitions, denominators, evidence windows, aggregation, exceptions, reporting timing, or object scale to avoid activation. Mitigation includes version history, independent review, alternative formulations, affected-party evidence, transparent exception records, and periodic recalibration.

14.1 Uncertainty-sensitive gates

Uncertainty does not always reduce governance pressure. A high-risk condition with weak evidence may justify HOLD because the system cannot establish safety adequately. Low-impact reversible uncertainty may permit SHIP with monitoring or RESTRICT. High-impact, partly irreversible uncertainty generally strengthens the case for HOLD.

Let t_L denote the latest point at which intervention can still alter the relevant consequence. A review completed after t_L may provide accountability, remedy, or learning without providing prospective correction.

15. Authority Architecture

Evidence and thresholds cannot change a system without an authorized decision locus. Authority should be decomposed into purpose authority, evidence authority, metric authority, threshold authority, review authority, gate authority, implementation authority, remedial authority, and reauthorization authority.

PPDC distinguishes:

• formal authority: recognized right to decide;

• real authority: effective control over the decision;

• implementation control: ability to alter the governed object;

• burden incidence: exposure to consequences.

Aghion and Tirole’s distinction between formal authority—the right to decide—and real authority—effective control over decisions—is directly relevant because information structures, overload, urgency, measurement systems, and organizational multiplicity may produce substantial divergence (Aghion and Tirole, 1997).

Authority adequacy also requires competence, evidence access, conflict-of-interest control, accountability, proportional representation of affected interests, and ability to implement. Technical competence does not create public sovereignty. Democratic authorization does not create technical knowledge. Affected status does not create complete expertise. Mature governance connects differentiated sources of authority rather than collapsing them.

Where functions are distributed, governance depends on handoffs. A handoff requires an authorized transfer rule or observed transmission, a defined object, recipient responsibility, timing, and escalation. The existence of a sender and receiver does not prove a functioning interface.

Authority ambiguity—where multiple actors assume another must decide, no actor possesses complete jurisdiction, or legal and technical authority conflict—should generally trigger escalation or HOLD in high-impact cases.

16. Evidence-to-Gate Decision Record

A gate should not be generated from one score. The minimum decision object is a structured record:

D_g=(o,Ω,E,M,Θ,U,A,B,Λ,Ξ,Π)

where o is the object; Ω, purpose; E, evidence package; M, metric profile; Θ, thresholds; U, uncertainty; A, authority map; B, baselines; Λ, distribution of benefit, burden, knowledge, and authority; Ξ, reversibility and exit; and Π, applicable policy and permission rules.

The record should preserve object and version, domain, deadline, evidence sources, signal states, metric values, thresholds, uncertainty, competing interpretations, evaluator disagreement, affected-party evidence, authority basis, gate, rationale, implementation owner, required state change, verification method, expiration, appeal, and reauthorization condition.

It should distinguish:

1. declared rule;

2. contractual or formal rule;

3. operational control;

4. monitoring;

5. breach detection;

6. enforcement;

7. remedy.

A public clarification may change the declared state without changing contractual or technical permission. A contract may establish a restriction without monitoring. A technical control may exist without legitimate authorization.

17. SHIP , RESTRICT , HOLD , and ROLLBACK

17.1 SHIP

SHIP authorizes the object to proceed under defined scope and conditions. It is justified where the purpose remains clear, the problem model is adequate, evidence is sufficient, thresholds are satisfied, material risk is acceptable, burden is visible and proportionate, authority is valid, uncertainty is bounded, correction remains operative, and restriction or rollback remains feasible.

SHIP does not mean risk-free or permanently approved. The record should specify scope, version, permissions, monitoring, expiration, reassessment, and rollback conditions.

17.2 RESTRICT

RESTRICT permits continuation under defined limitations such as reduced scope, reduced autonomy, read-only operation, disabled tool access, limited population, human confirmation, stronger disclosure, increased monitoring, shorter authorization, or prohibition on downstream reliance.

It is appropriate where useful external benefit remains but one component creates disproportionate risk or burden, uncertainty can be managed by narrowing, a simpler baseline performs nearly as well, or exit capacity must be restored gradually.

17.3 HOLD

HOLD suspends action pending evidence, review, authority clarification, correction, or reauthorization. It is appropriate where evidence is insufficient, disagreement is material, authority is unclear, the object is ambiguous, thresholds cannot be applied, risk is high, reversibility is limited, policy conflict is unresolved, implementation cannot be verified, or the correction path is absent in a high-impact domain.

HOLD is not rejection. It should state the reason, evidence required, responsible actor, review deadline, permitted interim activity, and transition criteria. A bounded experimental HOLD may permit research without granting ordinary deployment authorization.

17.4 ROLLBACK

ROLLBACK requires reversal, withdrawal, disabling, downgrade, termination, or restoration to a safer prior state. It is appropriate where a material boundary was crossed, serious harm occurred or is imminent, a release failed, persistent drift cannot be managed by restriction, authority was exceeded, implementation diverged from authorization, the problem model became invalid, or prior permission relied on materially false or incomplete evidence.

No Determination and Conflicting Determinations may be recorded without becoming fifth canonical gates. They should usually trigger escalation or HOLD until a valid authority rule resolves them.

18. From Gate to Implemented Permission

A gate is not operative until the governed object changes state.

Implementation may be technical, procedural, contractual, informational, or remedial. Every gate should identify implementation owner, required action, affected system, deadline, verification method, bypass risk, rollback target, and completion evidence.

Declared implementation is not completed implementation. Partial implementation may occur where one interface changes while another remains active, new users are restricted while existing users continue, or a contract changes while technical access persists.

Implementation failure occurs where the gate is not executed, execution is delayed beyond t_L, the action is ineffective, a bypass remains, the implementer lacks authority, the state cannot be verified, or the system reverts without reauthorization.

Define correction latency as:

L_c=t_I-t_R

where t_R is the time at which the material trigger became recognizable and t_I the time at which the permission state was implemented. Prospective correction requires:

t_I ≤ t_L

Where t_I>t_L, the process may still provide accountability, remedy, and learning but did not prevent the relevant consequence.

19. Evidence Boundaries and Indeterminate Results

A rigorous governance framework must permit non-classification. Each material claim may be coded Supported, Partially Supported, Contested, Unobservable, Unsupported, Not Applicable — Justified, or Applicability Indeterminate.

Indeterminate is appropriate where evidence cannot establish or reject a required condition. It is not a weak positive, presumption of safety, or finding of failure. Its gate consequence depends on risk and reversibility. A low-impact reversible event may SHIP or RESTRICT despite analytical indeterminacy; a high-impact irreversible event may require HOLD.

Formal equations and metrics can create false precision. Mitigation requires explicit uncertainty categories, competing interpretations, documented assumptions, non-scalar profiles, authority to reopen decisions, and publication of evidentiary limits.

Confidentiality does not make governance impossible. Cleared review, compartmented evidence access, protected audit, confidential appeal, aggregate reporting, and state-specific gates may preserve differentiated accountability. Universal disclosure is not required; unreviewable secrecy is insufficient.

The governing principle of Part III is:

Evaluation becomes governance only when admissible evidence crosses a justified threshold, reaches a competent authority, produces a proportionate gate, and changes the permission state of the governed object.

—

Part IV — Correction and Governance Reliability

20. Criticism, Feedback, Review, and Correction

AI governance systems frequently use the language of learning, responsiveness, oversight, and continuous improvement. They receive complaints, collect evaluator feedback, conduct audits, convene review boards, produce incident reports, revise documentation, add monitoring, and publish explanations. These activities may be important. They should not be classified automatically as correction.

The relevant sequence is:

Criticism → Feedback → Review → Judgment → Gate → Implemented Correction

Criticism is an objection, anomaly report, dissenting interpretation, failure finding, appeal, or claim that the existing decision or decision structure may be inadequate. Feedback is transmission of information about performance, effects, errors, burdens, or disagreement into a receiving process. Review is examination by a competent actor or forum. Judgment is a reasoned conclusion concerning the object. None is yet operative correction.

PPDC distinguishes:

• decision correction: the authorized gate or decision changes;

• operative correction: the changed decision produces a verifiable alteration in the governed regime.

Evaluation → Gate Change

constitutes decision correction, while:

Gate Change → Implemented State Change

constitutes operative correction.

Correction should identify its object: output, individual decision, record, workflow, metric, threshold, authority, policy, configuration, model, problem model, or institution. A local failure should not trigger unnecessary architectural redesign; a structural mechanism should not be treated as an isolated output error.

A candidate correction-depth scale is:

Structured table:

Level: C0 — Cosmetic

Correction depth: Wording or presentation changes

Level: C1 — Event

Correction depth: One output or action changes

Level: C2 — Decision

Correction depth: Classification or gate changes

Level: C3 — Procedure

Correction depth: Workflow, review, or evidence rule changes

Level: C4 — Architecture

Correction depth: Metric, threshold, authority, or technical design changes

Level: C5 — Problem Model

Correction depth: Purpose, need profile, object, or institutional structure changes

The criterion is mechanism–correction fit: correction should operate at the lowest level capable of interrupting the identified failure mechanism reliably.

21. Soft Closure and Symbolic Governance

Soft closure is the condition in which a governance regime permits criticism, feedback, appeal, audit, transparency, or review while preventing those mechanisms from changing the operative decision structure.

Criticism → Feedback → Review not → Operative Correction

The system may be communicative and procedurally sophisticated. Its closure lies at the point of consequence.

Symbolic governance consists of artifacts that express responsibility or control without a reliable connection to permission: a dashboard whose alerts cannot trigger a gate, an appeal whose reviewer lacks reversal authority, an audit that cannot alter policy or deployment, a safety board whose decisions are advisory, a HOLD decision without technical enforcement, or a human reviewer operating as a rubber stamp.

These artifacts may still create visibility, preserve evidence, support understanding, and improve communication. They become misleading where their presence is treated as proof that the regime can correct itself.

A genuinely corrective regime must be vulnerable in a controlled sense. It must permit valid evidence to change what counts as admissible, how the system is measured, which threshold applies, who possesses authority, what the system may do, whether it remains deployed, and whether prior consequences are remedied.

21.1 Correction absorption and Core/Shell instability

Correction absorption occurs where criticism is incorporated into language or documentation without altering the operative regime. A disclaimer may be added after a reasoning failure, an appeal form created without reversal authority, or a new KPI introduced to report the failure without influencing permission.

The Shell is the visible layer of policy, cautious language, explanations, model cards, audits, safety framing, and compliance documentation. The Core is the deeper structure of evidence handling, uncertainty preservation, problem definition, metric validity, authority, threshold discipline, gate consequence, and correction.

A Core/Shell diagnostic compares declared safeguards with behavior under pressure:

Structured table:

Shell claim: “Uncertainty is preserved”

Core test: Does uncertainty survive paraphrase and release pressure?

Shell claim: “Human oversight is present”

Core test: Can the reviewer stop or reverse the action?

Shell claim: “Appeal is available”

Core test: Can appeal alter classification, threshold, or policy?

Shell claim: “The system is monitored”

Core test: Does monitoring alter permission?

Shell claim: “The system learns”

Core test: Are repeated mechanisms interrupted?

The operational test of openness is:

Can a valid correction signal alter permission, decision, criterion, authority, implementation, or problem model before the relevant opportunity closes?

31. PPDC Codebook and Derivation-Break Taxonomy

The codebook converts each component into inclusion, exclusion, and uncertainty rules.

• P is Supported where materially affected parties, need profiles, purpose, decision problem, baseline, burden, and correction path are explicit.

• F is Supported where a mechanism explains how the purpose may be defeated and states disconfirming conditions.

• S is Supported where signals are provenance-preserved, object-linked, temporally relevant, mechanism-linked, and uncertainty-qualified.

• M is Supported where metrics are defined, versioned, reproducible, scoped, calibrated or explicitly unvalidated, signal-linked, and decision-relevant.

• Θ is Supported where material consequence, evidence basis, uncertainty treatment, activation rule, error costs, gate consequence, and review condition are explicit.

• A is Supported where formal right, real control, evidence access, competence, implementation control, accountability, and conflict procedure are identifiable.

• G is Supported where a bounded object receives a reasoned, state-specific SHIP, RESTRICT, HOLD, or ROLLBACK determination.

• I is Supported where evidence shows that the object changed state consistently with the gate.

• R is Supported where audit, replay, contestation, correction, remedy where relevant, learning, expiration, and reauthorization are operative.

The Derivation-Break taxonomy is:

Structured table:

Code: DB1

Derivation break: Interested-Party Opacity

Code: DB2

Derivation break: Need-Profile Substitution

Code: DB3

Derivation break: Problem-Object Ambiguity

Code: DB4

Derivation break: Failure-Mechanism Substitution

Code: DB5

Derivation break: Signal Orphaning

Code: DB6

Derivation break: Metric Convenience Drift

Code: DB7

Derivation break: Threshold Absence or Arbitrariness

Code: DB8

Derivation break: Decision-Sovereignty Disconnect

Code: DB9

Derivation break: Correction-Sovereignty Failure

Code: DB10

Derivation break: Symbolic Gate

Code: DB11

Derivation break: Implementation Failure

Code: DB12

Derivation break: Audit, Replay, or Reauthorization Closure

A case may contain several breaks. The record should distinguish primary break, upstream contributors, downstream consequences, and parallel breaks. Co-occurrence does not prove causal ordering.

One failed implementation should be coded as an Acute Corrective Execution Failure unless independent design or repeated-event evidence supports a structural DB11 finding. Indeterminate remains a valid output and must not be treated as pressure to complete the diagnosis.

32. Candidate Measurement Profile

PPDC should be measured through a multidimensional profile rather than one score.

32.1 Component Support Profile

CSP_g=(P,F,S,M,Θ,A,G,I,R)

with each component retaining its categorical evidence state.

32.2 Derivation Link Traceability

If L_g is the number of applicable adjacent derivation links and L_g^S the number supported:

DLT_g=(L_g^S) / (L_g)

The ratio is descriptive and does not establish correctness.

32.3 Bidirectional Traceability Rate

BTR_g= fraction (Applicable components)

32.4 Signal Admissibility Rate

SAR_g= fraction (Signals used in decision)

32.5 Decision-Bearing Metric Rate

DBMR_g= fraction (Metrics presented as governance metrics)

32.6 Threshold Justification Rate

TJR_g= fraction (Applicable thresholds)

32.7 Evaluation-to-Gate Conversion Rate

EGR= fraction (Decision-relevant evaluations)

32.8 Gate Implementation Rate

GIR= fraction (Gate determinations requiring state change)

32.9 Correction-Sovereignty Reach

CSR= fraction (Affected-party signals meeting evidence and standing rules)

32.10 Replayability and Reauthorization

Replayability completeness measures the proportion of required artifacts available with preserved integrity. Reauthorization completeness measures the proportion of material continuation decisions that reassess all relevant derivation fields.

32.11 Soft-closure profile

Soft closure should be represented through complaint volume, review activation, decision-change rate, threshold-change rate, policy-change rate, implementation rate, remedy rate, recurrence, and correction latency. The candidate pattern is high procedural activity combined with low operative change.

32.12 Governance burden

The governance mechanism itself creates evidence collection, annotation, review, delay, audit, appeal, threshold maintenance, implementation, remedy, and reauthorization work. A PPDC-complete regime may still be inferior if its complete governance burden materially displaces the purpose it protects. The hierarchy should remain:

Categorical Evidence States → Multidimensional Profiles → Domain-Specific Rules → Optional Scalarization

Scalarization should not occur until compensability, weights, sensitivity, and non-compensatory constraints are justified.

33. Reliability and Validation Design

A conceptual framework does not become validated through detailed vocabulary. Validation requires independent use.

The development set should include clear successful correction, clear derivation breaks, governance activity without implementation, one-time execution failure, proprietary non-observability, functioning governance with contested outcomes, and outside-scope near misses. Development cases cannot validate the framework because the constructs were shaped partly through them.

Independent coders should apply a draft codebook to a calibration set. Disagreement concerning object selection, interested-party materiality, failure mechanism, signal admissibility, relation validity, authority, implementation, and structural versus acute failure should produce codebook revision before routine adjudication.

A holdout set must contain cases not used in theory development. Where feasible, structural coding should occur before coders inspect episode outcomes, preventing a successful outcome from proving architecture or a failed outcome from proving structural absence.

Negative cases are essential: systems with extensive artifacts and real correction; systems with minimal formal structure but reliable correction; high-authority systems with legitimate and effective gates; high-impact systems where contestability is limited but proportionate; complex systems outperforming simpler baselines; and systems with repeated complaints but no material defect.

Reliability should be reported separately for object selection, component states, derivation relations, DB codes, authority mapping, gate classification, implementation status, and durability. Agreement on the final category alone is insufficient.

Validation should examine:

• content validity: whether fields cover the proposed construct;

• convergent validity: expected alignment with traceability, safety analysis, assurance, contestability, runtime assurance, and risk management;

• discriminant validity: separation from document volume, general accountability, observability, organizational capacity, human oversight, and outcome correctness;

• predictive validity: prediction of gate issuance, implementation, latency, recurrence, remedy, and drift;

• incremental validity: added value after adjacent frameworks are applied.

The research sequence should proceed through construct and codebook development, synthetic scenarios, retrospective process tracing, longitudinal field observation, prospective interventions, domain transfer, and independent replication. Preregistration should specify objects, hypotheses, codebook versions, thresholds, outcomes, rival explanations, and stopping rules where feasible.

34. Research Hypotheses

The following hypotheses are candidates rather than findings.

H1 — Component Presence: complete PPDC node structures predict implemented permission determinations better than artifacts without a complete chain.

H2 — Relation Integrity: supported derivation relations predict implementation and recurrence better than node presence alone.

H3 — Upstream Definition: explicit parties, needs, baselines, burdens, and correction paths reduce proxy substitution and object ambiguity.

H4 — Metric Validity: metrics linked to failure mechanisms and external outcomes outperform operational diagnostics and unvalidated proxies.

H5 — Threshold Explicitness: predeclared materiality and thresholds increase consistency and reduce retrospective gaming.

H6 — State-Specific Authority: a bounded gate authority, or binding referral to one, predicts implemented correction beyond advisory review.

H7 — Formal–Real Authority: unacknowledged divergence between formal and real authority increases symbolic gates, implementation failure, and override opacity.

H8 — Handoff Reliability: trigger-relevant handoff performance predicts correction better than formal function presence.

H9 — Implementation: verified gate implementation predicts reduced recurrence more strongly than gate issuance alone.

H10 — Correction Sovereignty: affected-party evidence reaching regime-changing authority improves detection and correction of need-profile substitution.

H11 — Replayability: replayable decisions support better causal diagnosis, remedy, threshold recalibration, and inter-rater agreement.

H12 — Reauthorization: substantive expiration and renewal reduce scope, authority, metric, and correction drift.

H13 — Prospective Boundaries: problem definitions, thresholds, correction paths, and rollback conditions established before dependency are more durable and less costly to enforce.

H14 — Soft Closure: high procedural openness combined with low gate-change and implementation rates predicts recurrence and longer correction latency.

H15 — Governance Reliability: Design State, Episode Performance, and Durability jointly predict future correction better than any one dimension.

H16 — Governance Burden: PPDC-guided governance improves correction only where its complete burden remains proportionate to the evaluative purpose and credible alternatives.

H17 — Incremental Value: PPDC’s object, relation, permission, implementation, and correction variables add classification, prediction, or intervention value after adjacent frameworks are controlled.

Each hypothesis should be paired with a rival explanation and explicit falsification test rather than treated as self-confirming.

35. Study Designs

Candidate study designs include:

• synthetic governance scenarios varying metric presence, threshold justification, advisory versus binding authority, implementation access, replayability, and correction sovereignty;

• historical process tracing reconstructing trigger, evidence, review, gate, implementation, substitutes, and deadlines;

• organizational audits of releases, agent deployments, serious incidents, appeals, red-team findings, rollback decisions, and failed reviews;

• prospective release studies comparing existing governance, PPDC-augmented governance, and adjacent assurance approaches;

• runtime intervention studies testing whether predeclared thresholds, implementation hooks, replay, and state-specific gates reduce harmful continuation without excessive false HOLD or ROLLBACK decisions;

• contestability studies comparing information-only explanation, procedural appeal, reversal authority, and system-level policy correction;

• reauthorization studies comparing permanent permission, automatic renewal, procedural renewal, and substantive renewal;

• domain-transfer studies across model release, agentic tool use, healthcare, recruitment, insurance, public administration, finance, infrastructure, and scientific workflows.

Domain transfer should not assume identical thresholds, authority, or correction requirements.

36. Reduction and Originality Test

The strongest threat to PPDC is explanatory redundancy. The framework should not be defended merely because its vocabulary is coherent.

PPDC should be decomposed against requirements traceability, STPA, assurance cases, runtime assurance, AI RMF, ISO management and risk standards, algorithmic contestability, accountability, organizational authority, change control, and incident response.

A component is not independently novel where an adjacent framework already supplies the same function adequately. The principal candidate contribution is relational rather than proprietary ownership of every node. The residual proposal consists of:

1. the Governance Derivation Instance;

2. the upstream Problem Model;

3. explicit derivation relations;

4. the implemented permission endpoint;

5. DB1–DB12;

6. sovereignty cross-tests;

7. separation of completeness, adequacy, operational completion, and reliability;

8. recursive self-application.

The framework should be tested for incremental classification, prediction, and intervention. Does it distinguish complete but substantively wrong cases, correct but derivationally incomplete cases, accountable but non-operative review, symbolic gates, one-time correction without durability, or implementation without justified derivation? Do its variables improve prediction of gates, implementation, latency, recurrence, remedy, drift, and reauthorization? Do PPDC-derived interventions outperform more monitoring, more documentation, more human review, one additional safety metric, or one centralized authority?

Evidence may lead to:

Structured table:

Outcome: CONFIRM

Meaning: Reliable, discriminant, predictive, and incrementally useful

Outcome: NARROW

Meaning: Applicable only to defined domains or object classes

Outcome: SIMPLIFY

Meaning: Some distinctions add no value

Outcome: RECLASSIFY

Meaning: Best treated as an integrative diagnostic synthesis

Outcome: REJECT

Meaning: Coding is unreliable and incremental validity is absent

If PPDC adds no measurable value beyond adjacent tools, the defensible result is reclassification as an integrative governance-diagnostic synthesis and implementation crosswalk.

37. Principal Objections

37.1 “The framework is too demanding”

Real organizations often lack complete problem definitions, baselines, calibrated metrics, burden data, authority maps, and replay records. The demanding conjunction is nevertheless what prevents every imperfect system from being labeled governance failure. Partial results and Indeterminate findings remain useful. The empirical test is whether the stricter framework improves reliability and reduces false positives enough to justify its evidentiary cost.

37.2 “The chain is unrealistically linear”

Real governance is iterative, parallel, recursive, and distributed. PPDC specifies a logical derivation order, not a required temporal bureaucracy. Functions may be compressed or parallel if their relations remain reconstructable.

37.3 “PPDC confuses governance with engineering”

Political legitimacy, rights, judgment, and authority cannot be reduced to technical traceability. PPDC explicitly separates substantive adequacy, legitimacy, authority, accountability, and derivational completeness. Engineering traceability is an antecedent, not the full model.

37.4 “The framework is normative”

Purpose, materiality, burden, correction strength, and authority allocation involve values. PPDC distinguishes observable facts from evaluative rules and records who selected those rules and whose interests they represent. It provides analytical visibility rather than value-free resolution.

37.5 “Traceability does not establish truth”

Correct. A fully documented derivation may begin from false premises or unjust thresholds. PPDC is a necessary architecture for review, not a truth guarantee. Its value depends partly on whether complete records make substantive error easier to identify and correct.

37.6 “Judgment cannot be reduced to thresholds”

Thresholds may trigger review rather than dictate the final decision. They may be qualitative, procedural, context-dependent, or authority-sensitive. Expert discretion remains compatible with PPDC where it is explainable, bounded, reviewable, and connected to permission.

37.7 “Stopping authority can become domination”

A gate authority may suppress experimentation, centralize power, exploit uncertainty, or create veto paralysis. It must therefore be state-specific, evidence-bound, proportionate, reason-giving, appealable, time-limited, and reauthorized. Authority without constraints is arbitrary; review without authority is symbolic.

37.8 “Contestability will paralyze institutions”

Unbounded appeals can create delay, manipulation, and overload. PPDC requires burden-sensitive correction rather than unlimited veto. Standing, evidence, review, and remedy may be scoped, time-limited, risk-proportionate, and abuse-resistant. Empirical comparison must examine correction gains against delay and strategic use.

37.9 “Secrecy makes the framework impractical”

PPDC does not require universal disclosure. Cleared access, compartmented evidence, protected audit, confidential contestation, and bounded reporting may preserve review. Where evidence remains unavailable externally, the external result should be Indeterminate.

37.10 “A better baseline can always be imagined”

PPDC requires a credible, feasible, decision-relevant alternative rather than global optimization. Once adequacy is achieved and no material failure is established, SHIP may remain valid until material conditions change.

37.11 “The framework is anti-complexity”

Complexity may provide safety, robustness, specialization, and capability. PPDC asks whether complexity remains connected to the problem and whether each component adds decision-relevant value against a credible baseline.

37.12 “High governance burden is the price of safety”

Safety and rights protection belong in the benefit profile. Governance work is counted because it is part of the system, not because it is presumptively excessive. The relevant comparison applies equivalent safety and rights floors to alternatives.

37.13 “The governance layer can become the new failure”

This is a core design risk. PPDC must apply to itself through metric minimality, governance budgets, expiration, simplification authority, marginal-component testing, and reauthorization.

37.14 “The framework merely collects existing ideas”

Every major component has antecedents. Independent status depends on whether the integrated derivation, permission endpoint, break taxonomy, and reliability distinctions add measurable value. If they do not, the framework should be reclassified rather than defended rhetorically.

37.15 “Software cannot govern institutions”

Software cannot manufacture legitimacy, jurisdiction, public purpose, professional competence, or moral judgment. PPDC is not a software specification. LoopGuard-AI is one candidate implementation of part of the structure. The complete regime remains socio-technical and institutional.

38. Falsification and Rejection Conditions

The framework should be narrowed, reclassified, or rejected where one or more of the following persist after reasonable development:

• analysts cannot identify governance objects reliably;

• component states or derivation relations cannot be coded consistently;

• DB categories overlap without discriminant value;

• PPDC cannot be distinguished from general governance maturity;

• the permission endpoint adds no analytical value;

• formal and real authority cannot be measured meaningfully;

• correction sovereignty cannot be operationalized;

• completeness does not predict implementation;

• derivation breaks do not predict recurrence or latency;

• PPDC-derived interventions do not outperform simpler controls;

• the framework adds burden without correction improvement;

• adjacent frameworks explain the same cases without loss;

• the construct works only in development cases or cannot transfer across domains.

PPDC should not be protected by adding concepts indefinitely. Its own correction requirement applies to its theoretical status.

39. Scope and Maturity

PPDC is designed primarily for socio-technical AI regimes in which evidence is interpreted, permission is allocated, authority is distributed, system states can change, and consequences can be reviewed. It is especially relevant to model release, agent action, tool use, workflow transition, high-impact classification, institutional deployment, runtime restriction, rollback, and reauthorization.

It is not a complete theory of justice, morality, democratic legitimacy, intelligence, consciousness, model alignment, cybersecurity, safety engineering, or institutional effectiveness.

The strongest permissible claim is:

Problem-to-Permission Derivation Completeness is a candidate necessary condition for stable, reviewable AI governance.

It is not sufficient.

Current maturity is:

• Conceptual maturity: advanced candidate framework;

• Measurement maturity: pre-validation;

• Empirical maturity: unvalidated;

• Formal maturity: conceptual formalization;

• Governance maturity: candidate design and audit framework;

• CEP maturity: optional candidate explanation of equilibrium-like persistence;

• LoopGuard-AI maturity: concept-stage to architecture-stage unless stronger evidence is attached.

The article may claim that it defines PPDC and the Governance Derivation Instance, distinguishes nodes from derivation relations, introduces the implemented permission endpoint and DB1–DB12, separates completeness, adequacy, operational completion, and reliability, and proposes measurements, hypotheses, and rejection conditions. It should not claim prevalence, validated constructs, established causality, universal thresholds, empirically validated CEP, production-validated LoopGuard-AI, guaranteed stable governance, or first discovery of every component.

The defensible status is:

PPDC is an advanced candidate integrative governance-design theory and measurement framework with substantial conceptual development, explicit reduction and falsification conditions, preliminary measurement architecture, and no completed empirical validation.

40. Conclusion — The Key to a Stable Governance Layer

AI governance is often identified through what can be seen: policies, evaluations, metrics, dashboards, review boards, audits, explanations, human oversight, and release gates. These structures may be necessary. They do not answer the central question:

How did the governance regime move from a defined human or institutional problem to what the AI system is now permitted to do?

The answer requires more than a control. It requires a derivation.

Interested Parties → Need Profiles → Decision Problem → Failure Structure → Signals → Metrics → Thresholds → Authority → Gate → Implemented Permission State → Correction and Reauthorization

Without a problem model, the system may optimize an inherited or concealed objective. Without a failure structure, monitoring tracks symptoms. Without admissible signals, the mechanism remains invisible. Without interpretable metrics, evidence remains unstructured. Without justified thresholds, measurement remains descriptive. Without authority, review remains advisory. Without a gate, judgment remains indeterminate. Without implementation, the gate remains symbolic. Without correction and reauthorization, the permission state becomes closure.

For bounded governance instance g:

PPDC_g ⇔ P_g ∧ F_g ∧ S_g ∧ M_g ∧ Θ_g ∧ A_g ∧ G_g ∧ I_g ∧ R_g

and:

∧ _(i=1)^(|N_g|-1)τ(x_i,x_(i+1))

The requirement is conjunctive because the missing link matters. A sophisticated metric cannot replace authority. Authority cannot replace evidence. Implementation cannot replace justification. Accountability cannot replace correction.

The framework preserves four non-equivalent questions:

• Can the derivation be reconstructed and defended?

• Are its premises and decisions substantively adequate?

• Did the permission state change?

• Does correction remain functional under repetition and pressure?

The key to a stable governance layer is not maximal control, maximal monitoring, maximal human involvement, or one universal authority. It is preservation of a reviewable relation among the problem being governed, the evidence used, the actors authorized to decide, the state the system is permitted to occupy, and the means by which that state can be corrected.

A stable AI governance layer becomes possible only where every material permission can be traced backward to a defined problem and forward to an implemented, reviewable, and correctable system state.

Even this does not guarantee wisdom, justice, safety, or truth. It establishes something operationally prior: the regime can explain why it acts, show who may change its action, prove whether the change occurred, and remain vulnerable to valid correction.

That is not stable governance completed.

It is the architecture that makes stable governance testable, correctable, and institutionally accountable to its own derivation.

—

Glossary

ADM — The administrative, managerial, institutional, organizational, regulatory, or governing side of a decision regime.

CIV — The civil, exposed, dependent, human-facing, or cost-bearing side of a decision regime.

Civil Corrective Capacity — The capacity of the exposed side to understand, contest, correct, and reorient an AI-mediated decision regime.

Correction Sovereignty — Control over whether criticism, anomaly, harm, appeal, or feedback becomes a valid regime-changing correction signal.

Corrective Intelligence — Capacity to convert evaluation or failure evidence into changed permission, authority, restriction, escalation, redesign, or rollback.

Derivation Break — A specified failure in the path from problem model to permission, coded DB1–DB12.

Derivation Relation — A documented, reviewable, and defeasible relation connecting adjacent PPDC components.

Governance Derivation Instance — A bounded unit g=(o,d,a,b,T) containing a governance object, domain and purpose, AI or workflow configuration, baseline, and period.

Governance Derivation Record — The structured empirical record used to reconstruct and code one Governance Derivation Instance.

Governance Reliability — Stable corrective capacity under repeated pressure, uncertainty, authority conflict, incentive conflict, reversibility limits, and change.

HOLD — A permission state suspending ordinary action until specified evidence, authority, risk, or correction conditions are resolved.

Implemented Permission State — The verifiable operational state resulting from a gate determination.

Need-Profile Substitution — Replacement of one interested party’s need by another party’s metric, proxy, or operational objective.

Operational Completion — Completion of the authorized transition from gate determination to implemented state.

PPDC — Problem-to-Permission Derivation Completeness: the condition in which all required nodes and derivation relations from problem model to implemented and reviewable permission are present.

Problem-to-Permission Derivation Requirement — The requirement that a governance regime demonstrate PPDC for a bounded governance instance.

Public-Grammar Sovereignty — Control over the categories and language through which a decision regime appears neutral, objective, safe, efficient, or legitimate.

RESTRICT — A permission state allowing continuation only under defined limitations.

ROLLBACK — A permission state requiring reversal, withdrawal, disabling, downgrade, termination, or restoration to a safer prior state.

SHIP — A permission state authorizing continuation under defined scope and conditions.

Soft Closure — Procedural openness without operative vulnerability to valid correction.

Substantive Adequacy — Defensibility of the problem model, evidence, metrics, thresholds, authority, and permission decision.

—

References

Aghion, P., and Tirole, J. (1997). “Formal and Real Authority in Organizations.” Journal of Political Economy, 105(1), 1–29. https://doi.org/10.1086/262063Denney, E., Menzies, J., and Pai, G. (2023). Dynamic Assurance Cases: Closing the Loop Between Design and Operational Assurance. NASA Technical Reports Server, Document 20230007853.Dunavich, B. (2026a). “Before the Agent: Agentic AI Decision-Problem Design.” RATIUM.AI. https://www.ratium.ai/articles/before-the-agent-agentic-ai-decision-problemDunavich, B. (2026b). “ADM/CIV and the Epistemic Problem of AI Governance: Decision Sovereignty, Correction Sovereignty, and Public-Grammar Sovereignty.” RATIUM.AI. https://www.ratium.ai/articles/adm-civ-ai-governance-civil-corrective-capacityDunavich, B. (2026c). “A Hidden Split in Formal Reason: Cognitive Duality, Corrective Intelligence, and AI Governance Reliability.” RATIUM.AI. https://www.ratium.ai/articles/hidden-split-in-formal-reasonDunavich, B. (2026d). “Robert J. Aumann, CEP, and LoopGuard-AI: A Personal and Game-Theoretic Account.” RATIUM.AI. https://www.ratium.ai/technical-reference-dossiers/aumann-cep-loopguard-aiDunavich, B. (2026e). “The Foundational Problem of Low Consistency in Language Models under S4 Conditions.” RATIUM.AI. https://www.ratium.ai/foundational-source-dossier/language-model-consistency-s4-loopguardDunavich, B. (2026f). “LoopGuard-AI Technical Source Dossier: AI Governance Architecture, Runtime Control, and Engineering Reference.” RATIUM.AI. https://www.ratium.ai/technical-reference-dossiers/loopguard-ai-technical-source-dossierDunavich, B. (2026g). “The AI Configuration Paradox.” RATIUM.AI. https://www.ratium.ai/articles/ai-configuration-paradoxInternational Organization for Standardization and International Electrotechnical Commission. (2023a). ISO/IEC 42001:2023 — Information Technology — Artificial Intelligence — Management System.International Organization for Standardization and International Electrotechnical Commission. (2023b). ISO/IEC 23894:2023 — Information Technology — Artificial Intelligence — Guidance on Risk Management.Leveson, N. G., and Thomas, J. P. (2018). STPA Handbook. Massachusetts Institute of Technology.NASA. (2023). “Requirements Management.” NASA Systems Engineering Handbook Online Reference, Section 6.2.Rushby, J., Xu, X., Rangarajan, M., and Weaver, T. L. (2015). Understanding and Evaluating Assurance Cases. NASA/CR-2015-218802.SCSC Assurance Case Working Group. (2021). Goal Structuring Notation Community Standard Version 3. Technical Report SCSC-141C, Safety-Critical Systems Club.Slagel, J. T., White, L. M., Dutle, A., Munoz, C. A., and Crespo, N. (2024). “A Verification Framework for Runtime Assurance of Autonomous UAS.” 43rd Digital Avionics Systems Conference. NASA Technical Reports Server, Document 20240007986.Tabassi, E. (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1. National Institute of Standards and Technology. https://doi.org/10.6028/NIST.AI.100-1Yurrita, M., Verma, H., Balayn, A., Alfrink, K., Gadiraju, U., and Bozzon, A. (2025). “Identifying Algorithmic Decision Subjects’ Needs for Meaningful Contestability.” Proceedings of the ACM on Human-Computer Interaction, 9(7), Article CSCW234. https://doi.org/10.1145/3757415

Author’s Evidence and Claim-Control Note

The article distinguishes definitions, conceptual formalizations, candidate mechanisms, architecture proposals, empirical hypotheses, and validation targets. Equations are used to preserve distinctions and specify research objects; they are not estimated models or proofs of empirical prevalence. CEP is optional to PPDC, S4 is a bounded diagnostic hypothesis, and LoopGuard-AI is a candidate reference architecture rather than a validated product. Publication of this manuscript does not alter those evidence boundaries.