Customers, Teams, and access

Three separate statuses, easy to conflate

Every registered organization carries three independent status fields. None of them derives from either of the others.

Customer relationship — an explicit, manually-set fact: is this a confirmed, signed customer, or a prospect / legacy / internal-test record? Never inferred from governance status, activation status, or work activity. Defaults to prospect for a newly-registered record.

Governance status — a manual, informational label on the customer's manifest. Not an automated process.

Activation status — a real, code-enforced gate system. Fully automated, re-evaluated fresh every time — never trusts its own stored label.

Customer relationship — why the Customers list can look empty

The Customers screen shows only records explicitly classified customer — this is deliberate, so the list reflects real signed relationships rather than every deployment record or demo/test artifact that happens to exist. Registering a new organization (via "New customer") does not make it appear here: it is created as prospect by default and stays invisible on this screen until someone explicitly reclassifies it.

Valid values: customer (confirmed, signed engagement), prospect (registered, not yet confirmed), unverified_legacy (a pre-existing record whose real status hasn't been confirmed), internal_test (demo/showcase data, never a real customer). An unclassified record (nothing set yet) is treated the same as excluded from the list, same as any non-customer value.

Use "Open an existing customer by ID" above to reach any registered record's detail/classification panel directly, regardless of its current relationship status -- the filtered Customers list below is not the only way in.

Classification is set/changed from a customer's detail view ("Customer relationship" panel) — a change there is a real, audited admin action, same authorization chain as every other mutation on this screen, not a cosmetic label.

Governance status

Valid values: draft → pending_review → approved / rejected.

Current platform policy: this must stay draft for every customer. This is a deliberate safety rail for this release, not an oversight or a step you're missing. Its only real runtime effect is gating the customer_mcp interface (requires approved) — and that interface isn't available to any customer yet (permitted_interfaces must stay exactly ["managed_service"]). There is no current process for moving a customer past draft; changing it without a corresponding platform policy decision will be flagged by the validator as circumventing a deliberate guard.

Activation status — the real process

Lifecycle: configured → blocked_<reason> → activation_ready → active. Computed fresh from the customer's own declared release_gates list and gate_evidence records every single time — a customer's stored status is only ever a cached label, never trusted proof.

Each customer declares which gates apply to it in team-config.json's release_gates list. Every gate needs real evidence before it passes:

• Specific gates (e.g. customer_requirements_complete, organizational_assessment_accepted, kinyarwanda_translation_approved, source_stored_in_tenant_secure_storage) read evidence directly from the customer's own manifest/team-config fields — a real resolved sponsor, a fully-populated assessment config, an approved translation with a named reviewer, and so on. What each one specifically requires is defined in release_gate_registry.py.
• Generic platform-control gates (the four wave9a_* gates, plus any other gate id with no specific checker) require an explicit sign-off record in team_config.gate_evidence[gate_id]: {"status": "proven", "proven_by": "...", "proven_at": "...", "evidence_ref": "..."}. A gate is never satisfied by its mere presence in release_gates, a comment, or the underlying platform capability existing in code — only a dated, attributed record that someone actually verified it for this specific customer.

Once every declared gate passes, the customer reaches activation_ready — reaching active itself still requires a separate, explicit, audited action (never automatic), which re-validates the gates one more time before flipping the status.

A customer's detail view has a Release gates panel: live pass/fail per declared gate, the current evidence record, a togglable attestation history, and — for generic-evidence gates only — Attest / Revoke controls. Attesting or revoking is Platform Owner only (a Managed Operator can still freely Activate once gates are proven; only vouching that a control is real is owner-only). Gates with a specific checker render read-only here, since writing gate_evidence for one would never actually change whether it passes.

Known limitation, by design, not a bug: revoking a gate's evidence for a deployment that has already reached active is rejected outright — the write is rolled back, nothing changes. Nothing in this platform today can move a deployment's activation_status off active at all (suspend/kill-switch is a separate, orthogonal system that never touches this field). If evidence proven for an already-active customer is later found invalid, there is currently no way to record that revocation against them — see the tracked follow-up for the full suspend/deactivate/revoke/reactivate lifecycle this will require.

CL Admins

Exactly one Platform Owner. Any number of Portal Admin (Managed Operator) identities — a Portal Admin cannot perform irreversible actions like permanent customer offboarding, and cannot grant or revoke anyone's Portal Admin access (enforced in code, not just convention). Platform Owner stays a one-time, out-of-band grant (a real Google sign-in capture script, run by the person being added); Portal Admin is granted from the People Directory tab's "Platform access" control, Platform-Owner-only.

Being a Portal Admin does not imply access to any specific customer's operational workspace, Assigned CL Team membership, or Leadership View — those are independently granted per person. It does carry platform-wide authority over the Admin Control Plane itself (inviting customer users, assigning CL Team members, reclassifying customers) for every customer, the same breadth a Managed Operator has always had.

Super Admin is a separate, independent authority (today: you) — it is never inferred from the Admin roster above, from a customer assignment, or from any other role, and is never settable from this screen. It grants audited cross-customer workspace access, shown as the "View Customer Workspace" action on a customer's detail view.

People Directory & Assigned CL Team

One internal workforce, one identity each. Add a person once in the People Directory tab (name, email, job functions); they start Invited until their real, verified Google identity id is linked, then become Active and eligible for customer work. From there, assign them to any customer under Customers → People & access → Assigned CL Team — a picker over the directory, never a hand-typed identity id.

Job functions describe responsibilities only — they grant no access by themselves. Platform access (Worker/Portal Admin), customer assignments, and Leadership View entitlement are three independent grants on the same person, each set separately.