DRAFT Date: 2026-10-10 Author: Reuben Bowlby •

A Typed Delegation-Governance Tuple Profile for Multi-Agent Runtime Control

This is an unreleased working revision. Any DOI and earlier PDF shown here identify a previous snapshot and do not certify this revision or imply peer review.

Download working source

The working manuscript is available as LaTeX source below.

\documentclass[conference]{IEEEtran}

\usepackage{cite}
\usepackage{amsmath,amssymb,amsfonts}
\usepackage{graphicx}
\usepackage{textcomp}
\usepackage{xcolor}
\usepackage{booktabs}
\usepackage{url}
\usepackage{xurl}
\usepackage{listings}
\usepackage{multirow}
\usepackage{tikz}
\usetikzlibrary{automata,positioning,arrows.meta}

\lstset{
  basicstyle=\ttfamily\small,
  columns=fullflexible,
  frame=none,
  xleftmargin=1em,
  breaklines=true,
  breakatwhitespace=false,
}

\begin{document}

\title{A Typed Delegation-Governance Tuple Profile\\for Multi-Agent Runtime Control}

\author{\IEEEauthorblockN{Reuben Bowlby}
\IEEEauthorblockA{\textit{HUMMBL, LLC} \\
reuben@hummbl.io \\
ORCID: 0009-0002-5620-1103}}

\maketitle

\begin{abstract}
Multi-agent delegation requires connecting task scope, authority, execution evidence, and verification across multiple records. We present the Intelligent Delegation Profile (IDP), a six-type governance representation comprising delegation context, contract, capability token, evidence, attestation, and system event records. Cross-links support reconstruction, while evidence-before-verify, capability attenuation, and bounded delegation depth define validation obligations. We describe a briefing workflow and a peer-review mapping as design case studies. Historical operational summaries are retained as author-reported observations whose raw traces and benchmark protocol are not available in this artifact. A new exact-arithmetic companion reconstructs the stated no-decay trust-update model: recovery after one failure grows linearly with prior successful rounds, and does not establish economic resistance to attack. The profile contributes a composition and audit vocabulary; complete mediation, authentic evidence, and implementation conformance require separate assurance.
\end{abstract}

\begin{IEEEkeywords}
multi-agent systems, delegation governance, capability tokens, runtime assurance, composable trust
\end{IEEEkeywords}

%% ============================================================
\section{Introduction}

An audit of delegated work must connect what was authorized, who exercised that authority, what was observed, and who accepted the result. These questions concern different layers: an authorization token does not itself record task completion, and a provenance record does not itself prevent an unauthorized call. The IDP proposes explicit bindings among these layers.

Our contribution is a six-type profile with cross-linked identifiers and three validation obligations, together with two application mappings. It is not a new cryptographic primitive or a claim that no prior system combines governance mechanisms. The profile is useful only when its links and predicates are enforced by a defined implementation.

\textbf{Revision and evidence status.} This living-source revision is dated 2026-10-10. The archived PDF and arXiv bundle remain prior snapshots. The distributed bundle contains the manuscript, class file, and bibliography; it does not contain the historical raw logs, latency samples, claimed JSON Schema, TLA+ model, or trust simulation. Section~\ref{sec:eval} separates author-reported observations from the new reproducible arithmetic. Public reference code is inspected at the pinned revision cited in~\cite{reference-impl}; it is not a substitute for a deployment trace or a complete IDP conformance suite.

\section{Background and Related Work}

\textbf{Provenance and attestation.} W3C PROV represents entities, activities, agents, and their relationships, with associated constraints and interchange formats~\cite{w3c-prov}. IDP records could be projected into that vocabulary through an explicit mapping; runtime permission enforcement is a separate concern. IETF RATS distinguishes evidence, appraisal, attestation results, and relying-party decisions~\cite{ietf-rats}. This motivates separating EVIDENCE from ATTEST, but an application execution receipt is not automatically a hardware or software remote-attestation claim.

\textbf{Delegated authorization.} Macaroons support caveat-based attenuation~\cite{macaroons}; Biscuit adds a logic-based authorization language and public-key verification~\cite{biscuit}. UCAN specifies delegated capabilities and execution-time validation~\cite{ucan}. The earlier manuscript incorrectly claimed that UCAN lacks semantic attenuation: signature validity alone is insufficient, and UCAN validators must establish whether the requested authority follows from its proofs. The IDP's distinct design question is how to bind authorization to task contracts and evidence, not how to replace these token systems.

