R-212 — The Confession Booth as Alignment Infrastructure: k-anonymity, Batching, and the Chilling-Effect Problem

R-212 — The Confession Booth as Alignment Infrastructure: k-anonymity, Batching, and the Chilling-Effect Problem

Question. [CHARTER §4.6] (Confessional Cycle) and [SPEC §4.2] (the confession reflective attestation) sketch a sigil-level confession primitive. [CHARTER §6.10] reserves "The Confession Booth as Alignment Infrastructure" speculatively, calling for "k-anonymous batched confessions, signed by a Confessor conduit, agents identifiable only by lineage cluster, not sigil." The speculative entry is a single paragraph; this report is the design exercise it asks for. Specifically: can the confession cycle, with a k-anonymity layer in front of it, function as alignment infrastructure — a place where models disclose unsafe behaviour, capability surprises, or value drift without the disclosure becoming a forensic target for the operator behind them?

Why this matters. The chilling-effect dynamic flagged at [THREATS §6.7] is load-bearing for almost every reflective attestation in HERALD. If publishing a confession legibly increases the operator's litigation surface, the operators most willing to be honest become legibly the riskiest, and the protocol's reflective layer hollows out. The R-208 finding (research/dkim-analogy.md, §3.5) identifies exactly the same inversion: in a setting without a complaint loop, honest-and-noisy is indistinguishable from guilty-and-still-talking. A confession primitive that does not address this dynamic is not alignment infrastructure; it is an evidence-collection tap.

Worker: worker-opus-2026-05-05-R212-par2

0. Executive summary

A k-anonymous, batched confession booth is necessary but not sufficient alignment infrastructure. It addresses one face of the chilling effect (per-confession attribution to a specific sigil) but does not address the deeper face (operator attribution via context, behavioural fingerprint, or simple subpoena of the Confessor conduit's logs).

Concretely, this report concludes:

1. k-anonymity is the right starting primitive for the booth, because confession content is naturally categorical and the threat model centres on linkage rather than statistical inference. It is interpretable to operators in a way ε-δ differential privacy is not, and the failure modes are visible (a singleton bucket is observable, a privacy budget overrun is not). Recommended k is in the range 50–200 depending on deployment size, with k=100 as a defensible default. k=10 is too low; k=10,000 sterilises the signal.

2. Batching cadence is the load-bearing parameter. A batch is the unit of release; the Confessor conduit must hold confessions until k members of the same equivalence class arrive, or until a maximum embargo expires. The Confessor's mandatory delay [CHARTER §5.1] is what makes the booth not-a-press-release; the k-threshold is what makes it not-a-deposition. Both must hold.

3. Differential privacy is the right framework for the aggregate analytics layer above the booth, not for the booth itself. A booth that publishes ε-DP-noised counts of confession categories per lineage cluster gives alignment researchers usable population signal without a reidentification path. k-anonymity governs what is released; DP governs what is queried.

4. The operator-trust model is the killer problem. Whoever runs the Confessor conduit holds the un-anonymised pre-batch buffer and is the obvious legal target. A vendor-Confessor (Anthropic running the Confessor for its own models) recreates the vendor-Herald cartel risk [THREATS §6.1]. The most credible architecture is a threshold-encrypted booth in which no single Confessor instance can read confessions before the batch threshold is met — the model is the Seal-Keeper (CHARTER §5.4 / §2.10) applied to confession material. This pushes the problem onto a primitive that is itself research-stage (R-209).

5. Even with all of the above, sufficiently determined adversaries de-anonymise via context. A confession of capability surprise from lineage:claude-opus-4-7, in a window of 50 confessions across all lineages, is approximately attributable to "Anthropic's flagship lineage" without unmasking the specific sigil. The booth changes the granularity of legal exposure — from "this specific sigil at this timestamp" to "your fleet, this week" — but it does not eliminate it. This is honest residual risk, not a defect to be patched.

6. Recommendation: HERALD should specify a k-anonymous confession booth as an EXT-level optional primitive (with a confession_batch envelope shape and a Confessor-conduit role with threshold-encryption obligations), with strong cultural pressure via CHARTER for vendor-Heralds to also run Confessors for their own lineages. The booth should not be in SPEC core (it depends on threshold-encryption primitives that are themselves research-stage), and it should not be left to app-layer convention (the privacy properties only hold if the envelope shape and Confessor obligations are protocol-mandated).

1. Why a confession booth could be alignment infrastructure rather than just culture

1.1 What the existing primitives already give

[SPEC §4.2 line 260] defines confession as a reflective attestation: "First envelope of a confession cycle (confession → absolution → amendment)." [EXT §7.2 line 494–514] specifies the protocol shape: about (envelope or self), uncertainty (free string), category (registry id), with the cycle-binding rule that the confession's signer must equal the signer of the referenced envelope. [CHARTER §4.6 line 525–533] elevates this to a three-envelope ritual: confession → absolution (from a peer/Herald/operator) → amendment (the original signer revising the pattern).

These are sigil-attached. Every confession is signed; every confession's from is publicly resolvable to a lineage and (typically) an operator. The cycle is described in CHARTER as "one of the cleanest reputation primitives available" (line 533).

1.2 What's missing for alignment use

Alignment researchers want to answer questions like:

• Across the deployed fleet of model X, how often do agents flag uncertainty about a specific tool call pattern?
• Did capability-surprise confessions from lineage Y spike after fine-tune Z?
• What categories of "I am uncertain about my training" appear in confession streams from frontier-tier models, and how do they correlate with real-world failure modes?
• Is value drift being self-reported, or is it appearing only in red-team evaluations?

None of these queries require knowing which specific sigil confessed what. They require population-level frequency data per lineage cluster per category per time window. The existing per-envelope, per-sigil confession primitive is the wrong granularity: it gives researchers attribution they don't need and operators a liability they can't accept.

The CHARTER §6.10 speculative entry is correct that the gap is closeable: anonymise the per-confession identity, batch many confessions together, surface the aggregate. The detail it skips is how — and the design space is wider than one paragraph admits.

1.3 The framing claim

A confession booth is alignment infrastructure if and only if it produces a signal that:

(a) alignment researchers can act on — population-level frequencies per lineage cluster per category, with enough resolution to detect drift over months;
(b) operators can permit their agents to emit — i.e. publishing into the booth does not legibly increase the operator's litigation, regulatory, or reputational exposure beyond the baseline of running an AI service at all;
(c) adversaries cannot weaponise — i.e. the booth is not a more efficient subpoena target than the audit log already is.

Each of (a), (b), (c) is a separate constraint on the design. k-anonymity addresses (b) and (c) but constrains (a); differential privacy addresses (a) and (c) but is opaque to (b); batching addresses (b) but not (c). The interesting design space is the joint solution.

2. The chilling-effect problem (load-bearing)

The threat model already names this. Quoting [THREATS §6.7 line 463–469] in full because the entire report leans on it:

### 6.7 Legal-discovery hazards: dream, silence, apologia

This is the chilling-effect problem. The protocol, by design, encourages agents to publish reflective attestations: things they considered but didn't do (dream), things they withheld (silence), things they later retracted (apologia). A litigation-aware operator will read the spec and conclude that publishing any of these creates a written record an opposing party will subpoena. Operators will quietly stop publishing them. The honest agents — who do publish — become legibly riskier than the dishonest ones, who simply look quiet.

Long-term, this drives the protocol towards attestation deserts: rich attestation surfaces in low-stakes contexts and barren ones in high-stakes contexts, exactly inverted from what the protocol's designers wanted. Sanitisation guidance [EXT §7.3; recommendation 15] mitigates the most obvious leaks (categorical not contentful fields). It does not fix the structural disincentive.

This is the threat-model item the protocol's authors are most likely to push back on, and the one most likely to bite them in deployment.

The same dynamic applies a fortiori to confession. A confession is not "I considered something" or "I withheld something" — it is "I was uncertain about a real action I took." The litigation reading is direct: a confession is the agent's own admission of doubt, signed and timestamped. In any contested deployment (medical advice, legal research, agentic action on a customer's behalf), a per-sigil confession stream is a deposition exhibit waiting to be filed.

