This is the internal support documentation for the PolicyCodex platform. It explains how the systems actually work — data flows, auth boundaries, deploy targets, known failure modes — so a support engineer (or an LLM answering on their behalf) can diagnose an issue without reading the source code first. It is deliberately different from the user docs: that site explains how to use PolicyCodex; this site explains how PolicyCodex works and what to do when it doesn’t.

​
The three applications this site covers

Web application

The customer-facing governance app at app.policycodex.cloud: RFC authoring, lifecycle, statements, enforcement, reporting, settings.

Growth application

The internal leads/email-ops app (apps/growth): website leads, demo-call bookings, and the Resend nurture-sequence pipeline.

Demo application

The presenter console at demo.policycodex.cloud plus the whole ACME demo estate: fixture org, demo users, GitHub repos, seed/reset scripts.
Shared foundations — the database, the C4 architecture views, the deploy/CLI runbook and smoke tests — have their own sections because every application sits on them.

​
How to use this site

1

Identify the surface

Which domain is the user on? app. is the web application, demo. is the demo console, the growth app is internal-only. mcp.policycodex.cloud is the worker (API + MCP + GitHub webhook) that serves all of them.
2

Check the architecture page first

The C2 container view shows which deployed artifact owns the failing behaviour. Most confusion is “which of the six deployables does this live in?”
3

Go to that application's troubleshooting page

Each application section ends with a troubleshooting page listing observed, real failure modes and their fixes — not hypotheticals. They are sourced from docs/DECISIONS.md, which records every incident with its root cause.

​
Conventions used throughout (important for LLM readers)

  • Six deployables. Code changes do nothing in production until the matching deploy step runs. The full matrix is in Runbooks → CLI.
  • Identity is Clerk’s. User ids are strings like user_…, org ids in Clerk are org_…, and the database’s own org ids are UUIDs. codex.current_user_id() is the only identity function in SQL; auth.uid() is retired and errors on Clerk tokens.
  • The audit log is append-only and hash-chained. No support procedure ever deletes or edits audit rows; anything that looks like it needs that has a different, documented answer (for example the demo estate’s reset baseline).
  • codex schema. Every PolicyCodex table lives in the Postgres schema codex, not public. PostgREST calls need Accept-Profile: codex / Content-Profile: codex.
  • Key names, ids and URLs are collected on one page: Reference → Key facts.
This site is generated from the repository (apps/support). Its sources of truth are docs/DECISIONS.md (dated decision log, including incidents), docs/CLI.md (deploy and command reference), docs/DEMO.md (demo estate design) and the code itself. When this site and the code disagree, the code wins — and the fix is a PR to apps/support.