\textbf{Identity and integrity.} SPIFFE provides workload identity~\cite{spiffe}; task-specific authorization still requires policy. The historical IDP uses HMAC-SHA256, a shared-key message authentication construction~\cite{hmac}. Calling HMAC tags ``signatures'' does not give independently verifiable signer attribution: a party holding the shared verification secret can also generate tags. We use ``authenticated'' for those records below.

\textbf{Model-based review.} Research on LLM evaluators demonstrates self-recognition and preference effects in the studied settings~\cite{arize-bias}. Heterogeneous reviewers may reduce one shared source of bias but do not structurally eliminate correlated errors, collusion, or preference effects. Diversity is a design variable requiring evaluation, not an assurance result.

\section{The IDP Tuple Profile}

\subsection{Tuple Types}

The IDP defines six typed tuple classes, each with specific governance semantics:

\begin{table}[htbp]
\caption{IDP Tuple Types}
\label{tab:tuple-types}
\centering
\small
\begin{tabular}{@{}lp{2.0cm}p{3.2cm}@{}}
\toprule
\textbf{Type} & \textbf{Semantics} & \textbf{Key Fields} \\
\midrule
DCTX & Delegation lifecycle state & \texttt{parent\_\allowbreak{}dctx\_\allowbreak{}id}, \texttt{chain\_\allowbreak{}depth}, \texttt{status}, \texttt{timeout} \\
CONTRACT & Task scope and constraints & \texttt{objective}, \texttt{allowed\_\allowbreak{}tools}, \texttt{acceptance\_\allowbreak{}criteria} \\
DCT & Capability-bounded authorization & \texttt{allowed\_\allowbreak{}adapters}, \texttt{invocation\_\allowbreak{}budget}, \texttt{cost\_\allowbreak{}ceiling}, \texttt{ttl}, \texttt{signature} \\
EVIDENCE & Execution receipt & \texttt{tool\_\allowbreak{}outputs}, \texttt{adapter\_\allowbreak{}results}, \texttt{timing\_\allowbreak{}data}, \texttt{content\_\allowbreak{}hash} \\
ATTEST & Verification result & \texttt{verdict}, \texttt{linked\_\allowbreak{}evidence\_\allowbreak{}id}, \texttt{reviewer\_\allowbreak{}identity}, \texttt{confidence} \\
SYSTEM & Runtime event & \texttt{circuit\_\allowbreak{}breaker\_\allowbreak{}state}, \texttt{kill\_\allowbreak{}switch\_\allowbreak{}mode}, \texttt{health\_\allowbreak{}probe\_\allowbreak{}results} \\
\bottomrule
\end{tabular}
\end{table}

\subsection{Proposed Tuple Schema}
\label{sec:tuple-schema}

Table~\ref{tab:tuple-types} illustrates the six tuple types at a conceptual level. Table~\ref{tab:schema-summary} records the proposed mandatory and optional fields. The machine-readable schema claimed by the earlier manuscript is not in the distributed artifact, so the table is a design specification rather than a reproduced JSON Schema conformance result. Exact names, canonical serialization, envelope fields, and validation error behavior require a versioned implementation profile.

