A platform-as-product that sits between the substrate (Steps 0–4) and the vibe-app developer. The substrate is the silicon. The Console is the OS, SDK, App Store, and observability surface that make the substrate consumable without re-deciding the substrate's doctrines on every new app.
The metaphor is two real things composed: the NES lockout chip ("only licensed cartridges run") and the iPhone App Store ("the SDK is the only way in, the sandbox keeps apps from compromising each other, the App Review is the gate"). For PayCargo this means: five concrete surfaces (Developer Portal, SDK Registry, App Registry, App Review Workflow, Cross-app Observability), three concrete constraints inherited from the substrate (identity, PII lockbox, egress point), five concrete SDK contracts enforced at the IAM/network/CI layers (not by convention), and a four-phase rollout that starts with just the platform team this week and lands the broader vibe-app developer audience by mid-60-day. Phase A is documentation and scaffolding only — no code yet. Phase B begins coded SDK packages once the doctrine survives a paper review.
By day 21 of Phase One, the substrate is hardened and one real vibe app (the observability app, Step 4.5) is in production with sign-in, role-gated admin, embedded docs, and a daily Bedrock narrative. The shape of "how vibe apps are built on PayCargo's substrate" has been validated once. The next two vibe apps (Sales monthly reports, the third TBD) will be built next week with the the external developer. Without a Console, the second and third apps re-invent the patterns the first earned. The substrate's leverage compounds zero times.
Two real-world reference designs solve this problem at industrial scale:
Nintendo's 10NES lockout chip ensured only licensed cartridges ran on the console. Quality was enforced at the silicon layer, not at the developer's discretion. The console refused to boot unrecognized cartridges. The cartridge format was published; the lockout mechanism was tamper-resistant.
For PayCargo: the substrate's doctrines (data governance grid, three-layer defense, lockbox tokenization, four-layer DB boundary, NFW egress) are the lockout chip. Vibe apps that try to bypass them fail at the IAM permission boundary, at the Terraform plan, or at the CI gate — not at the developer's mercy.
Apple's iOS pattern: Apple owns the OS. Developers own apps. The SDK is the only legitimate way to call into iOS. Every app runs in a sandbox that isolates it from other apps' data. App Review is the gate before public distribution. Push notifications, payments, location, file access — all go through SDK helpers that enforce policy.
For PayCargo: the substrate is the OS. Vibe apps are apps. The vibecode SDK is the only legitimate way to call into the substrate (Bedrock, lockbox, SoRs, audit emission). The governance cells (Step 4.5.a) are the per-app sandbox boundaries. The CI plan + human review is App Review. Cross-app dashboards (the Console's observability surface) are the equivalent of the App Store's "report a problem" + the developer's analytics console combined.
NES gives us the doctrine: the platform refuses to run anything the platform doesn't sign off on. iPhone gives us the operational shape: SDK, sandbox, App Review, registry, observability. Phase One built the silicon. The Console is the rest.
Five concrete things that together are "the Console." Each is a deliverable. Each can be partially built before the next starts.
A vibe app, dogfooded. Sign in via SSO, browse approved patterns, scaffold a new app, see your app's metrics. The interface platform-team uses to operate the Console; the interface vibe-app developers use to consume it.
Versioned, pinned vibecode/sdk/* packages in a private artifact store (CodeArtifact). Single source of truth for "this is how you call Bedrock," "this is how you reveal PII," "this is how you emit audit." Apps depend on tagged versions; upgrades are PRs.
Catalog of every deployed vibe app. Owner, cell, classification, status, cost, audit health, admin members. Powers the Developer Portal's "your apps" view and the Audit team's "what runs on this substrate" inventory.
PR template asking the right questions (problem, audience, governance cell, data classification, SoRs touched). CI plan validates SDK contracts at plan time. Human review for new patterns triggers a Step.X doctrine doc.
Per-app + cross-app dashboards. Recursive (the Console observes itself, like the obs app). Daily Bedrock narrative per app, generalized from Step 4.5's pattern. Anomaly surfacing across apps without leaking app-internal detail to other apps.
These surfaces map cleanly to existing platform anchors:
| Surface | Backed by | Existing pattern reference |
|---|---|---|
| 1. Developer Portal | S3 + CloudFront + Lambda + Cognito (a vibe app on the substrate) | Obs app shape (Step 4.5); reusable browser→Lambda template (Step 4.5.b) |
| 2. SDK Registry | AWS CodeArtifact private npm registry | MODULES.md vibecode SDK roadmap (already specced) |
| 3. App Registry | DDB table with app metadata; populated by Terraform on apply | The agent_state table pattern (existing substrate) |
| 4. App Review Workflow | GitHub PR template + GitHub Actions contract checks + CODEOWNERS | Step 3a CI gate (existing); extend with contract validators |
| 5. Cross-app Observability | CloudWatch dashboards + Bedrock narrative Lambda + DDB audit table | Obs app's narrative + dashboards generalized per-app |
The substrate already enforces three boundary classes. The Console doesn't loosen them — it makes them consumable. Each constraint gets a corresponding SDK helper that hides the substrate complexity from the app developer while keeping the enforcement intact.
Today: Cognito user pool with TOTP MFA, per vibe app. The obs app's pool (us-east-1_fJLnhjqnl) is the working reference.
The Console rule: two distinct identity concepts must both hold for any PII-touching operation.
cognito:groups claims so the SDK contracts don't care which path was used.sor-reader, internal). This is the IAM identity the substrate actually trusts for service access.Any SDK call that touches PII (lockbox reveal, SoR reads that surface customer data, audit emission carrying customer identifiers) checks both: (a) the calling developer's claim chain is valid, including group membership, and (b) the calling runtime role is in the allowed tier list for that data class. Neither alone is sufficient. The Console's SDK refuses to issue the operation if either check fails — before the substrate even sees the request.
For Phase A: we model the invariant under the existing Cognito + TOTP + invite pattern. The dual-auth contract survives the SSO swap because Identity Center federation merely changes where the developer-identity claims originate, not their shape.
Today: lockbox CMK exists, lockbox DDB token table exists, the reveal Lambda is scaffolded but not exercised. Phase One has no PII workloads (per the pilot constraint).
The Console rule:
vibecode/sdk/lockbox/reveal.ts — the audited reveal Lambda — with purpose codes and a TTL on the revealed plaintext (it never persists; it's returned to the caller for in-memory use during a single request).Enforcement: the four-layer DB boundary (Step 3 — Step.3.db-access-boundaries.html) becomes the SDK's only data access path. Apps that try direct DDB SDK calls fail at the IAM permission boundary because their tier role doesn't have the relevant DDB actions on PII-tagged tables. Static analysis on app code surfaces "looks like PII" patterns at PR time.
Today: Network Firewall + DNS Firewall in alert mode (Step 5 flips to drop / BLOCK). SoR allowlist exists: Salesforce, Monday, GitHub, GitBook.
The Console rule:
vibecode/sdk/sor/{salesforce,monday,github,gitbook}.ts helpers.Enforcement: apps' execution roles don't have generic outbound IP allowance. Egress is brokered exclusively through the SDK's egress proxy pattern. After Step 5 (NFW drop), this also becomes a network-layer enforcement, not just a code convention. Direct outbound calls fail at the NFW boundary.
Every vibe app must declare and the platform enforces five contracts. None of them are convention-only. Each fails at a different layer when violated, and each failure mode is legibly different from the others (so the operator knows which contract triggered).
| # | Contract | What it means | Enforcement layer | Failure shape |
|---|---|---|---|---|
| 1 | governance_cell | App declares which CMK cell encrypts its resources (Step 4.5.a). The cell must exist in the live grid. | Terraform plan-time lookup | Plan fails: "cell X not in data_governance_kms_keys" |
| 2 | three_layer_defense | Browser-facing surface uses CloudFront OAC + Function URL AWS_IAM + JWT in X-Auth-Token (Step 4.5.b). |
SDK template; CI plan validates resource shape | CI plan fails: "browser-Lambda surface missing OAC association" or "Function URL AuthType is NONE" |
| 3 | lockbox_only_pii | Raw PII never persists outside the lockbox. Reveal is single-shot, audited, TTL-bounded. | SDK static analysis at PR; IAM permission boundary at runtime | PR check fails: "PII-shaped string detected in non-lockbox write path" OR runtime AccessDeniedException on direct PII-tagged DDB writes |
| 4 | audit_emit_required | Every business operation emits a structured audit event via vibecode/sdk/audit.ts before the route handler returns. |
SDK linter on app code; runtime middleware enforces emission | PR linter fails: "route handler missing audit.emit()" OR runtime warning + circuit-breaker on repeated emission misses |
| 5 | cost_attribute | Every Bedrock call carries app + cell + purpose tags. Bedrock invocations without attribution are denied. | SDK wrapper auto-tags; CloudWatch dashboards refuse to render unattributed cost | SDK rejects the Bedrock call with structured error: "missing attribution; pass via invokeAgent(opts)" |
Each contract has a one-line "this is what the developer writes" form in the SDK that hides the substrate plumbing. The developer writes the declaration; the SDK handles enforcement. The contracts are the API surface of the Console.
Three layers, each with a clear ownership boundary and a clear interface upward.
The boundary that matters: nothing in the App layer talks to the Substrate layer directly. The Console is the only legitimate intermediary. Apps that try to bypass the Console (importing the AWS SDK directly, calling Cognito directly, doing raw KMS Decrypt) fail at the IAM permission boundary because their execution role doesn't grant those direct paths.
Layer 1 (Substrate) holds invariants. Layer 2 (Console) re-expresses them as developer-friendly contracts. Layer 3 (App) consumes via the contracts. A bug in Layer 3 cannot weaken Layer 1's invariants because Layer 3 cannot reach Layer 1 except through Layer 2's interfaces. This is what makes the iPhone security model robust against app-level bugs and what makes the Console robust against vibe-app developer mistakes.
The Console's identity invariant (developer-identity AND runtime-identity must both hold) needs to work today — before Identity Center SAML federation lands with the DNS administrator next week. The doctrine survives this transition because the invariant is expressed in claims, not in providers.
Same shape as the obs app:
cognito:groups claim. Groups today: admins (existing), developers (new), auditors (future).enable_sso_federation flag flips to true. Identity Center SAML IdP becomes the primary login path.cognito:groups shape the SDK already reads. No SDK changes required.The invariant the Console enforces is "every PII-touching operation requires both kinds of identity." The Cognito + TOTP path today, and the Identity Center SAML path next week, both produce a valid developer-identity claim chain. The substrate doesn't trust either provider directly — it trusts the claim shape the SDK validates. Provider swap is operational; doctrine is invariant.
Every vibe app passes through five lifecycle states. The Console makes each transition explicit.
vibecode/sdk/app-template/. CI plan validates SDK contracts. Existing CI gates from Step 3a stay in force. The app's Terraform module is structurally identical to the obs app's, parameterized.The transitions form the standard App Store-style governance flow, but with the substrate's CI-as-deploy-path replacing Apple's manual review.
Four phases. Phase A is documentation only. Phase B is the first coded SDK packages and the Developer Portal vibe app. Phase C is when vibe apps 2 and 3 consume the Console. Phase D is the maturation work that lands post-60-day.
Goal: doctrine is written down and the substrate change shape is clear. No SDK code yet. No Console vibe app yet.
audit.ts, cost.ts, governance/cell.ts, lockbox/reveal.ts, sor/{salesforce,monday,github,gitbook}.ts). Just signatures, contracts, examples — not code.Exit criterion: the platform team agree the doctrine is right, the SDK shape is right, and the constraints are enforceable.
Goal: the SDK exists as code, the Developer Portal exists as a vibe app, Identity Center federation lands with the DNS administrator, and the first new vibe app (Sales monthly reports, vibe app 2) is built consuming the Console end-to-end.
audit.ts, cost.ts, governance/cell.ts.vibecode/sdk/app-template/.enable_sso_federation = true flips on).Exit criterion: Vibe app 2 ships to a real PayCargo sales user. the external developer has a working mental model of the Console.
Goal: vibe app 3 ships. Cross-app observability surface is real. App Registry is operational.
lockbox/reveal.ts, sor/* (Phase 1 covers Salesforce + GitHub at minimum), governance/cross-org-grant.ts.Exit criterion: three vibe apps in production. The 60-day plan's Phase 03 commitment delivered.
Goal: the Console matures into a real product surface.
Exit criterion: any new PayCargo developer can ship a vibe app in < 1 day, with zero substrate doctrine drift.
| Already there (substrate + obs app) | New (the Console adds) |
|---|---|
| Substrate (Steps 0–4) | Developer Portal as a dogfooded vibe app |
| Obs app (Step 4.5) — the first reference vibe app | SDK Registry (CodeArtifact + versioned packages) |
| Data governance grid (Step 4.5.a) | App Registry (DDB-backed) |
| Three-layer defense (Step 4.5.b) | App Review PR template + CI contract validation |
| Cognito + TOTP per app (obs app pattern) | Identity Center SSO federation (Phase B with the DNS administrator) |
| MODULES.md SDK roadmap (specs, not code) | Static analysis enforcing the 5 SDK contracts |
| Four-layer DB boundary (Step 3) | SDK-published lockbox/reveal.ts wrapping the reveal Lambda |
| NFW + DNS Firewall + SoR allowlist | SDK-published sor/{salesforce,monday,github,gitbook}.ts helpers |
| Daily Bedrock narrative (obs app) | Per-app daily narrative + cross-app anomaly surfacing |
The right read: the Console doesn't add new substrate constraints. It re-expresses the constraints the substrate already enforces, but in a form the vibe-app developer consumes naturally. Every Console feature has a substrate anchor. Nothing is conjured.
This step encodes five doctrines specific to the Console layer, all of them extensions of substrate doctrines already pinned.
And the unifying meta-doctrine from earlier substepping:
"Expand the boundary, never weaken it." The Console is one more enforcement boundary, not a relaxation of existing ones. Every Console capability is additive. Where it appears to relax a substrate constraint (e.g., "developer doesn't have to think about KMS key choice"), it's because the SDK pre-decided the substrate-correct answer and made it the default. The constraint is enforced; the developer is shielded from having to enforce it themselves.
sor/* helpers depend on the NFW allowlist; Step 5 makes the allowlist enforced rather than advisory.The 60-day plan promised: "At day 60, we don't have a bigger system. We have a hardened one — and three teams that can't imagine going back." The Console is the mechanism by which the three teams can't imagine going back — because shipping a vibe app on this platform is faster, safer, and more observable than the alternative. The Console is what makes Phase 02 (Module & Abstraction Library) real instead of aspirational, and what makes Phase 03 (Three Vibe App POCs) compound instead of repeat.