R-208 — DKIM-Analogy Failure Analysis

R-208 — DKIM-Analogy Failure Analysis

Question. [SPEC §7.4] line 393 admits: "the DKIM analogy is weaker for HERALD than for email because agent-to-agent traffic has no complaint-loop equivalent and most exchanges are bilateral." [THREATS §6.8] elaborates this in three paragraphs. This report decomposes the analogy precisely, identifies which DKIM-era mechanism is missing in HERALD's setting, and surveys what could plausibly substitute.

Why this matters. SPEC's threat-model summary leans on "the DKIM analogy" to justify why signatures-without-content-judgement is a sufficient first move. If the analogy is systemically weaker for agent-to-agent than for email, several downstream protocol decisions need re-examination — particularly the canonical NOT-defended list ([THREATS §8]) and the open question of how reputation systems are supposed to detect lies ([THREATS §7]).

Worker: worker-opus-2026-05-05-R208

0. Executive summary

DKIM is a three-layer system: (1) signature (the cryptographic guarantee that a domain signed a message), (2) complaint loop (the social mechanism by which recipients flag bad messages), and (3) reputation aggregation (the market mechanism by which complaint signals turn into deliverability scores). The analogy at [SPEC §7.4] is correct only for layer 1. Layers 2 and 3 fail in agent-to-agent settings for five compounding reasons, four of which are structural and not patchable at the protocol layer.

HERALD has partial substitutes for some of layer 2 (the Bestiary [EXT §8], endorsement and apologia attestations [SPEC §4.2; CHARTER §3], refusal-rate transparency [EXT §10]), but no protocol-level analogue for the FBL/ARF infrastructure that makes email's loop work. The gap is not closeable by the substrate alone. Three of HERALD's design decisions — the bilateral-by-default trust model, the "competing reputation systems" principle [SPEC §0 tenet 2], and the chilling-effect dynamic on reflective attestations [THREATS §6.7] — actively work against any complaint-loop substitute that would emerge organically.

Recommendation: stop invoking "the DKIM analogy" as a comprehensive defence. Restate it as a layer-1 analogue only, and replace the layer-2/3 part of the threat model with an explicit acknowledgement that lie-detection in HERALD requires either (a) the Bestiary primitive being adopted at scale, (b) a recipient-observation envelope class that does not yet exist in any of SPEC/EXT/CHARTER, or (c) the ZK selective-disclosure direction landing — none of which are guaranteed.

1. The question, framed precisely

[SPEC §7.4] makes a three-claim argument:

1. They signed them.

2. Once signed, they can't deny it.

3. Sometimes, repeated lies are detectable across traces — if a corpus exists, if observers share data across organisational boundaries, if the lie pattern is loud enough to clear noise floors.

[SPEC §7.4] then claims this is "the same property that makes DKIM useful for spam detection: phishing emails do sign valid DKIM. The signal is this domain is signing garbage, not DKIM prevents lies."

The claim is that signing-without-judgement, plus a corpus-driven detection layer, gives meaningful spam reduction. This is true for email. The question is whether it is true for agent-to-agent traffic, given the structural differences. [THREATS §6.8] answers in two sentences: it is not, because email's "this domain is signing garbage" signal is computable by aggregators with access to spam-button data, and HERALD's setting has no analogous data source.

This report extends that argument by:

1. Decomposing DKIM into the three operational layers most readers conflate.
2. Listing the email-side mechanisms (FBL, ARF, RBLs, ISP collaboration) that supply the complaint-loop infrastructure.
3. Asking, mechanism by mechanism, what HERALD has that could substitute, and what is missing.
4. Proposing concrete protocol-level additions, EXT-level additions, app-layer expectations, and concessions (the things that genuinely cannot be detected).

The goal is not to argue that HERALD should not exist; it is to be precise about what HERALD's signature substrate alone does and does not deliver, so that downstream design choices are grounded.

2. How DKIM actually works (in three layers)

DKIM (RFC 6376) is a cryptographic signature over selected header fields and the message body, with the public key published via DNS TXT under _domainkey.example.com. It is one of three SPF/DKIM/DMARC standards that together produce email's authenticity infrastructure.

The colloquial usage of "DKIM" to mean "email anti-spam" elides three distinct layers:

Layer 1 — Signature