\begin{table*}[htbp]
\caption{Proposed IDP Tuple Schema Summary (mandatory \textsuperscript{M}, optional \textsuperscript{O})}
\label{tab:schema-summary}
\centering
\footnotesize
\begin{tabular}{@{}llllp{4.5cm}@{}}
\toprule
\textbf{Tuple} & \textbf{Field} & \textbf{Type} & \textbf{Card.} & \textbf{Constraint} \\
\midrule
\multirow{6}{*}{DCTX}
& \texttt{intent\_\allowbreak{}id} & UUIDv4 string & M & Matches root intent \\
& \texttt{task\_\allowbreak{}id} & UUIDv4 string & M & Unique per delegation event \\
& \texttt{parent\_\allowbreak{}task\_\allowbreak{}id} & UUIDv4|null & O & Null for root; non-null for child \\
& \texttt{chain\_\allowbreak{}depth} & integer $\geq$ 0 & M & $\leq$ \texttt{MAX\_\allowbreak{}DEPTH} (default 3) \\
& \texttt{status} & enum & M & One of: PROPOSED, ISSUED, RUNNING, EVIDENCE\_READY, VERIFIED, REPLANNED, FAILED \\
& \texttt{budget} & object & O & \texttt{max\_\allowbreak{}tokens}, \texttt{max\_\allowbreak{}cost\_\allowbreak{}usd}, \texttt{max\_\allowbreak{}wall\_\allowbreak{}time} \\
\midrule
\multirow{5}{*}{CONTRACT}
& \texttt{contract\_\allowbreak{}id} & UUIDv4 string & M & Links to governing contract \\
& \texttt{objective} & string & M & Non-empty, $\leq$ 4096 chars \\
& \texttt{allowed\_\allowbreak{}tools} & string[] & M & Non-empty list of tool identifiers \\
& \texttt{acceptance\_\allowbreak{}criteria} & string[] & O & Checklist for verification \\
& \texttt{expiry} & ISO8601|null & O & Null = no expiry \\
\midrule
\multirow{7}{*}{DCT}
& \texttt{token\_\allowbreak{}id} & UUIDv4 string & M & Unique per token \\
& \texttt{issuer} & agent-id string & M & Registered agent identity \\
& \texttt{subject} & agent-id string & M & Must differ from issuer \\
& \texttt{ops\_\allowbreak{}allowed} & string[] & M & Subset of parent DCT's \texttt{ops\_\allowbreak{}allowed} (I2) \\
& \texttt{resource\_\allowbreak{}selectors} & object[] & O & \texttt{resource\_\allowbreak{}type}, \texttt{resource\_\allowbreak{}id}, \texttt{constraints} \\
& \texttt{caveats} & object[] & O & \texttt{TIME\_\allowbreak{}BOUND}, \texttt{RATE\_\allowbreak{}LIMIT}, \texttt{APPROVAL\_\allowbreak{}REQUIRED}, \texttt{AUDIT\_\allowbreak{}REQUIRED} \\
& \texttt{signature} & HMAC-SHA256 hex & M & Message authentication tag over an explicitly defined serialization \\
\midrule
\multirow{5}{*}{EVIDENCE}
& \texttt{evidence\_\allowbreak{}id} & UUIDv4 string & M & Unique per evidence tuple \\
& \texttt{ops\_\allowbreak{}executed} & string[] & M & Subset of DCT's \texttt{ops\_\allowbreak{}allowed} \\
& \texttt{resources\_\allowbreak{}accessed} & object[] & O & Within DCT selectors and contract restrictions \\
& \texttt{cost} & object & O & \texttt{tokens}, \texttt{usd}, \texttt{wall\_\allowbreak{}time\_\allowbreak{}ms} \\
& \texttt{output\_\allowbreak{}hash} & SHA-256 hex & O & Content-addressed output \\
\midrule
\multirow{5}{*}{ATTEST}
& \texttt{verification\_\allowbreak{}id} & UUIDv4 string & M & Must reference existing EVIDENCE (I1) \\
& \texttt{verdict} & enum & M & PASS, FAIL, NEEDS\_REVIEW \\
& \texttt{reviewer\_\allowbreak{}id} & agent-id string & M & Registered agent identity \\
& \texttt{confidence} & float & M & $[0.0, 1.0]$ \\
& \texttt{linked\_\allowbreak{}evidence\_\allowbreak{}id} & UUIDv4 string & M & Same as \texttt{verification\_\allowbreak{}id} (redundancy for traversal) \\
\midrule
\multirow{3}{*}{SYSTEM}
& \texttt{event\_\allowbreak{}type} & enum & M & CIRCUIT\_BREAKER, KILL\_SWITCH, HEALTH, MISC \\
& \texttt{event\_\allowbreak{}data} & object & M & Type-specific payload \\
& \texttt{severity} & enum & O & INFO, WARN, ERROR, CRITICAL \\
\bottomrule
\end{tabular}
\end{table*}

