Skip to content
Back to skills

Derived Index Consent Boundary

ASecurity

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 director...

  • 2 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added September 24, 2026
toolsrustgoapi

Works with

  • cli
  • api

Security analysis

A100/100

Scanned September 24, 2026

npx -y skills add curiositech/port-daddy --skill derived-index-consent-boundary --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Derived Index Consent Boundary?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Derived Index Consent Boundary
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/curiositech-derived-index-consent-boundary/badge)](https://www.skillsdirectory.com/skills/curiositech-derived-index-consent-boundary)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
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:
      - { kind: derived-index-design, format: markdown }
    produces:
      - { kind: derivation-boundary-audit, format: markdown }
---

# 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.
3. **Revocation propagates into derivation.** Delist ⇒ derived rows drop (or
   tombstone to non-queryable) within a stated bound, verified by the same sweep that
   enforces retention. Account erasure ⇒ derived rows are in the erasure path's
   table inventory (derived tables are the rows erasure audits always miss).
4. **Retention bound on evidence.** Derived rows decay (recency windows, TTLs) so
   the index is a phone book with a memory span, not an unbounded activity log.

## The Audit Method

**Step 1 — Inventory the derivations.** List every table/materialized view whose
rows are *computed from* witnessed traffic rather than *submitted by* the principal.
Greps to locate candidates (locators, not verdicts): writes into `*_index`,
`*_reputation`, `*_sightings`, `*_presence` tables from publish/webhook/heartbeat
handlers; scheduled jobs that scan event or chain tables and write summaries.
Self-reports (a signed card the principal PUTs) are out of scope; the moment a
pipeline *joins* a self-report against witnessed activity, the joined product is a
derivation and in scope.

**Step 2 — For each derivation, find the gate's position.** Three positions; only
one is acceptable:

| Position | Shape | Verdict |
|---|---|---|
| Read-side filter | pipeline always runs; API checks consent before serving | **FAIL — shadow index.** Breach/insider/subpoena surface exists regardless of the API. |
| Write-side filter | pipeline runs per event; consent checked before each derived write | PASS if revocation also purges (property 3) |
| Pipeline subscription | consent event *starts* derivation for that principal; revocation *stops and purges* | **PASS — the canonical shape** |

**Step 3 — Run the activity-oracle threat model.** Even a fully consent-gated index
is an oracle about its members. Enumerate what a read-only adversary learns:
who is online and when (work-pattern inference), project/harbor names (hash them),
collaboration graphs (who publishes on whose channels), volume trends (business
intelligence). For each: minimize (hash names, bucket timestamps to coarse windows,
k-anonymize any cross-tenant aggregate with a stated k — refuse to serve aggregates
below k), or justify in writing on the trust page. A directory entry is a lens the
member chose to publish; make sure it is not also a telescope pointed at them.

**Step 4 — Audit the discretion.** Derived ranking implies editorial power. If
operators can down-weight "gamed" entries via server config, every weight change
must land in the audit log (who, when, old→new) — accountable discretion, not silent
editorial. Refuse-to-route confidence floors and cold-start `{results: [],
reason}` responses are part of honesty here: an empty index must say why, never 404.

**Step 5 — Check the evidence base's own integrity.** A derived index is only as
honest as its lowest-integrity input. Rank inputs: signed+chained events > signed
events > authenticated-transport claims > bearer-token/unattested streams. **An
unattested input tier poisons the index** (anyone holding the shared secret
manufactures "demonstrated" activity); either attest the source first (give the
publisher a real identity) or exclude that stream from derivation entirely — do not
launder it in as a labeled-but-rankable tier, because labels wash out in ranking.

**Step 6 — Emit the audit**: per derivation — gate position, evidence window,
revocation bound, retention bound, oracle exposures + mitigations, discretion audit
trail, input integrity floor. PASS/FAIL per property 1–4.

## Design Prescription (canonical pipeline)

```
consent event (scope-ladder crossing, explicit screen)
      │  writes listings row {principal, granted_at, scope, retro_grant?}
      ▼
derivation subscription starts  ──►  derived rows {evidence_ts >= granted_at, ttl}
      │                                      ▲
revocation event                             │ sweep: TTL decay + delist purge +
      └── stops subscription ── purge ───────┘ CI invariant scan (property 1)
```

- Consent, revocation, and every ranking-weight change are themselves signed,
  chained events — the boundary's own history is tamper-evident.
- The erasure job's table inventory names every derived table explicitly; adding a
  derived table without touching the erasure inventory fails CI.
- Publish the derivation spec (what is computed, from which inputs, with what
  windows) on the trust page. "Phone book, not a log" becomes checkable: bounded
  memory span, no rows without consent, deletion that provably propagates.

## Failure Modes Table

| Failure | Symptom | Countermeasure |
|---|---|---|
| Shadow index | consent checked at read; table full of non-consenting principals | pipeline-subscription gate; CI table-scan invariant |
| Retroactive creep | consent at T, rows cite evidence < T | evidence-window check; explicit retro grant |
| Erasure miss | account deleted, derived rows survive | derived tables in erasure inventory, CI-enforced |
| Activity oracle | index reveals schedules/graphs of members | hashing, bucketing, k-anonymous aggregates, trust-page justification |
| Silent editorial | rank weights tuned without trace | weight changes audit-logged; floors + reasoned empties |
| Poisoned evidence | unattested/bearer stream feeds "demonstrated" tier | attest the source first or exclude; never rank laundered tiers |
| Unbounded log | "phone book" accretes history forever | TTL/recency decay swept and reported |

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…