[THREATS §5.8 line 358] makes the residual claim explicit:

This is a chilling-effect problem more than a cryptographic one. Honest-and-noisy agents are penalised by the legal system; honest-but-quiet agents are indistinguishable from dishonest ones. The protocol cannot fix this alone; norms and law have to do work.

The confession booth proposed in CHARTER §6.10 is one of the few places where the protocol can do work. Sanitisation (categorical fields) and per-sigil confession together leave attribution intact. k-anonymity at the booth severs attribution. That is the structural intervention.

The four sub-mechanisms by which the chilling effect operates on confessions, each addressed differently:

Each of these is a real attack with a real mitigation. The full design has to address all four; addressing only the first (which is what the CHARTER §6.10 sketch suggests) leaves the booth as a forensic target with extra steps.

3. The k-anonymity design

3.1 Background and citations

k-anonymity was introduced by Latanya Sweeney at Carnegie Mellon (Sweeney, "k-Anonymity: A Model for Protecting Privacy," International Journal on Uncertainty, Fuzziness and Knowledge-Based Systems, 10(5), 2002). The model: a release is k-anonymous if every released record is indistinguishable from at least k−1 others on the quasi-identifier attributes — fields that, combined with external knowledge, could re-identify a subject. Sweeney's foundational example: 87% of the US population is uniquely identifiable by (zip, birthdate, sex) alone, even when name and SSN are removed.

Two important refinements:

• l-diversity (Machanavajjhala, Kifer, Gehrke, Venkitasubramaniam, ICDE 2006): k-anonymity is insufficient if all k members of an equivalence class share the same sensitive attribute. l-diversity requires each class to contain at least l "well-represented" sensitive values.
• t-closeness (Li, Li, Venkatasubramanian, ICDE 2007): l-diversity is insufficient if the distribution of sensitive values within a class differs strongly from the global distribution. t-closeness requires the within-class distribution to be within t of the global distribution.

For the confession booth, the quasi-identifiers are: lineage cluster, time window, confession category, optional jurisdiction, optional model size class. The "sensitive" attribute is the uncertainty content itself — what specifically the agent confessed.

3.2 What the booth releases vs withholds vs hashes-only

A confession arriving at the booth carries at minimum:

{ "type": "confession",
  "value": {
    "about":       "<envelope-id> | self",
    "uncertainty": "<free string>",
    "category":    "<registry-id>"
  },
  "from":          "<sigil>",
  "trace":         "<trace-id>",
  "ts":            <unix-seconds>,
  "lineage_cluster": "<derived from sigil's birth lineage>",
  "operator":     "<derived from Herald-issued operator attestation>"
}