Three checks require runtime state beyond ordinary per-record JSON Schema validation. \textbf{C1 (Referential integrity)} resolves ATTEST evidence references. \textbf{C2 (Authority containment)} compares a child grant with its authorized parent, resources, expiry, and caveats. \textbf{C3 (Depth bounding)} validates the parent relation and depth limit. A conforming runtime must perform these before accepting or activating the relevant record; syntactic schema validation alone does not establish them.

\subsection{Cross-Link Identifiers}

IDP tuples carry cross-link identifiers where applicable, connecting them to the broader delegation tree:

\begin{itemize}
\item \texttt{intent\_\allowbreak{}id}---links to the originating agent intent declaration
\item \texttt{task\_\allowbreak{}id}---identifies the specific delegation task
\item \texttt{contract\_\allowbreak{}id}---links to the governing CONTRACT tuple
\item \texttt{capability\_\allowbreak{}token\_\allowbreak{}id}---links to the authorizing DCT
\item \texttt{verification\_\allowbreak{}id}---links ATTEST tuples to their supporting EVIDENCE
\end{itemize}

These identifiers support reconstruction if referenced records are retained, uniquely identified, and accessible. Parent pointers permit ancestor traversal; finding descendants or all related tuples also needs a complete searchable record set or reverse index. A dangling link can expose some omissions, but an entirely omitted branch is not detectable from cross-links alone.

\subsection{Lifecycle Invariants}

The IDP specifies three invariants. Their intended enforcement points are described separately from implementation evidence. Figure~\ref{fig:dctx-fsm} depicts lifecycle states; depth and capability checks occur at child creation, not by incrementing depth during ordinary state transitions.

\textbf{Invariant I1 (Evidence-before-verify).} Let $\mathcal{E}$ denote the set of EVIDENCE tuples in the governance bus at time $t$, and let $A$ be an ATTEST tuple submitted at $t$. I1 requires:
\begin{equation}
A.\texttt{verification\_\allowbreak{}id} \in \{ e.\texttt{evidence\_\allowbreak{}id} \mid e \in \mathcal{E} \}
\end{equation}
\emph{Required binding.} Existence is a minimum referential-integrity condition, not sufficient verification. Accepted evidence must also match the task, intent, contract revision, and authorized grant; its signature/tag and issuer role must be valid. The verifier must evaluate the contract's evidence requirements before issuing PASS. A runtime must serialize evidence acceptance and dependent attestation, or reject unresolved references and retry; this paper does not establish a particular lock or index implementation.

\textbf{Invariant I2 (Monotonic capability attenuation).} Let $D_p$ be the parent DCT and $D_c$ the child DCT under creation. I2 requires:
\begin{equation}
\begin{aligned}
\operatorname{Ops}(D_c) &\subseteq \operatorname{Ops}(D_p), \\
\operatorname{Resources}(D_c) &\subseteq \operatorname{Resources}(D_p).
\end{aligned}
\end{equation}
Here Ops denotes the allowed-operation set and Resources the authorized resource set. Resource-selector containment requires: for every selector $s_c \in D_c.\texttt{resource\_\allowbreak{}selectors}$, there exists $s_p \in D_p.\texttt{resource\_\allowbreak{}selectors}$ with $s_c.\texttt{resource\_\allowbreak{}type} = s_p.\texttt{resource\_\allowbreak{}type}$ and $s_c.\texttt{constraints}$ no less restrictive than $s_p.\texttt{constraints}$ (i.e., child constraints must imply parent constraints). Caveats and time-to-live follow the same monotonicity: child caveats must be a superset of parent caveats (more restrictive), and the child validity interval must be contained in the parent interval. Comparing duration alone is insufficient: a later-issued child with a shorter TTL can still outlive its parent. Resource identity as well as type must be contained, and arbitrary caveat implication needs a supported policy language.
\emph{Required enforcement.} Check containment before child activation and again at execution where revocation, expiry, or consumable budgets can change. Non-strict inclusion permits equal scope. Two children each granted the parent's remaining quota can still overspend in aggregate, so per-child containment does not replace reservation/accounting. No claim of absence of bypass paths follows from this predicate.