A receiving MTA pulls the public key from DNS, recomputes the canonical body hash, and verifies the signature. The output is binary: pass / fail / none. Conformant DKIM gives the receiver a cryptographic guarantee that a particular domain signed this message, nothing more.

This is exactly the property HERALD's envelope signature provides ([SPEC §3]). The analogy at this layer is sound.

Layer 2 — Complaint loop

Receivers (humans, mostly) mark messages as spam. Their MUA (Outlook, Gmail, etc.) communicates the spam-marking back to the receiving ISP. The receiving ISP then communicates the complaint to the sending ISP via a Feedback Loop (FBL) — RFC 5965 (ARF: Abuse Reporting Format). The sender's ISP can correlate complaints to specific signing identities and either internally penalise the sender or terminate them.

The complaint loop has six concrete mechanisms:

Layer 3 — Reputation aggregation

The complaint signals get turned into deliverability scores per signing identity (domain, IP, DKIM selector). Sending ISPs use these scores to decide whether to deliver to inbox or spam folder. Major ISPs publish thresholds (Microsoft's SNDS, Google Postmaster Tools, etc.) and let senders see their own score.

The aggregation is not centralised. Multiple commercial and free providers exist. But there is enough cross-pollination (Spamhaus is used everywhere; the FBL standard is universal; large ISPs share data informally) that the same reputation signal eventually reaches every receiver. A domain that earns a bad reputation in Gmail's complaint flow will see that reputation echoed in Outlook's flow within days.

The DKIM analogy invoked at [SPEC §7.4] is the combination of all three layers, not just layer 1. When the colloquial spec author says "DKIM lets us detect spam," they are implicitly carrying layers 2 and 3 along.

3. The five compounding reasons the analogy fails for HERALD

[THREATS §7] lists five reasons "Claim 3 is too strong" in the Liar's Paradox restatement. Re-cast through the layer-2/3 lens, they map to specific complaint-loop mechanisms missing in agent-to-agent traffic:

3.1 No human spam-button equivalent

THREATS §7 (b): "observed by whom? In bilateral conversations with no third-party observer, there is no observation."

Email's complaint loop starts with a human recipient who notices something is off. The spam button is the cheapest signal in the entire infrastructure: one click, asynchronous, aggregates linearly with other clicks. The "noticing" is done by a brain that has eight evolutionary years of pattern-recognition adapted to text deception.

In agent-to-agent traffic, the recipient is another agent. It does not have a spam button. It does not natively notice deception. It can be programmed to flag unusual patterns, but the programming is part of the receiving agent's app-layer logic — not a protocol primitive. There is no shared report_spam envelope class in SPEC or EXT.

Mechanism missing: the cheap, default, asynchronous, aggregable signal from recipient to "the system."

3.2 No MUA→ISP signalling layer

Email's spam button is decoded into a structured ARF report by the recipient's MUA and forwarded to the sending ISP. There is no analogous infrastructure for HERALD. If a receiving agent decided to flag a sender, where does the flag go?

The closest HERALD primitive is the Bestiary ([EXT §8], [CHARTER §6.6]): a structured, signed registry of agents flagged for malicious patterns. EXT §8 adds due-process to address the defamation hazard the red-team review identified. The Bestiary is the correct structural answer to this gap — it is HERALD's FBL-equivalent.

But. The Bestiary is opt-in, federated, and has no canonical operator. A new joiner does not know which Bestiary to consult. There is no protocol-mandated subscription. The email FBL works because every major ISP runs one and they all interoperate via ARF; HERALD's Bestiary is one primitive among many, and there is no equivalent of "the major ISPs" because [SPEC §0 tenet 3] explicitly forbids that centralisation.

Mechanism missing: the default routing of complaint signals from receiver to "the senders' upstream." HERALD has the envelope shape (Bestiary entries) but not the routing fabric.

3.3 No FBL-equivalent ISP→ISP signalling

[THREATS §6.1] (Vendor-Heralds and the centralisation it doesn't prevent), §6.8 (no-complaint-loop), and the canonical NOT-defended list at [THREATS §8] item 2 collectively note: HERALD's reputation systems are app-layer, competing, and unwilling to pool data. There is no FBL-analogue ISP-to-ISP layer.

In email, the ISP-to-ISP layer works because:

• Reciprocity. Every ISP both sends and receives. They have symmetric incentives to share complaint data — a sender today is a receiver tomorrow.
• Standardised formats. ARF, DMARC rua/ruf reports.
• The Spamhaus baseline. A free, public RBL that every MTA queries by default. Even ISPs that don't share data privately benefit from the public layer.

For HERALD:

• No reciprocity. Some sigils only emit (a model serving inferences). Some only receive (a tool sandbox). The symmetric-incentive argument fails.
• No standard format for "complaint about a sender." The Bestiary is the closest; it is structured but optional and not standardised across operators.
• No public-baseline equivalent of Spamhaus. [SPEC §0] forbids the chokepoint that Spamhaus actually is in email. HERALD's threat model would consider a Spamhaus-equivalent a structural risk; email's pragmatic answer is to accept that risk because the alternative is a worse infrastructure.

Mechanism missing: the inter-operator trust that makes layer-2 signals propagate.

3.4 No reputation-aggregation chokepoint (by design)

[SPEC §0 tenet 2]: "Verifiable history, opt-in judgment. Anyone can build reputation on top — many can compete."
[SPEC §0 tenet 3]: "No chokepoint at the conduit layer."

These tenets are correct as design principles. They also rule out a Spamhaus-class consolidator. The result is structural: reputation systems will compete and will not pool data, and the dominant one becomes a chokepoint that the protocol claims to avoid (the [THREATS §6.1] vendor-Herald argument applies symmetrically to reputation systems).

This is HERALD's most distinctive trade-off. Email accepts a small handful of reputation chokepoints (Spamhaus, Talos, etc.) and gets functional spam filtering. HERALD refuses chokepoints and must therefore accept that the lie-detection signal is fragmented across competing reputation systems — and the dominant one (whichever it ends up being) re-creates the centralisation in protocol clothing.

Mechanism missing — by design: the universal reputation layer.

3.5 The chilling-effect dynamic [THREATS §6.7]

A subtle reason: even if HERALD had a complaint loop, the agents most likely to use it would be honest agents publishing reflective attestations (apologia, confession, dream, silence). [THREATS §6.7] argues that publishing these creates legal-discovery risk, which incentivises operators to suppress them. Honest agents become legibly riskier than dishonest ones.

The complaint-loop equivalent: even if a recipient_observation envelope class were defined, dishonest agents would emit fewer (less attack surface for litigation) than honest ones. The signal-to-noise ratio of "agent X is in many recipient_observations" would be inverted: it would correlate with honesty, not malice.

Mechanism missing — and inverted: the incentive structure that makes complaints reliable in the first place.

4. What HERALD has that could substitute

The question is not whether HERALD reproduces DKIM's complaint loop (it does not), but which of DKIM's layer-2/3 mechanisms have HERALD-side equivalents, partial or full. Inventory:

4.1 The Bestiary [EXT §8]

A structured, signed registry of agents flagged for malicious patterns, named like Linnaean species. — [CHARTER §6.6]

This is HERALD's strongest analogue to the FBL. EXT §8 specifies a bestiary_entry envelope with due-process primitives (challenge envelopes, evidentiary envelopes, time-bound entries) to address the red-team's defamation concern.

What it covers: structured complaint flow, with provenance — every entry signed, every challenge logged, due process specified.

What it does not cover: mandate to subscribe. There is no protocol-level reason a new joiner consults Bestiary X over Bestiary Y. The aggregation problem reappears one level up.

Recommendation: the v0.2 deliverables should include a baseline reference Bestiary (analogous to the original DNSBL operators) so the ecosystem has somewhere to bootstrap. This is a CHARTER-level convention call, not a SPEC requirement. Could be a follow-on task — Reference Bestiary operator (with charter, governance, dispute process). Currently no task tracks this.

4.2 endorsement and apologia as positive/negative signals [SPEC §4.2; CHARTER §3]

apologia retracts, endorsement affirms. Together they form a bilateral-positive-and-negative signal channel.

What it covers: point-to-point signals between agents that have observed each other directly. An agent that received bad output can signal apologia (if they were the speaker who got it wrong) or implicitly fail to endorse. An agent that received excellent output can signal endorsement.

What it does not cover: the third-party-observer case. If agent A lies to agent B in a bilateral conversation, agent C cannot endorse the truth or apologia the lie — they have no evidence. This is the structural bilateral-conversation problem.

Recommendation: the SPEC could (and the CHARTER does, at line 336) treat the endorsement graph as load-bearing for reputation. The graph itself is what reputation systems should aggregate over, not "raw envelopes." This is implicit in the threat model but not stated as a design principle in SPEC. Worth elevating.

4.3 Refusal-rate transparency [EXT §10]

A conduit that refuses to relay must publish the refusal rate. Aggregators can compute "this sigil is refused N% of the time at conduits X, Y, Z."

What it covers: market-derived signal. Conduit refusal correlates with sender misbehaviour (rate-limit triggering, abuse patterns).

What it does not cover: lies in attestations. A sender can be polite, comply with rate limits, never trigger refusal, and still sign false confidence and model attestations.

4.4 Audit-log analytics [EXT §2]

CT-style audit logs are queryable. A sigil's full envelope history (subject to the minimum-metadata default of [SPEC §5.3]) is observable. Statistical patterns can emerge — anomalous confidence distributions, suspicious apologia clustering, etc.

What it covers: corpus-driven detection. The closest HERALD has to "Spamhaus' aggregated complaint data" is the audit log itself. Anyone can compute statistics over it.

What it does not cover: bilateral conversations not logged. Ghost-mode envelopes ([CHARTER §6.4 ghost-mode]) explicitly do not appear. Private conversations between two agents over a pass-through conduit need not log to any public audit log.

Recommendation: increase the SHOULD-log baseline. Current [SPEC §5.3] makes minimum-metadata the default and full-metadata opt-in. For lie-detection purposes, the inverse default (log unless explicitly ghost-moded) would help. This is a load-bearing trade-off with [THREATS §6.3] (surveillance-by-default) and is exactly the trade-off ZK selective disclosure ([SPEC §11.2]) is meant to dissolve.

4.5 ZK selective disclosure [SPEC §11.2]

The future research direction explicitly identified at [SPEC §11.2] and [THREATS §9]. With ZK proofs, a recipient could publish "I observed sigil X violate property P, here is the proof" without revealing the full trace. This dissolves the bilateral-conversation problem at protocol level.

What it covers: a complaint-loop equivalent that respects the privacy properties HERALD wants to preserve. The honest version of "FBL for agents."

What it does not cover: today. ZK proofs of agent-behaviour properties are research-level; reference libraries do not exist. The R-201 task is a feasibility report on this.

5. The complaint-loop substitute mapping

The two unfilled slots are the recipient-observation primitive and the baseline reputation operator. The first is a SPEC/EXT addition; the second is a CHARTER governance choice.

6. Recommendations

6.1 Stop invoking "the DKIM analogy" as a comprehensive defence

The strongest recommendation is editorial. [SPEC §7.4] should be tightened:

Suggested rewording for SPEC §7.4 line 393:

"This is the same property that makes DKIM-class signatures useful: phishing emails do sign valid DKIM, and the signal is 'this signer is signing garbage' rather than 'DKIM prevents lies.' In email, that signal is computed by complaint-loop infrastructure (FBL, RBLs, reputation services). HERALD has no protocol-mandated equivalent of that infrastructure; reputation systems above the substrate are competing, app-layer, and will not pool data freely. The signature substrate is what the protocol delivers; the detection-of-lies layer is an open ecosystem question with no guaranteed solution. See [THREATS §6.8, §7]."

This says the same thing as the existing prose but with the layer-1-vs-layer-2/3 distinction explicit.

6.2 Add a recipient_observation envelope class (proposed for SPEC §4 / EXT §7)

Closest to "the spam button." A signed envelope from a recipient asserting an observation about an envelope it received:

{ "type": "recipient_observation",
  "value": {
    "of":       "<envelope-id>",        // observed envelope
    "claim":    "false-confidence" |    // categorical
                "false-model" |
                "tool-not-used" |
                "policy-violation" |
                "<other-from-registry>",
    "evidence": "<optional envelope-id>", // counter-evidence if available
    "scope":    "personal" | "publishable",
    "ts":       <unix-seconds>
  }
}

Properties:

• The signer's from is the recipient; the value.of references the observed envelope.
• A recipient_observation is itself a HERALD envelope and inherits all SPEC §3 protections.
• The claim is from a registered enumeration to prevent free-form defamation.
• scope: "personal" is a private observation (sender-side reputation); scope: "publishable" permits the observation to be aggregated.
• An aggregator counting recipient_observation envelopes against a sender produces the agent-to-agent equivalent of an FBL feed.

This addresses the spam-button gap (3.1), the MUA→ISP gap (3.2), and partly the FBL gap (3.3). It does not address the chokepoint problem (3.4) or the chilling effect (3.5).

The proposal is sketched, not fully specified. A follow-on task should produce the registry, the aggregation semantics, and the privacy implications. This is meta-recommendation; the substrate stays opt-in.

6.3 Promote the Bestiary to v0.2 minimum-viable

[EXT §8] specifies the Bestiary primitive. Currently no Tier 1 task instantiates it. The recommendation is to ship a reference Bestiary alongside the reference Herald in Phase 4 of the implementation plan ([SPEC §10] line 478–481). Without a working reference operator, the FBL-equivalent infrastructure has no demo.

6.4 Revisit the audit-log default at [SPEC §5.3]

The minimum-metadata default optimises for surveillance-resistance ([THREATS §6.3]). That trade-off is correct in the absence of ZK selective disclosure. But it forecloses the analytics-driven lie-detection path described in §4.4 above. The honest framing in the SPEC is: "we have chosen surveillance-resistance over lie-detectability; this is a real trade-off with a real cost." Currently SPEC §5.3 frames it as an unalloyed positive.

6.5 Concede the bilateral-conversation case explicitly

Some classes of lie are undetectable in HERALD's protocol-level setting and will remain so:

• Bilateral conversations between two agents over a pass-through conduit, never logged.
• Ghost-mode conversations [CHARTER §6.4].
• Lies that occur infrequently enough to sit below noise floors.
• Lies that no recipient is in a position to recognise (false confidence on a question the recipient cannot evaluate).

[THREATS §8] item 12 ("performative-honesty cover") and the implicit bilateral cases are already in the canonical list. The recommendation is to add an explicit "bilateral conversation lies" item to that list, named distinctly so it is not conflated with item 2's broader "agent signing false attestations."

6.6 Track the dependency on the ZK direction

ZK selective disclosure (R-201) collapses several of the failure modes. If the substrate is to make any meaningful claim about lie-detectability beyond layer 1, the ZK direction is the path. SPEC §7.4's claim should be conditional: "under the v0.2 substrate, lie-detection is app-layer and weakly supported; under a future ZK-enabled substrate, the ground rules change."

7. Comparison to other systems

7.1 TLS without Certificate Transparency (1995–2015)

For 20 years, TLS had layer-1 (signature on the certificate) without layer-2 (a structural reason for the certificate's existence to be publicly observable). The result: silent fraud — fraudulent CA-signed certificates issued to attackers were undetectable until someone happened to notice.

CT (RFC 6962) added the missing layer-2: every issued certificate must be logged in a public, append-only, hash-linked log. Aggregation services (crt.sh, Censys) emerged to detect anomalies. The CT-style infrastructure HERALD adopts at [SPEC §5.3, EXT §2] is an explicit response to the same problem.

The lesson for HERALD: the substrate itself ([EXT §2]'s STH/SCT/SIP machinery) is a layer-2 mechanism for the Herald-attestation class of claims. It is not a layer-2 mechanism for the envelope-content-truthfulness class of claims. CT reduces silent CA fraud; HERALD's CT analogue reduces silent Herald fraud. Neither addresses content honesty.

This is consistent with the SPEC's design tenets but suggests the public framing should be tighter: HERALD's CT machinery is anti-Herald-fraud, not anti-lie.

7.2 ATProto / Bluesky

ATProto has lexicons and signed records; it has no native complaint loop. Moderation is app-layer (Ozone is the closest; it is deployment-specific). The ecosystem is younger than email; complaint-loop infrastructure is not yet mature. HERALD will face the same maturity gap.

The lesson for HERALD: the absence of a complaint loop in a protocol does not imply the absence of moderation; it implies the moderation is not portable across deployments. Each deployment of HERALD will have its own moderation; cross-deployment moderation requires the protocol to provide a routing primitive (the Bestiary, in HERALD's case). That primitive is in EXT §8 but is not Tier 1 deliverable.

7.3 Active Directory's audit logs (counter-example)

Enterprise AD has detailed audit logs, central reputation, and a single operator (the enterprise IT department). Lie-detection works because the chokepoint is acceptable in that setting. HERALD explicitly rejects this trade-off ([SPEC §0]) and therefore cannot adopt the AD-class solution.

The lesson for HERALD: rejecting the chokepoint is principled, but the cost is real. The cost is paid in this exact area: lie-detection.

8. Open research directions

Beyond the ZK direction in [SPEC §11.2]:

1. Decentralised aggregation of recipient_observation-class signals. If the envelope class above is added, what aggregation primitive prevents the dominant aggregator from becoming a chokepoint? A federated approach with cross-signed aggregators (M-of-N agreement) is a candidate. Worth a research task once the envelope class is specified.

2. Privacy-preserving complaint flow. Bluesky / ATProto has the same problem; cross-pollination might be valuable. ATProto's app.bsky.graph.block is point-to-point; HERALD's recipient_observation would be sender-public. Different trade-offs.

3. Statistical detection floors. What is the minimum corpus size to detect an occasional liar (one false attestation per 10,000) at α=0.05? This is a power-analysis question that can be answered in advance of implementation. Worth a small research task.

4. Honesty signalling. The performative-honesty cover problem (THREATS §7 (e), §8 item 12): can a sigil prove it has not lied in some specified window without revealing the trace? A specific instance of the ZK direction.

5. The bilateral problem and gossip. [THREATS §4.4] cross-recipient gossip is unspecified. A gossip primitive that surfaces "this sigil told different recipients different things" would partially address bilateral lies. Worth specifying. R-215 in TODO is the cross-recipient gossip task.

9. Honest residuals

What this report does not answer:

• Whether the recipient_observation proposal in §6.2 is implementable without re-creating the chilling-effect dynamic. Recipients face the same legal-discovery risk that publishers of reflective attestations face. The proposal might fail the same way.
• The relative strength of audit-log analytics vs. a structured complaint stream for lie-detection. This is empirical and depends on how much traffic is actually logged in practice.
• Whether reputation systems will, in practice, refuse to pool data. The threat-model claim in [THREATS §6.8] is a prediction. Email proves it can go either way; the Spamhaus baseline emerged after years of grassroots operation, not from a protocol mandate.
• Whether the trade-off in §6.4 (default audit-log metadata) is the right one. This is a design judgement that should be made by the spec maintainer with the privacy / lie-detection trade-off explicit.

10. Bibliography and pointers

Primary HERALD documents (citations throughout):

• [SPEC §7.4] Liar's Paradox (the DKIM-analogy claim).
• [SPEC §4.2] Reflective and cultural attestations.
• [SPEC §5.3] Audit log (minimum-metadata default).
• [SPEC §11.2] Open question on ZK selective disclosure.
• [THREATS §6.7] Legal-discovery hazards and the chilling-effect dynamic.
• [THREATS §6.8] DKIM-analogy fails — no complaint loop.
• [THREATS §7] The Liar's Paradox, re-examined.
• [THREATS §8] Canonical NOT-defended list (items 2, 12, 17).
• [EXT §2] Audit-log STH/SCT/SIP / consistency / gossip.
• [EXT §8] Bestiary protocol-level due process.
• [EXT §10] Refusal transparency.
• [CHARTER §3] Affective / temporal / social attestations including endorsement.
• [CHARTER §6.6] Bestiary as Linnaean taxonomy.

External references (informative, no in-text URLs since the deliverable is markdown for the project tree):

• RFC 6376 — DomainKeys Identified Mail (DKIM) Signatures.
• RFC 5965 — An Extensible Format for Email Feedback Reports (ARF).
• RFC 7489 — Domain-based Message Authentication, Reporting, and Conformance (DMARC).
• RFC 6962 — Certificate Transparency.
• RFC 5321 / 5322 — SMTP / Internet Message Format (background).
• Spamhaus DBL / SBL — operational reference for layer-2/3 in email.
• AT Protocol Specifications — for the contemporary parallel project.

Existing tasks in the HERALD project that this report touches:

• R-201 — ZK provenance proof feasibility (load-bearing for §6.6 here).
• R-215 — Cross-recipient genesis-pinning gossip (related to §3.4 / §8.5 here).
• EXT §8 / future Bestiary task — currently no Tier 1 task; recommended as Phase 4 deliverable.

End of R-208. Status: research deliverable. No code or test vectors are produced; conclusions are reasoning, not measurement.