How do agents orchestrate the fix — and how do instruments verify it worked?
AGENT & INSTRUMENT DIAGRAM: IDENTITY & ACCESS
════════════════════════════════════════════════════════════
AGENTS (who applies force)
──────────────────────────
[ENG] Engineering Team — Fixes code, seeds data, builds tiers
[NAV] Dream Team (Nav) — Commissions via browser, validates independently
[CLK] Clerk (External) — Handles authentication, session management
[USR] Platform User — Signs up, triggers onboarding flow
INSTRUMENTS (what verifies/rewards)
────────────────────────────────────
(CA) ClerkAuthAdapter — Validates session, resolves identity chain
(PE) PolicyEngine — Enforces permission checks (canI method)
(GUR) governance_user_roles — Stores role assignments per org
(GAA) governance_access_audit — Logs access decisions
(MTC) Multi-Tenant Checklist — 54-item audit score (currently 22%)
(BC) Browser Commission — Independent verification via browser
FEEDBACK LOOPS
──────────────
LOOP 1: AUTHENTICATION (working)
┌────────────────────────────────────────────────────┐
│ [USR] → Sign in → [CLK] → Session valid? │
│ │ │ │
│ │ (CA) validates │
│ │ │ │
│ │ ExternalAuthId → SystemUserId │
│ │ → OrganisationId │
│ │ │ │
│ └── ApplicationContext ◄───┘ │
└────────────────────────────────────────────────────┘
STATUS: WORKING — the sensor reads correctly
LOOP 2: AUTHORIZATION (broken)
┌────────────────────────────────────────────────────┐
│ Server Action → (CA).validateContext() │
│ │ │
│ ▼ │
│ (PE).canI(context, action, resource) │
│ │ │
│ ├── defaultAllow: true → BYPASS (current) │
│ │ ⚠ Sensor disconnected — no feedback │
│ │ │
│ └── defaultAllow: false → Check (GUR) │
│ ├── 22P02 crash (wrong ID type) ← BUG │
│ ├── No role data → DENY │
│ └── Role found → (GAA) logs → ALLOW/DENY │
└────────────────────────────────────────────────────┘
STATUS: BROKEN — two bugs + missing data + sensor bypassed
LOOP 3: COMMISSIONING (operational)
┌────────────────────────────────────────────────────┐
│ [ENG] ships fix │
│ │ │
│ ▼ │
│ [NAV] opens browser → (BC) checks against PRD │
│ │ │
│ ├── PASS → Advance tier, update commissioning │
│ └── FAIL → [NAV] reports evidence → [ENG] fixes │
│ │
│ (MTC) re-audit after each tier │
│ Score: 22% → target 80%+ │
└────────────────────────────────────────────────────┘
STATUS: OPERATIONAL — the verification loop works
LOOP 4: ONBOARDING (broken)
┌────────────────────────────────────────────────────┐
│ [USR] signs up → [CLK] authenticates │
│ │ │
│ ▼ │
│ Auto-provision: create user + org │
│ │ │
│ ├── Role assignment: MISSING │
│ │ No (GUR) row created → no permissions │
│ │ │
│ └── [USR] hits dashboard → 22P02 → redirect loop│
│ │ │
│ ▼ │
│ [ENG] manual DB fix (1-24h wait) │
└────────────────────────────────────────────────────┘
STATUS: BROKEN — the actuator (role assignment) is missing
════════════════════════════ ════════════════════════════════
Control System Analysis
The authorization system is a control loop with disconnected components:
| Component | P&ID Equivalent | Status | Fix |
|---|---|---|---|
| Setpoint | Target state | Defined (Admin/Member/Viewer roles) | Seed role definitions |
| Sensor | PolicyEngine (canI) | Bypassed (defaultAllow: true) | Switch to defaultAllow: false |
| Controller | governance_user_roles query | Broken (22P02 — wrong ID type) | Fix query to use systemUserId |
| Actuator | Role assignment | Missing (no auto-bootstrap) | Assign role during provisioning |
| Feedback | governance_access_audit | Built but disconnected | Wire after sensor reconnected |
The fix sequence follows PID controller logic:
- Reconnect the sensor — fix the query so it reads correctly
- Restore the actuator — seed roles and assign on provision
- Enable the controller — switch defaultAllow to false
- Close the loop — audit trail captures every decision
Agent Responsibilities
| Agent | Tier 0 | Tier 1 | Tier 2 | Tier 3+ |
|---|---|---|---|---|
| Engineering | Fix query, seed roles, break loop | Auto-bootstrap, error pages | RBAC enforcement, tests | Invites, org switch, billing |
| Nav (Dream) | Verify: dashboard loads, admin accessible | Verify: fresh deploy auto-bootstraps | Verify: member can't access admin | Verify: invite end-to-end |
| Clerk | Continue auth (working) | Org sync webhook | — | SSO/SAML |
| User | Report lockout (done) | Test onboarding | Test role-based access | Test invite acceptance |
Gate
Verification for A&ID completeness:
- Every agent named (who applies force) — YES: Engineering, Nav, Clerk, User
- Every instrument named (what verifies/rewards) — YES: CA, PE, GUR, GAA, MTC, BC
- Feedback loops explicit — YES: 4 loops with status
- Control system mapping to P&ID — YES: setpoint, sensor, controller, actuator, feedback
Demand-Side Jobs
| Job | Struggling Moment | Hidden Objection | Tier |
|---|---|---|---|
| Let Me In | Owner deployed production app, can't access own dashboard | "Don't weaken security to fix onboarding" | T0 |
| Control Access | Everyone sees everything or nothing — no middle ground | "RBAC will take weeks instead of features" | T2 |
| Isolate Data | No enforcement beyond FK — query could leak across tenants | "RLS is hard to debug when data doesn't show up" | T2-T3 |
| Invite Members | No self-serve invite — admin needs developer to add users | "What if I invite someone by mistake?" | T3 |
| Manage Org | No billing, no settings scope, no activity visibility | "Customers don't pay for settings pages" | T4 |
Role Definitions
| Role | Dashboard | CRM Data | Admin Settings | Org Management | Invite Users |
|---|---|---|---|---|---|
| Admin | Full | Full CRUD | Full | Full | Yes |
| Member | Own org | Full CRUD | View only | No | No |
| Viewer | Read only | Read only | No | No | No |
Permission Model
Permissions follow {resource_type}:{action} pattern:
| Resource Type | Actions | Admin | Member | Viewer |
|---|---|---|---|---|
dashboard | read | Yes | Yes | Yes |
contact | read, create, update, delete | All | All | read |
deal | read, create, update, delete | All | All | read |
admin_settings | read, update | All | read | No |
org_members | read, invite, remove, change_role | All | No | No |
billing | read, update | All | No | No |
Commissioning
Browser-based validation against this PRD. The builder never validates their own work.
| Component | Tier | Status | How to Verify |
|---|---|---|---|
| Owner can access /dashboard | T0 | Blocked | Navigate to dashboard, confirm no redirect loop |
| Owner can access /admin | T0 | Blocked | Navigate to /admin, confirm admin panel renders |
ADMIN_EMAILS env var configured | T0 | Fail | Check Vercel dashboard |
| Roles seeded in database | T0 | Fail | Admin panel → user management |
| Auto-bootstrap Admin on first login | T1 | Not started | Fresh deploy, new user sign-up, verify Admin role |
| Three roles defined and enforced | T2 | Not started | Viewer cannot access admin routes |
| Cross-tenant isolation | T2 | Not started | Log in as org1 user, attempt org2 data |
| Invite-by-email works | T3 | Not started | Admin sends invite → correct org + role |
| Stripe billing on org | T4 | Not started | Payment creates invoice tied to org |
Context
- Capability Map — Previous: what can we do
- A&ID Template — The empty pattern
- Control System — PID controller mental model