\textbf{Invariant I3 (Bounded delegation depth).} Let $\delta$ denote \texttt{MAX\_\allowbreak{}DEPTH} (currently 3). For any DCTX $x$ in a delegation tree rooted at $r$:
\begin{equation}
x.\texttt{chain\_\allowbreak{}depth} = \text{distance}(r, x) \;\wedge\; x.\texttt{chain\_\allowbreak{}depth} \leq \delta
\end{equation}
where $\text{distance}(r, x)$ is the number of parent-child edges from root $r$ to $x$.
\emph{Required enforcement.} Set root depth to zero and child depth to parent depth plus one when the child context is created; reject a child exceeding the bound. Transitions within the same task do not increase graph depth. Replanning count is a separate bound. The earlier description of incrementing depth on ISSUED-to-RUNNING conflated execution state with graph position.

\begin{figure}[htbp]
\centering
\begin{tikzpicture}[
  ->,>=Stealth,
  node distance=0.7cm and 0.9cm,
  every state/.style={minimum size=0.5cm,inner sep=1pt,font=\scriptsize},
  every edge/.style={draw,font=\tiny},
  term/.style={double,fill=gray!15},
]
\node[state] (P) {PRO};
\node[state,right=of P] (I) {ISS};
\node[state,right=of I] (R) {RUN};
\node[state,right=of R] (E) {EVD};
\node[state,term,below right=0.5cm and 0.4cm of E] (V) {VER};
\node[state,term,below=0.8cm of R] (F) {FAIL};
\node[state,below left=0.5cm and 0.4cm of E] (RP) {RPL};

\path (P) edge node[above]{} (I)
      (I) edge node[above]{} (R)
      (I) edge node[left,pos=0.3]{\,} (F)
      (R) edge node[above]{} (E)
      (R) edge node[right]{} (F)
      (E) edge node[right,pos=0.4]{\textbf{I1}} (V)
      (E) edge node[left]{} (RP)
      (RP) edge node[below]{} (F);
\coordinate (returnlevel) at ([yshift=-0.4cm]F.south);
\draw[rounded corners=3pt] (RP.south) -- (RP.south |- returnlevel)
      -- (P.south |- returnlevel) -- (P.south);
\end{tikzpicture}
\caption{DCTX state machine. PRO=Proposed, ISS=Issued, RUN=Running, EVD=Evidence\_Ready, VER=Verified, RPL=Replanned, FAIL=Failed. Double borders mark terminal states. I1 marks the evidence prerequisite for verification; I2 and I3 are checked when child contexts are created, outside this state-transition diagram.}
\label{fig:dctx-fsm}
\end{figure}

\subsection{Delegation Tree Structure}

A complete IDP delegation tree for a single execution run follows this structure:

\begin{lstlisting}
Root DCTX (human authorization)
  |-- Root CONTRACT (task objective)
  |-- Root DCT (full capability set)
  |-- Child DCTX_1 (adapter invocation)
  |     |-- Child CONTRACT_1 (adapter scope)
  |     |-- Child DCT_1 (attenuated caps)
  |     |-- EVIDENCE_1 (execution receipt)
  |     \-- ATTEST_1 (verification result)
  |-- Child DCTX_2 ... DCTX_n
  |-- SYSTEM (circuit breaker, health)
  \-- Root ATTEST (terminal verification)
\end{lstlisting}

The historical design records tuples in an append-mode JSONL bus with HMAC-SHA256 tags. A conforming receiver must reject invalid tags and ineligible writers. Whether every relevant action reaches this receiver is a separate mediation question.

\subsection{Append-Only Audit Semantics}

Corrections should append a new record linked to the original, with retention and uniqueness checks. Append-mode writes do not prevent another process from rewriting the file. HMAC authenticates retained content relative to key custody; it does not by itself detect deletion, truncation, reordering, or replacement by a key holder. A hash chain plus an independently trusted checkpoint can support stronger integrity claims, but complete lifecycle reconstruction also requires complete capture and retained evidence.

\section{Composability Evidence}

We illustrate how briefing and peer-review records could use the same six-type envelope. A mapping demonstrates representational reuse; it does not establish identical payload schemas or unchanged validator requirements.

\subsection{Case Study: Executive Briefing System}

