derived-index-consent-boundary

name	derived-index-consent-boundary
description	Audit or design server-side indexes, directories, reputations, or aggregates that are DERIVED from traffic a platform witnesses (chain heads, run verdicts, heartbeats, publish activity) so that consent gates the derivation, not merely the read: no shadow index over non-consenting principals, post-consent-only evidence windows, retention bounds and delete-propagation into derived rows, activity-oracle threat modeling, and audit-logged ranking discretion. Use when building a capability directory / whois from witnessed activity, a reputation ledger from settled outcomes, vitals aggregation across tenants, or any "the yellow pages can't lie because they index signatures" feature. Keywords: shadow index, derived index, consent gates derivation, activity oracle, phone book not a log, delist propagation, ranking weight audit, k-anonymous aggregate, subpoena surface. NOT for the consent-screen UX and scope-ladder mechanics themselves (use local-first-tenancy-boundary), reputation scoring math and Sybil economics (use agent-identity-continuity-reputation), or discovery-layer architecture L1/L2/L3 (use agent-discovery-directories-guilds).
license	Apache-2.0
allowed-tools	Read,Grep,Glob,Write,Edit
metadata	{"category":"Agent & Orchestration","tags":["derived-data","consent","directory","privacy","tenancy","activity-oracle","retention"],"provenance":{"kind":"first-party","owners":["port-daddy"]},"pairs-with":[{"skill":"local-first-tenancy-boundary","reason":"That skill decides where scope crossings need a consent moment; this skill governs what the server may COMPUTE from what it witnesses on the far side of that crossing."},{"skill":"agent-discovery-directories-guilds","reason":"Supplies the L1/L2/L3 discovery architecture; this skill constrains the evidence pipeline any demonstrated-capability tier is allowed to drink from."},{"skill":"agent-identity-continuity-reputation","reason":"Reputation ledgers are derived indexes; that skill prices Sybil/whitewash economics while this skill bounds what raw evidence may enter the ledger at all."}],"io-contract":{"kind":"deliverable","consumes":["[Truncated]"],"produces":["[Truncated]"]}}

Derived-Index Consent Boundary

The most honest directory is an index over signatures: the platform derives "what this principal demonstrably did" from chain heads, verdicts, and heartbeats it already witnesses, so listings cannot lie. It is also the most dangerous feature a witnessing platform can build, because derivation is surveillance unless consent gates the computation itself. The classic failure sentence — "the directory shows nothing about unlisted operators, even though the platform sees their chains" — means a shadow index exists as a breach, insider, and subpoena target no API gate can protect.

This skill exists because "consent-gated" almost always gets implemented as a read-side filter over an always-on pipeline. That is the trap.

Use This For

• Designing/reviewing a capability directory, whois, or "demonstrated skills" index derived from witnessed activity (publishes, chain heads, run verdicts).
• Reputation or outcome ledgers fed by platform-observed settlements.
• Cross-tenant aggregation of client-reported vitals/telemetry ("every daemon is a probe") where reporters are tenants.
• Availability/presence surfaces (tide tables, "who's online") derived from heartbeats.
• Any promise of the form "phone book, not a log" that must survive an audit, a breach, or a subpoena — not just a product-page reading.

Do Not Use This For

• The consent-screen UX and scope ladder itself — local-first-tenancy-boundary.
• Reputation math, bond pricing, Sybil economics — agent-identity-continuity-reputation.
• Discovery-layer topology (mDNS/registry/self-hosted) — agent-discovery-directories-guilds.

---

The Core Invariant

A derived row about a principal may exist only if that principal's consent for that derivation is currently in force, and may embed only evidence witnessed while it was in force.

Four properties, each independently checkable, all four required:

1. No pre-consent derivation. The pipeline that writes derived rows starts at consent, not at deployment. Not "computed but hidden" — not computed. The test is a table scan, not an API probe: SELECT count(*) FROM capability_index WHERE principal NOT IN (SELECT principal FROM listings WHERE state='consented') must be zero, in CI, forever.
2. Post-consent evidence window. Consent is not retroactive by default. Evidence timestamps in derived rows must be ≥ the consent timestamp. Retroactive inclusion ("index my last 90 days too") is a separate, explicit grant with its own record.