diff --git a/docs/superpowers/plans/2026-09-17-spicedb-research-note.md b/docs/superpowers/plans/2026-09-17-spicedb-research-note.md
new file mode 100644
index 0000000..e2ff61b
--- /dev/null
+++ b/docs/superpowers/plans/2026-09-17-spicedb-research-note.md
@@ -0,0 +1,46 @@
+# SpiceDB Research Note Implementation Plan
+
+> **For agentic workers:** Execute this plan inline with validation checkpoints.
+
+**Goal:** Add and publish a sourced research note on SpiceDB as a fine-grained authorization substrate for agents and Cloud Foundry resources.
+
+**Architecture:** Describe SpiceDB's schema, relationship, permission-check, consistency, and datastore/API model. Then analyze a CF integration boundary where an external certificate-verifying component maps instance identities to stable SpiceDB subjects and applications ask SpiceDB for authorization decisions.
+
+**Tech Stack:** Markdown, YAML frontmatter, Devbox, Git, GitHub CLI.
+
+---
+
+### Task 1: Write the SpiceDB research note
+
+**Files:**
+- Create: `research/spicedb.md`
+
+- [ ] Add frontmatter with title `SpiceDB: Fine-Grained Authorization for Agents and Cloud Foundry`, author `Ruben Koster (@rkoster)`, date `2026-09-17`, tags `[authorization, identity, agent-runtime, ecosystem-survey]`, `cf_areas: [uaa, capi, diego]`, `status: draft`, provisional ratings, and links to SpiceDB's repository, README, concepts, modeling, consistency, API, and Zanzibar sources.
+- [ ] Explain SpiceDB as a Zanzibar-inspired authorization database where schemas define relations and permissions, relationship tuples store facts, and clients issue checks or reverse lookups.
+- [ ] Cover consistency choices, caveated relationships, schema validation/tooling, supported datastores, gRPC/HTTP APIs, and the separation between authentication and authorization.
+- [ ] Explain agent/tool examples: an agent instance requesting access to a CF space, app, route, service binding, or tool, with relations representing ownership, delegation, membership, and environment boundaries.
+- [ ] Describe a proposed CF boundary where a gateway or policy service verifies an instance identity certificate, maps its verified identity to a stable subject, and queries SpiceDB; do not claim native certificate validation in SpiceDB.
+- [ ] Assess relationship synchronization from CAPI/Diego events, certificate rotation and revocation, latency/availability, tenant isolation, fail-open/fail-closed behavior, and auditability.
+- [ ] Add open questions around canonical subject IDs, delegated agent authority, stale tuples, revocation timing, policy ownership, and operational placement.
+
+### Task 2: Validate and inspect
+
+**Files:**
+- Test: `.github/scripts/validate_notes.py`
+
+- [ ] Run `devbox run validate` and expect all research notes and ideas to be valid.
+- [ ] Run `devbox run test` and expect success.
+- [ ] Run `git diff --check` and inspect `git status --short`; leave unrelated environment artifacts unstaged.
+
+### Task 3: Commit and publish
+
+**Files:**
+- Include: `research/spicedb.md`
+- Include: `docs/superpowers/specs/2026-09-17-spicedb-research-note-design.md`
+- Include: `docs/superpowers/plans/2026-09-17-spicedb-research-note.md`
+
+- [ ] Stage only the three intended files, using `git add -f` for ignored planning artifacts.
+- [ ] Commit with `docs: add SpiceDB research note`.
+- [ ] Push `research/spicedb` to origin.
+- [ ] Open a PR titled `docs: add SpiceDB research note` targeting `main`, with the repository checklist completed.
+- [ ] Verify the PR URL, branch, state, and CI status with `gh pr view`.
diff --git a/docs/superpowers/specs/2026-09-17-spicedb-research-note-design.md b/docs/superpowers/specs/2026-09-17-spicedb-research-note-design.md
new file mode 100644
index 0000000..120d8df
--- /dev/null
+++ b/docs/superpowers/specs/2026-09-17-spicedb-research-note-design.md
@@ -0,0 +1,45 @@
+# SpiceDB Research Note Design
+
+## Goal
+
+Add a sourced research note on SpiceDB as a fine-grained authorization substrate for agents,
+tools, and Cloud Foundry resources.
+
+## Scope
+
+The note will cover SpiceDB's Zanzibar-inspired architecture: schema-defined relationships,
+permissions, consistency, caveated relationships, reverse lookups, datastore/API boundaries,
+and the separation of authentication from authorization. It will then assess a possible CF
+integration in which instance identity certificates are verified outside SpiceDB and mapped to
+stable authorization subjects.
+
+The CF analysis will use examples involving agents accessing spaces, applications, routes,
+service bindings, tools, and other resources. It will discuss a shared SpiceDB service,
+relationship synchronization from CAPI/Diego events, certificate rotation and revocation,
+tenant isolation, latency/availability, and audit implications. It will not claim that SpiceDB
+validates CF instance identity certificates natively.
+
+## Structure
+
+Create `research/spicedb.md` using the repository template and required sections:
+
+1. Summary
+2. Key findings
+3. CF relevance
+4. Open questions
+
+Use provisional ratings and clearly label Cloud Foundry integration ideas as analysis or open
+questions rather than existing SpiceDB features.
+
+## Sources and evidence
+
+Use the SpiceDB GitHub repository and README, official concepts/modeling/consistency/API
+documentation where available, and the Zanzibar paper link referenced by the project. Claims
+about CF instance identity certificates, CAPI/Diego synchronization, and agent authorization
+will be framed as proposed integration boundaries.
+
+## Validation
+
+Run the repository's configured Devbox validation and test scripts, inspect whitespace and the
+staged diff, then commit the note, plan, and this design spec on `research/spicedb`. Push the
+branch and open a new PR targeting `main` without staging unrelated environment artifacts.
diff --git a/generated/research-map.html b/generated/research-map.html
index ee673dd..a2d1686 100644
--- a/generated/research-map.html
+++ b/generated/research-map.html
@@ -23,9 +23,9 @@
Focus use cases
Attested Workload Authority and Mediated Tool AccessExchange platform-attested workload identity for scoped authority while credentials and outbound tool access remain mediated by the platform.Strategic decision: Decide whether CF should become the portable trust and policy layer between agent workloads and the tools they invoke.Gap, experiments, and evidence
Current CF gap
CF issues workload identity certificates but does not exchange them for scoped tool authority, keep third-party credentials out of workloads, mediate off-platform access, or record delegation-aware audit events.
Candidate POC
Exchange a Diego instance identity certificate for a short-lived scoped token, invoke one allowed tool through a credential proxy and egress mediator, deny another, and emit attributable audit events.
Candidate RFC scope
Define workload token exchange, authority and delegation claims, credential brokering, outbound mediation and policy enforcement, audit events, revocation, and integration boundaries for UAA, routing, and service brokers.
CF can stage apps and run ephemeral tasks but cannot cheaply compose a reusable environment with per-session workspace state, select stronger isolation, constrain session networking, or resume the session lifecycle.
Candidate POC
Start two isolated sessions from one content-addressed staged environment, attach separate mutable workspaces, apply per-session egress policy, stop one session, and resume it on fresh compute.
Candidate RFC scope
Define environment and workspace references, session identity and lifecycle, isolation classes, network policy, workspace persistence and cleanup, scheduling, quotas, and compatibility with existing CF staging and task APIs.
Familiar < Novelty > EmergingEmerging < Maturity > Established
Unplaced notes (0)
All notes are placed.
Maturity x Actionability
Exploratory < Actionability > Ready to actEmerging < Maturity > Established
Unplaced notes (0)
All notes are placed.
+Gap, experiments, and evidence
Current CF gap
CF can stage apps and run ephemeral tasks but cannot cheaply compose a reusable environment with per-session workspace state, select stronger isolation, constrain session networking, or resume the session lifecycle.
Candidate POC
Start two isolated sessions from one content-addressed staged environment, attach separate mutable workspaces, apply per-session egress policy, stop one session, and resume it on fresh compute.
Candidate RFC scope
Define environment and workspace references, session identity and lifecycle, isolation classes, network policy, workspace persistence and cleanup, scheduling, quotas, and compatibility with existing CF staging and task APIs.