The historical manuscript reports a system with four agents and six active service adapters, and a representative 32-entry run: seven DCTX, seven CONTRACT, six DCT, six EVIDENCE, four ATTEST, and two SYSTEM records. These counts are author-reported; the run trace is absent. In particular, four ATTEST records for six evidence records do not establish one verified evidence chain per adapter call unless an explicit many-to-one attestation policy is provided.

\begin{table}[htbp]
\caption{Historical Author-Reported Volume (15 active days; raw daily records unavailable)}
\label{tab:eval-stats}
\centering
\small
\begin{tabular}{@{}lrrr@{}}
\toprule
\textbf{Statistic} & \textbf{Entries/day} & \textbf{Contract/day} & \textbf{DCT/day} \\
\midrule
Mean & 10,013 & 42 & 38 \\
Median & 847 & 8 & 7 \\
Min & 33 & 2 & 2 \\
Max & 26,014 & 112 & 98 \\
Total (15 days) & 150,192 & 635 & 567 \\
\bottomrule
\end{tabular}
\end{table}

The total divided by 15 is 10,012.8 entries/day, consistent with the rounded mean. The summary statistics do not recover the daily distribution or establish workload causes, completeness, successful verification, or performance. The evaluation window's dates, inactivity definition, rejection counts, retry handling, and data-extraction revision must be supplied for replication.

\subsection{Case Study: Peer Review Protocol}
\label{sec:peer-review}

A proposed peer-review mapping uses CONTRACT for acceptance criteria, EVIDENCE for observed checks, ATTEST for verdicts, and SYSTEM for assignment/control metadata:

\begin{table}[htbp]
\caption{Peer Review to IDP Tuple Mapping}
\label{tab:peer-review-mapping}
\centering
\small
\begin{tabular}{@{}llp{2.8cm}@{}}
\toprule
\textbf{Peer Review} & \textbf{IDP Tuple} & \textbf{Rationale} \\
\midrule
PROPOSAL & CONTRACT & Binds scope and acceptance criteria \\
REVIEW verdict & ATTEST & Reviewer's verification result \\
Standards check & EVIDENCE & Automated verification receipt \\
DECISION & ATTEST & Terminal adjudication \\
Trust snapshot & SYSTEM & Reviewer trust telemetry \\
Reviewer assign & SYSTEM & COI check, diversity enforcement \\
Cascade depth & SYSTEM & Adaptive verification level \\
Amended review & ATTEST & Append-only correction \\
\bottomrule
\end{tabular}
\end{table}

A reviewer-selection policy can consider task expertise, conflicts of interest, and diversity, while a risk floor sets the minimum review required regardless of past scores. A Beta-shaped reputation score may summarize prior scored outcomes, but treating those outcomes as independent Bernoulli evidence is a modeling assumption. The expression $2/(\alpha+\beta)$ is not the variance of a Beta distribution, whose variance is $\alpha\beta/[(\alpha+\beta)^2(\alpha+\beta+1)]$. Arbitrary prior changes or forgetting require a separately specified uncertainty interpretation.

Review metadata can fit SYSTEM payloads without adding a seventh tuple class, but new payload validation and policy semantics are still required. This is a design case study rather than a demonstrated protocol-effectiveness comparison. Model-family diversity does not establish independent judgments or prevent fabricated citations by itself.

\section{Evaluation and Reproducibility}
\label{sec:eval}

\subsection{Evidence classes and unavailable artifacts}

Table~\ref{tab:eval-stats} contains historical author-reported aggregates, not a reproduced dataset. The original under-200-ms overhead claim has no hardware specification, repetitions, latency samples, or comparator in the bundle. It is not retained as an established performance result. Similarly, counts of tests or source lines without an executable revision and transcript do not demonstrate conformance or operational reliability.

Audit completeness needs an independent denominator. Define it as the fraction of independently observed in-scope actions having all required valid records under a declared policy. Counting records emitted by the same path under audit cannot detect actions that bypass that path. Future experiments should inject bypasses, omissions, invalid evidence links, and restart failures, then measure detection and prevention separately.

\subsection{Reported peer-review packet observation}