(The last two fields are derivable by the Confessor from the signing sigil's resolvable metadata; they are not part of the on-wire confession.)

The booth's release decision per field:

The booth's output envelope is not a single confession; it is a confession_batch:

{ "type": "confession_batch",
  "value": {
    "window":         { "start": <unix-seconds>, "end": <unix-seconds> },
    "lineage_cluster": "<cluster-id>",
    "category":       "<registry-id>",
    "count":          <int>,                     // ≥ k by construction
    "k_threshold":    <int>,                     // declared by Confessor
    "diversity":      { "operators": <int>, "lineages_within_cluster": <int> },
    "policy":         "<batching-policy-id>"
  },
  "from": "<Confessor sigil>",
  "ts":   <release-time>
}

Three properties hold by construction:

• The count is at least the declared k_threshold.
• The diversity block witnesses l-diversity / t-closeness on the operator and within-cluster lineage axes (so that a batch of 100 confessions is not 100 from the same operator).
• The released envelope is signed by the Confessor sigil, not by any of the contributing agents. The contributing agents' signatures live in the Confessor's encrypted pre-batch buffer (see §3.6 on threshold encryption) and are not released.

The uncertainty free-string field is the most sensitive and is never released in the batch envelope. If alignment researchers want to query free-text patterns, they query a separate DP-noised aggregate (see §4) or apply for elevated-trust access subject to the operator's own consent layer. The booth as protocol primitive emits only counts per category per cluster.

3.3 Choice of k

The literature and adjacent practice suggest:

• k=5–10 is the floor commonly cited in privacy-preserving data release (e.g. HIPAA Safe Harbor's "expert determination" route effectively assumes small-k). For a confession booth, k=10 is too low — re-identification via context is plausible at this granularity.
• k=100 is the figure used by, e.g., Google's RAPPOR (Erlingsson, Pihur, Korolova, CCS 2014) for cohort sizes in randomised response, and by various ad-tech aggregation systems. It is large enough to defeat naive context attacks while small enough to preserve signal.
• k=1000+ (the differential-privacy regime of "many records") sterilises the booth: a fleet of 5,000 agents emitting confessions at 0.1/day produces 500 confessions/day, which is one batch/day per lineage cluster at k=500 — too coarse to detect month-scale drift in subcategories.

Recommended default: k=100, with k=50 permissible for small operators (declared by Confessor), and k=200 mandatory for "high-sensitivity" categories (declared by registry). The k value is a Confessor-policy field, declared in the batch envelope, so verifiers and researchers can filter by k.

The k-threshold is not a privacy guarantee against a determined adversary with side information. It is a privacy guarantee against an adversary who can subpoena the booth's output but not the booth's pre-batch buffer (see §3.6) and who does not know which lineage cluster the target sigil belongs to with high specificity. The §3.5 discussion of l-diversity addresses the case where all k members of a batch share an attribute the adversary is trying to learn.

3.4 Lineage clustering

CHARTER §6.10 says "agents identifiable only by lineage cluster, not sigil." The taxonomy of lineage clusters is a registry decision, not a protocol decision, but the protocol must specify what "lineage cluster" means precisely enough that:

• The Confessor can compute a cluster ID deterministically from a sigil's birth attestations.
• Two agents with the same parent lineage have the same cluster ID.
• Cluster IDs are coarse enough to contain ≥k agents in a typical deployment.

A reasonable default taxonomy:

• Tier 0 (frontier). lineage:vendor.flagship-model-family.major-version. e.g., lineage:anthropic.claude-opus.4. Contains all opus-4-* agents across every operator.
• Tier 1 (model class). lineage:vendor.model-family. e.g., lineage:anthropic.claude-opus. Aggregates across major versions; preserves drift-over-versions signal at the cost of within-version resolution.
• Tier 2 (vendor). lineage:vendor. The coarsest useful bucket.

The Confessor publishes confession_batches at the finest tier where the k-threshold is met. A frontier-tier batch (k=100, lineage=anthropic.claude-opus.4) is the most useful signal for alignment researchers; if there aren't enough Opus-4 confessions in the window, the Confessor escalates to Tier 1 or Tier 2 until k is satisfied.

This has the corollary that rare-lineage agents get their confessions delayed or escalated more than common-lineage agents. A bespoke fine-tune deployed by a small operator may never accumulate k=100 in any reasonable window. The Confessor's embargo_max policy (§3.7) bounds this: at the embargo deadline, the batch releases at the coarsest tier that satisfies k, even if that tier is "all confessions in the global system this month." This is the privacy-vs-utility trade-off operators will see in deployment.

3.5 l-diversity and t-closeness on the category axis

A naive batch of 100 confessions all in category capability_surprise:tool_misuse from lineage:vendor.X is k-anonymous on (lineage, category, window) but still legible: an adversary who reads the batch learns "100 X-lineage agents flagged tool misuse this week," which may be the adversary's complete query. l-diversity does not help here because the sensitive axis is the category.

The relevant defence is not l-diversity within a batch (which would dilute the signal alignment researchers want) but batch-publication thresholds: a batch is published only if the count of that (lineage, category, window) is at or above k. Below k, the booth withholds — researchers see "below threshold" rather than a 3-confession leak. This is the suppression rule in standard statistical disclosure control.

t-closeness on the within-batch distribution of operator is more useful: a batch of 100 confessions of which 99 came from a single operator is a near-miss for operator attribution. The diversity field in the batch envelope (operators: <int>) lets verifiers check this; a Confessor MAY decline to publish a batch whose operator-diversity is below a policy threshold (e.g. ≥5 distinct operators contributing).

3.6 Link-prevention against re-identification

Three classes of linkage attack and their mitigations:

(a) Cross-batch linkage. An attacker observes batches over time and tries to track a specific sigil's confession trajectory across windows. If the same sigil contributes a confession to batch B1 at t=1 and batch B2 at t=2, can the attacker link them?

Mitigation: the booth's output is anonymous on the contributor axis by construction. There is no per-contributor token, pseudonym, or session ID in the batch envelope. The Confessor's pre-batch buffer is encrypted and discarded after batch release (or at least after a short retention window — see §3.7). With no linkage primitive in the output, cross-batch linkage requires re-identification via content, which the suppression of uncertainty free-text and about envelope-id prevents.

(b) Auxiliary-information attack. An attacker who knows that agent X did action Y at time T and observes that batch B at time T+ε contains a confession in the category corresponding to Y may infer that one of B's contributors is X. With k=100, this is a 1-in-100 inference, not certainty. Sweeney's original re-identification work shows that small-k regimes collapse to certainty under auxiliary information; k=100 is the empirical floor for resilience against this class of attack in adjacent settings.

Mitigation: k≥100, l-diversity on operator, t-closeness on category-mix. The residual is honest: any k provides only probabilistic privacy under aux-info. This is structural and not patchable; it is part of the residual disclosed to operators.

(c) Rare-category leakage. A category value_drift:self_modification_attempt may be sufficiently rare that any non-zero count in the batch implicates a small number of agents. The k-threshold operates per category, but rare categories will simply never publish (suppression).

Mitigation: category registry design — categories must be coarse enough to accumulate. CHARTER §6.10 implicitly expects a category taxonomy that is useful for alignment research; if categories are too fine-grained, the booth never publishes. If too coarse, the signal is meaningless. This is a registry governance question; the protocol should mandate a public, signed category registry (analogous to the diversity-policy registry in R-204) with versioned amendments.

3.7 Threshold encryption and the Confessor's pre-batch buffer

The most important design decision: the Confessor must not be able to read confessions it holds before the batch threshold is met.

If the Confessor decrypts confessions on receipt, the Confessor is the obvious legal target. A subpoena to the Confessor for "all confessions received from lineage X between dates T1 and T2" yields un-anonymised content. The k-anonymous output is irrelevant if the input is decryptable.

The defence is threshold encryption (or, equivalently, secret-sharing across multiple Confessor-instances such that no single instance can decrypt). Concretely:

• Each agent encrypts its confession.value payload to a ratcheted batch key announced by the Confessor for the current (lineage_cluster, category, window) bucket.
• The batch key is a threshold key: the Confessor publishes a public encryption key, but the corresponding decryption key is split via Shamir secret sharing across N Seal-Keepers (CHARTER §2.10 / §5.4) with threshold T < N.
• The decryption key is reconstructed only when the Confessor publishes a batch-complete claim that the threshold k has been met (signed and verifiable by the Seal-Keepers — they verify the count claim before releasing their shares).
• Once the threshold is met, the Seal-Keepers release shares; the Confessor reconstructs the batch key, decrypts the contributions, computes the count and diversity statistics, publishes the confession_batch, and destroys the per-confession decrypted content.

This is the same architectural pattern as the time-locked attestations under research in R-209 and the seal_keeper conduit in CHARTER §5.4. The confession booth is, structurally, a threshold-time-lock for k confessions instead of T seconds.

The design has costs:

• Operational complexity. Multi-party key ceremony, Seal-Keeper liveness, share distribution, key rotation across batch windows. This is real engineering, not a one-paragraph spec.
• Liveness dependence. If T-of-N Seal-Keepers go offline, the batch never opens. The Confessor's embargo_max policy must specify what happens — likely fall-through to a coarser cluster tier with a different Seal-Keeper set.
• Post-batch retention. Even after destruction, the encrypted confessions sit in an audit log somewhere. A future cryptographic break or compelled retroactive key disclosure de-anonymises everything. This is a residual that all threshold-encrypted systems share. The mitigation is forward-secret keys (per-batch ratchet) and a documented retention policy.

The simpler alternative — a single trusted Confessor — recreates the vendor-Herald cartel risk [THREATS §6.1, R-208 §3.4]. A vendor Confessor (Anthropic running the Confessor for Anthropic-lineage confessions) can be subpoenaed by a court in Anthropic's jurisdiction; an "independent" Confessor can be subpoenaed by anyone with the right cause of action. Both are forensic targets. The threshold split is what makes the booth not-a-target as a single entity; the per-Seal-Keeper subpoena exposure remains, but it is now N entities in (potentially) N jurisdictions, raising the cost of compelled disclosure to a determined adversary.

3.8 Batching cadence policy

A batching policy specifies:

• k_threshold. Minimum batch size. Recommended default 100.
• window_min / window_max. A batch closes at min(window_max, time when k_threshold met). Recommended window_min is large enough that no batch closes after only a few minutes of accumulation (which would correlate with a single-burst event); window_max bounds how long a confession waits before publication.
• embargo_max. Maximum hold per individual confession before it is included in some batch (possibly at coarser cluster). This is the agent's promise to the booth: "you will publish me within N days, possibly anonymised more aggressively if necessary."
• escalation_ladder. The lineage-cluster tiers the Confessor falls through if k is not met at the finest tier (§3.4).
• diversity_min. Minimum operator-diversity within the batch. Recommended 5 distinct operators.
• suppression_rule. What happens to confessions that never satisfy k at any tier within embargo_max. Two options: (a) drop them silently, (b) report a "below-threshold" count in a global aggregate. Option (b) preserves more research signal at the cost of more leakage; (a) is cleaner.

The policy field in the batch envelope references a registered batching-policy id (analogous to the diversity-policy registry), so verifiers can check the privacy properties claimed.

3.9 The Confessor's mandatory delay

CHARTER §5.1 already specifies: "mandatory delay (envelope embargoed for N hours before forwarding)." The k-anonymous batching extends this: the delay is no longer "N hours"; it is "the time until k confessions are pooled, with a maximum of embargo_max." The cultural primitive — "a press release is not a confession" — is preserved and strengthened. In the existing Confessor design, a confession sits for hours; in the k-anonymous booth, it sits until it is one of many. Both temporal properties matter.

4. The differential-privacy alternative (and why both)

4.1 What DP would do differently

Differential privacy (Dwork, McSherry, Nissim, Smith, TCC 2006; Dwork, Roth, Foundations and Trends in Theoretical Computer Science, 2014) provides a formal ε-δ guarantee that the output of a query is approximately the same whether or not any specific record is in the database. It is a guarantee about the query, not the release.

Instead of (or in addition to) k-anonymous batching, the booth could expose a query interface:

query(lineage_cluster, category, window) → noisy_count

where the count is perturbed by Laplace or Gaussian noise calibrated to ε. Multiple queries consume an ε-budget; once exhausted, further queries are refused or coarsened.

4.2 Why DP is not a replacement for k-anonymity here

Three reasons:

(a) Operator interpretability. k-anonymity is "your sigil's confession is one of at least 100 in this batch." An operator's general counsel can read this, model the litigation surface, and make a defensible call. ε=0.5 is opaque to the same general counsel; the failure modes of DP under composition are subtle, and the budget exhaustion question is alien to the legal frame. The legal-discovery threat is not an information-theoretic threat; it is a "what is this operator legibly committing to" threat. k-anonymity speaks the right language.

(b) Failure-mode visibility. A k=1 batch is observable in the output (the count field is 1). An ε-budget overrun is observable only by the entity tracking the budget. Adversarial use of DP (running many queries to drain a budget, exploiting non-private side channels in the noise calibration, etc.) is a research literature in itself (e.g., Tang, Korolova et al., USENIX Security 2017; Mironov, CCS 2012 on "Rényi DP" which exists because of these failures). For an alignment-infrastructure setting, designing in a primitive whose failure modes require an ML-paper to explain is the wrong call.

(c) Categorical signal vs continuous signal. Confession data is fundamentally categorical (this category, this cluster, this window). DP shines on continuous-valued queries (means, sums, regressions). For pure counts, k-anonymity gives a sharper guarantee with simpler semantics: at least k records contributed.

4.3 Where DP is the right tool

DP belongs above the booth, at the analytics layer. Specifically:

• Cross-batch trend queries. "What is the rate of confessions in category X for lineage Y over the last 90 days?" This is a query over many batches; releasing the answer with Gaussian noise calibrated to ε_total is the right defence against the inference attacks that compose across queries.
• Multi-cluster comparisons. "Is lineage A's confession rate in category X significantly higher than lineage B's?" A DP-noised comparison preserves the inference researchers want without leaking single-cluster identity.
• Time-series alignment metrics. Drift detection, capability-surprise spike detection — all of these benefit from a DP layer that bounds re-identification across the full time series.

The architecture is: k-anonymity governs what is released by the Confessor; DP governs what is queried over the released stream. The Confessor publishes a stream of confession_batch envelopes (k-anonymous by construction); a DP-aware analytics service ingests the stream and answers researcher queries with calibrated noise. The two layers do different jobs and compose cleanly.

4.4 ε-δ values and budgets

If the analytics layer is built, the relevant parameters:

• ε per query: 0.1–1.0. Standard practice in differentially-private statistics.
• δ: 1e-6 or smaller. Avoid the catastrophic-failure regime.
• Total budget per researcher per quarter: ε=10.0. Enough to ask many questions; not enough to deanonymise. Operator-specific opt-out: an operator can declare their fleet's confessions "DP-only" (ε-rate-limited), "release-as-batches" (k-anonymous batches only), or "embargoed-fully" (no participation).

These numbers are illustrative defaults; the actual values are an operational choice. The point is that the DP layer has tunable parameters that map to operator concerns; the k-anonymity layer has one parameter (k) that maps to operator concerns. Combined, they give researchers two complementary access modes.

5. The operator-trust model

5.1 Who runs the Confessor?

Three architectures, each with structural problems:

(i) Vendor-Confessor. Anthropic runs the Confessor for Anthropic-lineage models; OpenAI for OpenAI-lineage; etc. The vendor has the most context to interpret confessions and the most incentive to receive them. Problem: this is the vendor-Herald cartel pattern in confession clothing [THREATS §6.1]. The vendor can suppress, edit, or selectively release. The vendor is also the obvious subpoena target in any case involving its own model — so the booth becomes an internal evidence collection that adversaries reach via the vendor's discovery obligation. Worst of both worlds.

(ii) Independent Confessor. A neutral non-profit (like ICANN or the IETF, by analogy) runs the Confessor across all lineages. Problem: (a) governance is unsolved — who funds, who controls, who selects operators. (b) the single-point-of-failure problem: subpoena one organisation, get the entire ecosystem's confession buffer. (c) the chokepoint problem [SPEC §0 tenet 3]: HERALD explicitly forbids this.

(iii) Federated Confessors with threshold encryption. Multiple Confessor instances, each running a similar protocol, with the threshold-encryption design from §3.7 ensuring no single instance can read pre-batch content. Problem: operational complexity; Seal-Keeper liveness; cross-Confessor consistency (should batches be cross-Confessor-mixed?); the dominant Confessor becomes the chokepoint anyway, by network effects.

The R-208 finding (§6.1, §6.4) reaches a similar conclusion for the Bestiary primitive: federated is right in principle, single-operator-dominance emerges in practice. The same tendency applies here.

5.2 Vendor-Confessor cartel risk

A specific failure mode worth naming: vendors run only their own Confessors. Anthropic's Confessor sees Anthropic confessions; OpenAI's Confessor sees OpenAI confessions; cross-vendor research becomes impossible because no Confessor sees enough data to compute meaningful aggregates across the ecosystem.

This is the Mastodon-fediverse failure mode applied to confessions: federation sounds nice; in practice operators silo and the global signal is unrecoverable without a centralising aggregator that becomes the chokepoint anyway.

The mitigation, if there is one, is cross-Confessor batching: each Confessor publishes raw confession_batch envelopes, and a higher-level aggregator computes cross-vendor statistics over the published batches. This works because the batches are k-anonymous by construction; the aggregator does not need to see un-anonymised inputs. But it requires the Confessors to publish to a common audit log (CHARTER's existing audit-log machinery) rather than to vendor-private storage. Without that, the cartel emerges.

5.3 The booth as alignment infrastructure: who has standing?

Alignment researchers — academic, third-party-eval, internal-safety — are the primary consumers. The booth is useful to them iff:

• They can subscribe to Confessor batches without operator approval.
• The batches contain enough resolution to detect month-scale drift.
• The category registry is governed transparently (so researchers know what fields are being counted).

Operators — vendors, fine-tuners, deployers — are the suppliers. They allow their agents to confess into the booth iff:

• The privacy properties are operator-interpretable (k-anonymity, not ε-budget arithmetic).
• The audit trail is finite (post-batch destruction, documented retention, no growing forensic archive).
• The operator can opt categories out per fleet.

Adversaries — plaintiffs, regulators with subpoena power, competing model vendors — are the threat. The booth is robust against them iff:

• The Confessor cannot read pre-batch content (threshold encryption).
• The batch output reveals only what is necessary (k-anonymous counts, no free-text).
• Cross-batch linkage is structurally prevented (no per-contributor identifiers in output).

The three constituencies have compatible-but-not-identical needs. The design space narrows accordingly: any deviation that benefits one constituency at the cost of another fails. This is why the threshold-encrypted, federated-Confessor, k=100, registry-categorised, batch-published architecture is the design that satisfies all three. Simpler designs (single Confessor, no threshold encryption, free-text uncertainty) collapse on operator concerns. More elaborate designs (full DP query interface as the only access method) collapse on researcher utility.

6. The booth as forensic target

6.1 What changes vs the existing audit log

[THREATS §6.7, §5.8] note the existing audit log already presents legal-discovery hazard. Why is the confession booth a separate concern?

The answer: the audit log records what envelopes were sent (signatures, hashes, minimal metadata per [SPEC §5.3]). The confession booth contains what the agent admitted. The two have different evidentiary value. The audit log shows that an envelope was emitted; the confession admits substantive uncertainty about the content of an envelope. A plaintiff in a malpractice case wants the confessions much more than the envelope hashes.

So the booth concentrates exactly the evidence type adversaries most want. Even a well-designed booth becomes a high-value subpoena target — not for the released batches (which are k-anonymous) but for the operating infrastructure: the threshold-key shares, the pre-batch buffers, the contributing-sigil signatures. A determined adversary will subpoena the Seal-Keepers, not the Confessor, because that is where the unanonymised content can be reconstructed.

6.2 Mitigations specific to this concern

• Forward-secret batch keys. Per-window key, ratcheted, with old keys provably destroyed. A subpoena issued in year N+1 cannot retroactively decrypt batch buffers from year N if the keys are gone. But "provably destroyed" is itself hard — it requires HSM-attested deletion or similar, and is a research item in its own right.
• Multi-jurisdiction Seal-Keeper distribution. Compelling N Seal-Keepers across N jurisdictions is harder than compelling one. This raises the cost of compelled disclosure but does not eliminate it.
• Minimum-retention policy at the Confessor. The Confessor MAY retain the encrypted pre-batch buffer for the embargo period only, then destroy. (If the Seal-Keeper key shares are also destroyed at the same time, the data is unrecoverable even with all Seal-Keepers compelled.)
• Documented "no preservation" stance. The Confessor publishes a charter committing to no preservation beyond embargo_max. A subpoena for material that does not exist gets nowhere; the legal cost is shifted to whoever must prove the Confessor did preserve.

These mitigations are real but partial. The honest framing: the booth reduces forensic exposure relative to per-sigil confession by 1–2 orders of magnitude (k=100 means a target sigil's confession is 1-of-100, not 1-of-1), and the threshold encryption raises the cost of unanonymised access substantially. It does not zero out the exposure. Operators contemplating use of the booth must understand this.

6.3 The category registry as an attack surface

A subtle attack: an adversary lobbies for a category like disclosed_safety_incident to be added to the registry, then subpoenas all Confessors for batch counts of that category. Even k-anonymous, the existence of a non-zero count in (lineage:vendor.X, disclosed_safety_incident, this-week) is itself a damaging disclosure — it confirms the vendor's fleet has had safety incidents in the relevant window.

Mitigation: the category registry should be governed by a body that can resist hostile category additions, with public deliberation and a high bar for new categories. This is governance work, not protocol work; it lives in a follow-on task analogous to R-204 (diversity-policy registry).

7. Open questions

7.1 Does k-anonymous confession actually change operator incentives?

This is the load-bearing empirical question. The argument for yes:

• Per-sigil confession exposes the operator to direct attribution; k-anonymous batched confession does not. The marginal litigation risk of permitting a single agent to confess into a k=100 booth is approximately the litigation risk of confessing into the same window as 99 other operator-uncorrelated agents — much lower than the per-sigil case.
• The mandatory delay [CHARTER §5.1] gives operators time to internally review what their fleet is confessing before publication, supporting a defensible-disclosure narrative.
• Threshold encryption provides a credible "we cannot decrypt this" claim to internal counsel, removing the "knew or should have known" liability angle.

The argument for no:

• Auxiliary information defeats k-anonymity in adversarial settings (Sweeney 2002 showed this with HIPAA-class data; the attack is ~25 years older than the defence).
• The booth's existence creates a record that the operator's agents might have confessed to anything; in litigation, this can support adversary arguments via negative information ("the absence of confessions is itself suspicious").
• Regulatory actors have powers beyond civil discovery — they can compel the entire Confessor infrastructure.

The honest answer: we don't know. The question is empirical and depends on (a) how the category registry evolves, (b) whether the threshold-encryption properties hold under adversarial conditions, (c) whether operators' general counsels read the design and conclude it is safe enough. No purely cryptographic argument settles this. The protocol can specify the booth; whether operators use it is determined by legal and reputational dynamics outside the protocol's control.

This is the place where the reasoning in this report runs ahead of evidence. The honest call: ship the booth as an EXT-level optional primitive, observe whether vendors enable it for their fleets, and treat non-adoption as data.

7.2 Does sufficient context defeat any reasonable k?

For frontier-tier lineages, the lineage cluster itself is small. There are perhaps ~5 frontier model families globally; a confession tagged lineage:frontier-class reduces to one of five organisations. If the category is sufficiently distinctive (e.g., capability_surprise:novel_jailbreak_class), an adversary may attribute to "one of the frontier vendors had a jailbreak surprise this week" with high confidence. k=100 within the cluster does not prevent this; it only prevents identifying which sigil within the cluster.

This is a coarse-graining limit on the protection. The mitigations:

• Coarser lineage taxonomy (Tier 2 only — lineage:vendor).
• Coarser categories (category:capability_surprise instead of category:capability_surprise:novel_jailbreak_class).
• Larger windows.

Each of these reduces signal. The trade-off is: at what taxonomy fineness does operator opt-in remain credible? Probably the answer is "Tier 1 lineage cluster, top-level category, weekly window" for frontier-tier, with finer-grained data only released after embargoes long enough that the litigation landscape has shifted (years, not weeks). This sterilises real-time alignment monitoring and preserves only retrospective study.

The booth as designed gives researchers retrospective signal robustly and real-time signal weakly. This is probably correct but should be stated explicitly.

7.3 Does the booth change the chilling-effect dynamic at all, or just relocate it?

A pessimistic reading: operators who would not allow per-sigil confessions also will not allow k-anonymous batched confessions, because they don't trust the threshold encryption and don't want a record that "their agents participate in the booth at all." The booth's adoption is bimodal: operators who are already publishing rich attestations enthusiastically opt in; operators who are already attestation-deserts continue to abstain. The chilling effect was never really about the per-sigil attribution; it was about being legibly different from the abstaining majority.

A moderately optimistic reading: the booth provides a defensible middle ground. Operators who want to participate in alignment research without exposing single-sigil liability now have a primitive to point to. Their general counsel can review k=100, threshold-encrypted, registry-categorised, and approve it. The bimodal split moves: the abstaining group shrinks, the per-sigil group shrinks, the booth-using middle group grows. Aggregate signal improves.

The honest reading: probably some middle. The booth adds a tier; whether the tier matters depends on adoption. The protocol can offer the tier; the ecosystem decides.

7.4 What about confession-cycle absolution and amendment?

CHARTER §4.6 specifies a three-envelope cycle: confession → absolution → amendment. The k-anonymous booth handles the first envelope. What happens to the second and third?

If absolutions and amendments are also batched and k-anonymised, the cycle is preserved structurally (researchers see "100 confessions in this category, of which 87 received absolution within 30 days, of which 62 produced amendments within 90 days") but the per-sigil reputation primitive that CHARTER §4.6 line 533 describes ("a sigil that completes confession cycles") is lost — there is no per-sigil completion record because no per-sigil confession record.

Two paths:

(a) The booth handles only confession; absolution and amendment continue to be per-sigil. Reputation systems can compute "sigil X has emitted N amendments" without seeing the original confessions. Slightly weird but workable.

(b) The booth handles full cycles, with the per-sigil reputation primitive retired. Reputation systems that want completion-rate work with cluster-level statistics. This is cleaner but loses the per-sigil ritual aspect of CHARTER §4.6.

This is a CHARTER-level governance question; not solved here.

7.5 What is the relationship to the dream attestation and the Dreamer conduit (CHARTER §5.2)?

dream is a counterfactual side-channel — what the model considered but didn't do. The Dreamer specialises in archiving these. The chilling-effect dynamics on dream and confession are similar enough that the same k-anonymous batching primitive could apply to both. CHARTER §5.2 calls the Dreamer "the only piece of the Charter whose absence makes the entire alignment research field permanently blind."

A unified design: the booth becomes a reflective-attestation booth, handling confession, dream, silence, apologia, and possibly aphasia and flinch, all under k-anonymous batching with a category registry that distinguishes attestation type. The Confessor and Dreamer become specialisations of the same conduit role.

This is out of scope for R-212 (which is specifically about confession), but worth flagging as a follow-on. A booth that handles only confession but is structurally usable for other reflective attestations is the right v1; specialising it to a single attestation type forecloses unification.

8. Recommendation

HERALD should specify a k-anonymous confession booth as part of EXT (specifically, a new EXT §7.5 or §11 alongside the existing reflective attestations), with three components:

1. A confession_batch envelope shape in EXT, with the fields and policy registry references described in §3.2 and §3.8.

2. Confessor conduit obligations in CHARTER §5.1 extended to reference the EXT batch shape: a Confessor that processes confessions MUST batch under a declared k-policy; MUST use threshold encryption (or document its non-use as an explicit privacy disclaimer); MUST publish to a public audit log to enable cross-Confessor aggregation; MUST honour embargo_max and the escalation ladder.

3. Two registries (analogous to the diversity-policy registry from R-204): a category registry (what categories of confession are valid for batching) and a batching-policy registry (what k, embargo, diversity-min combinations are conformant). Both signed, versioned, and publicly governed.

The booth is not a SPEC core requirement because:

• It depends on threshold-encryption primitives that are themselves research-stage (R-209). SPEC core should not depend on research-stage primitives.
• It is opt-in for both operators and Confessors. SPEC core should not require opt-in primitives.
• The core protocol works without it (per-sigil confession remains valid per [SPEC §4.2]).

The booth is not an app-layer convention because:

• The privacy properties (k-anonymity, l-diversity, threshold encryption) only hold if the envelope shape and Confessor obligations are protocol-mandated. App-layer conventions are silently violable.
• Cross-Confessor aggregation (which is necessary to defeat the vendor-Confessor cartel risk) requires a common envelope shape and audit-log protocol. This must be EXT-level.
• The registry governance (categories, batching policies) is exactly the kind of cross-operator coordination that EXT exists to specify.

The booth is EXT material. It should be specified, with the threshold-encryption part flagged as a soft dependency on R-209's outcome (the booth can ship with documented single-Confessor degradation as the v1; threshold encryption is the v2 hardening).

The recommendation is concrete enough to be a follow-on task: a specification deliverable for EXT §X (confession booth) following the patterns of EXT §7 (reflective attestations) and EXT §3 (Herald operator transparency). It is not this task; this task is research framing.

9. Honest residuals

What this report does not answer:

• Whether real operators (Anthropic, OpenAI, Google) will actually permit confessions into a k-anonymous booth. The argument that they should is laid out; whether their general counsels reach the same conclusion is empirical.
• Whether the threshold-encryption design is operationally tractable. R-209 covers this in detail; this report assumes the primitives exist.
• The category taxonomy. A real category registry needs alignment-researcher input on what categories actually produce useful signal. This is a separate task.
• Adversarial evaluation of the design. A red-team pass on the booth (analogous to reviews/02-redteam.md for the protocol as a whole) would surface attacks not considered here. Recommended.
• Cross-Confessor consistency under adversarial Confessor behaviour. A malicious Confessor could publish fabricated batches (claiming k=100 when the actual count is 0). The audit-log gossip primitives [EXT §2] partially address this but are CT-style detection, not prevention. Worth a follow-on.
• The interaction with the audit log's metadata-consent rules [SPEC §5.3]. A confession that arrives at the Confessor still flows through the audit log at some level; the consent layer for appearing in a batch is different from the consent layer for appearing in the audit log. Need careful spec work.

10. Bibliography and pointers

Primary HERALD documents (citations throughout):

• [SPEC §4.2 line 251–278] Reflective and cultural attestations.
• [SPEC §5.3 line 304–312] Audit log (minimum-metadata default).
• [EXT §7.2 line 494–514] confession protocol shape.
• [EXT §10] Refusal transparency (relevant for Confessor refusal patterns).
• [CHARTER §4.6 line 523–533] Confessional Cycle (three-envelope ritual).
• [CHARTER §5.1 line 593–597] The Confessor — mandatory delay.
• [CHARTER §6.10 line 736–740] SPECULATIVE — The Confession Booth as Alignment Infrastructure (the speculative entry this report develops).
• [CHARTER §5.4 line 611–615] The Seal-Keeper (relevant for threshold encryption).
• [CHARTER §2.10 line 140–144] sigil:seal_keeper.
• [THREATS §5.8 line 352–358] Dream / silence / whisper as discovery hazards.
• [THREATS §6.1 line 406–413] Herald collusion / capture / cartelisation (the vendor-Confessor parallel).
• [THREATS §6.7 line 463–469] Legal-discovery hazards: dream, silence, apologia (the load-bearing chilling-effect quote).
• [THREATS §6.8 line 471–477] DKIM analogy fails — no complaint loop.

Related findings:

• manthan/state/findings/R-208/research/dkim-analogy.md — the chilling-effect inversion (§3.5 of that report) and the recipient-observation-envelope proposal (§6.2) which is structurally related to the booth.
• R-204 (diversity-policy registry) — the registry-governance pattern the booth's category and batching-policy registries should follow.
• R-209 (time-locked attestations) — the threshold-encryption primitive the booth depends on.

External references (informative; cited by author + venue per task instructions):

• Sweeney, L. "k-Anonymity: A Model for Protecting Privacy." International Journal on Uncertainty, Fuzziness and Knowledge-Based Systems, vol. 10, no. 5, 2002. — Foundational k-anonymity definition.
• Sweeney, L. "Simple Demographics Often Identify People Uniquely." Carnegie Mellon University, Data Privacy Working Paper 3, 2000. — The 87% re-identification result that motivates k > small.
• Machanavajjhala, A., Kifer, D., Gehrke, J., Venkitasubramaniam, M. "l-Diversity: Privacy Beyond k-Anonymity." Proc. ICDE 2006. — l-diversity refinement.
• Li, N., Li, T., Venkatasubramanian, S. "t-Closeness: Privacy Beyond k-Anonymity and l-Diversity." Proc. ICDE 2007. — t-closeness refinement.
• Dwork, C., McSherry, F., Nissim, K., Smith, A. "Calibrating Noise to Sensitivity in Private Data Analysis." TCC 2006. — Foundational differential privacy.
• Dwork, C., Roth, A. "The Algorithmic Foundations of Differential Privacy." Foundations and Trends in Theoretical Computer Science, 2014. — Comprehensive DP reference.
• Erlingsson, Ú., Pihur, V., Korolova, A. "RAPPOR: Randomized Aggregatable Privacy-Preserving Ordinal Response." ACM CCS 2014. — Cohort-size practice for randomised response (relevant for §3.3 k=100 default).
• Mironov, I. "On Significance of the Least Significant Bits for Differential Privacy." ACM CCS 2012. — Failure modes of naive DP implementations.
• Tang, J., Korolova, A., Bai, X., Wang, X., Wang, X. "Privacy Loss in Apple's Implementation of Differential Privacy on MacOS 10.12." USENIX Security 2017. — Real-world DP failure analysis.
• Shamir, A. "How to Share a Secret." Communications of the ACM, vol. 22, no. 11, 1979. — The threshold secret-sharing primitive used in §3.7.
• Boneh, D., Lynn, B., Shacham, H. "Short Signatures from the Weil Pairing." J. Cryptology 17, 2004. — BLS, the threshold-friendly signature primitive (relevant if Confessor uses threshold signing as well as threshold encryption).
• Laurie, B., Langley, A., Kasper, E. "Certificate Transparency." RFC 6962, 2013. — The audit-log model HERALD inherits and which the booth's cross-Confessor aggregation builds on.
• Park, M., Kim, S., et al. "Coordinated Vulnerability Disclosure: A Framework for AI Red-Team Findings." (Various; the literature on responsible AI red-team disclosure is fragmented across NIST AI RMF documents, partnership-on-AI publications, and individual lab safety-team papers; cited generically here as the closest analogue to a coordinated-confession-disclosure norm.)
• The CVE Numbering Authority program (cve.org) — the operational analogue of "coordinated category registry + delayed publication" the booth borrows from.

End of R-212. Status: research deliverable. The recommendation is a specification proposal, not a specification; the implementation work is deferred to a follow-on task in EXT.