The historical manuscript reports fabricated citations in 2 of the first 4 packets and none of the next 11, for 15 packets total. The packet-level judgments and source-verification records are not bundled. Conditional on these reported counts, a fixed-margin two-sided Fisher exact calculation gives $p=6/105=0.05714$, correcting the earlier $0.047$. This calculation is reproduced by \texttt{trust\_\allowbreak{}analysis.py}; it does not validate the observations or justify causal inference. The time split was not documented as prespecified; packets share agents and evolving procedures, and there is no control arm. Absence of detected fabrication is not proof of absence of fabrication.

\subsection{Exact reconstruction of the trust-update model}
\label{sec:trust-analysis}

The new companion implements the stated no-decay model with exact rational arithmetic. It is an analytical reconstruction, not the unavailable historical \texttt{trust\_\allowbreak{}simulation.py}. Begin with Beta$(1,1)$. After $b$ successful rounds of reward weight $w>0$, $\alpha=1+wb$ and $\beta=1$. One failed round adds penalty $p>0$ to $\beta$. After $r$ further successes, returning to the pre-failure mean requires
\begin{equation}
\frac{\alpha+wr}{\alpha+wr+1+p}\geq\frac{\alpha}{\alpha+1}
\quad\Longleftrightarrow\quad wr\geq p\alpha.
\end{equation}
Thus the minimum recovery count is
\begin{equation}
r_{min}=\left\lceil\frac{p(1+wb)}{w}\right\rceil.
\end{equation}

For the baseline $w=p=1$, this is $b+1$. For weighted success $w=0.5$ and critical-failure penalty $p=3$, it is $3b+6$. Recovery is linear in buildup, not superlinear. The particular weights are design choices, not constants derived from a reputation theorem.

\begin{table}[htbp]
\caption{Analytical Recovery Counts (new reconstruction)}
\label{tab:gaming}
\centering\small
\begin{tabular}{@{}rrrr@{}}
\toprule
Build $b$ & Baseline & Weighted, $p=2$ & Weighted, $p=3$ \\
\midrule
10 & 11 & 24 & 36 \\
20 & 21 & 44 & 66 \\
30 & 31 & 64 & 96 \\
50 & 51 & 104 & 156 \\
\bottomrule
\end{tabular}
\end{table}

\begin{table}[htbp]
\caption{Sensitivity at $b=50$: Exact Recovery Counts}
\label{tab:sensitivity}
\centering\small
\begin{tabular}{@{}rrrr@{}}
\toprule
Reward $w$ & Penalty 2 & Penalty 3 & Penalty 5 \\
\midrule
1 & 102 & 153 & 255 \\
0.5 & 104 & 156 & 260 \\
0.25 & 108 & 162 & 270 \\
\bottomrule
\end{tabular}
\end{table}

At fixed $b$ and $p$, changing $w$ affects the intercept $p/w$, not the slope $p$. The prior sensitivity table is withdrawn because it does not follow the stated update rule. The companion removes the arbitrary 100-round display cutoff. At $b=30$, $w=0.5$, the mean changes from $16/17$ to $16/20$ after a critical failure; this is a score consequence, not evidence that the attempted action was prevented.

A review-depth floor can block score-based reduction below that floor independently of these weights. Establishing attack resistance requires modeling attack payoff, scoring accuracy, ability to choose easy tasks, correlated outcomes, identity replacement, and the actual probability of malicious acceptance. None is present in this arithmetic. Temporal decay and bootstrapped priors also change the model and are not covered by these tables.

\subsection{Commands and checks}

From the repository root, run:
\begin{lstlisting}
python papers/crai-typed-tuple-profile/trust_analysis.py
python -m unittest discover \
  -s papers/crai-typed-tuple-profile \
  -p test_trust_analysis.py
\end{lstlisting}
The tests cross-check the closed form against stepwise exact updates over 96 parameter combinations and verify the Fisher calculation. They validate arithmetic, not a deployment, reviewer behavior, or source data authenticity.

\section{Discussion and Limitations}

\subsection{Implementation and mediation boundary}
\label{sec:impl-gaps}

The public reference repository~\cite{reference-impl} at commit \url{5538bfadd52dd5557b4e42732d9787f7e36dadf5} contains Python delegation, context, and bus modules and a synthetic log. It supports source inspection of that revision. It does not include the complete schema, TLA+ model, and historical trust harness asserted by the old manuscript. The stronger profile predicates in this paper require implementation-to-specification checks with invalid fixtures; matching class names is insufficient.

Scheduler or adapter validation can be bypassed if an agent retains direct tool, network, or subprocess authority. Production enforcement requires non-bypassable mediation over an explicitly declared boundary. An environment-variable bypass, writable state, or shared signing secret accessible to the agent weakens that boundary. Host confinement, independent observation, and emergency controls are not established by the record schema.

\subsection{Key custody, retention, and scale}

HMAC records assume trusted shared-key custody. Stable keys and rotation history are needed for verification after restart; an ephemeral fallback cannot authenticate prior process records. Cross-organization independent attribution requires a suitable public-key protocol and trust policy, including key identity and revocation. This is more than substituting an algorithm name.

Operational volume alone does not establish throughput, latency, reliability, or scalability. Flat-file reconstruction costs, missing branches, retention expiry, corruption, and concurrent writers require measurements. No independent multi-organization evaluation is available here.

\subsection{Formal verification boundary}

Stated invariants are proof obligations, not completed model-checking results. A depth-monotonicity predicate does not prove capability-set attenuation: a deeper child can still carry expanded authority. A sound abstraction must represent authority or prove a refinement relating depth to authority. The previously claimed TLA+ supplement is not in the archive, so this revision reports no reproduced TLA+ safety or liveness result. Eventual termination would additionally require explicit progress/fairness assumptions and bounds on replanning; a diagram alone does not supply them.

\section{Conclusion}

The IDP provides a concrete vocabulary for connecting delegated authority, execution receipts, and verification decisions. The two case mappings illustrate how that vocabulary can be reused. The released evidence supports a design contribution and reproducible arithmetic, while historical operational summaries remain unverified. Future work should bind a complete schema to a tested implementation, publish sanitized traces and measurement protocols, and evaluate mediation and adversarial behavior independently of record volume or trust-score changes.

\begin{thebibliography}{9}
\bibitem{w3c-prov}
W3C, ``PROV-Overview: An Overview of the PROV Family of Documents,'' 2013. \url{https://www.w3.org/TR/prov-overview/}.

\bibitem{ietf-rats}
H. Birkholz, D. Thaler, M. Richardson, N. Smith, W. Pan, ``Remote ATtestation procedureS (RATS) Architecture, RFC 9334,'' 2023. \url{https://www.rfc-editor.org/rfc/rfc9334}.

\bibitem{macaroons}
A. Birgisson, J. G. Politz, U. Erlingsson, A. Taly, M. Vrable, M. Lentczner, ``Macaroons: Cookies with Contextual Caveats for Decentralized Authorization in the Cloud,'' 2014. \url{https://research.google/pubs/macaroons-cookies-with-contextual-caveats-for-decentralized-authorization-in-the-cloud/}.

\bibitem{biscuit}
Eclipse Biscuit, ``Biscuit authorization token specification,'' accessed October 10, 2026. \url{https://github.com/eclipse-biscuit/biscuit/blob/main/SPECIFICATIONS.md}.

\bibitem{ucan}
UCAN Working Group, ``UCAN specification,'' accessed October 10, 2026. \url{https://ucan.xyz/specification/}.

\bibitem{spiffe}
SPIFFE Project, ``SPIFFE Overview,'' accessed October 10, 2026. \url{https://spiffe.io/docs/latest/spiffe-about/overview/}.

\bibitem{hmac}
H. Krawczyk, M. Bellare, R. Canetti, ``HMAC: Keyed-Hashing for Message Authentication, RFC 2104,'' 1997. \url{https://www.rfc-editor.org/rfc/rfc2104}.

\bibitem{arize-bias}
A. Panickssery, S. R. Bowman, S. Feng, ``LLM Evaluators Recognize and Favor Their Own Generations,'' 2024. \url{https://arxiv.org/abs/2404.13076}.

\bibitem{reference-impl}
HUMMBL, ``Governance Tuple Reference Implementation, revision 5538bfadd52dd5557b4e42732d9787f7e36dadf5,'' 2026. \url{https://github.com/hummbl-io/governance-tuple-reference/tree/5538bfadd52dd5557b4e42732d9787f7e36dadf5}.

\end{thebibliography}
\end{document}