# Token Factory Readiness Backlog v1

Status: draft execution backlog
Owner: Platform Architecture / Token Factory
Last updated: 2026-06-02

## Purpose

Define the future work that shared platform services must be ready to support
when Token Factory becomes an active product build.

This is not today's implementation plan for Token Factory. It is a readiness
backlog that turns expected Token Factory needs into concrete platform
contracts, gaps, and sequencing so the later product build is easier and does
not rediscover shared-service gaps.

This backlog follows:

- `Token_Factory_Readiness_Decision_Packet_v1.md`;
- `../Token_Factory_Gateway_Product_Model_v1.md`;
- `IAM_Department_Layer_Readiness_v1.md`;
- `../Unified_IAM_Billing_Across_Products_v1.md`;
- `../platform-foundation/Product_Onboarding_Checklist_v1.md`;
- `../platform-foundation/Platform_Architecture_Gap_Register_v1.md`.

## Current Scope

Current work is platform/shared-service readiness. Do not start Token Factory
product implementation from this backlog unless Token Factory is explicitly
activated as a product track.

Today, use this backlog to:

1. keep future product needs visible in Fairway;
2. map readiness areas to existing canonical docs and existing queue tasks;
3. close shared-service gaps that also benefit GPUaaS, App Platform, and future
   products;
4. avoid building Token Factory-only IAM, billing, policy, API-key, secret, or
   evidence paths.

## Source Reconciliation Map

Before creating new docs or implementation tasks, use the existing source docs
and queue tasks below.

| Readiness area | Existing source docs | Existing queue/task anchor | Fairway readiness task | Do not duplicate |
|---|---|---|---|---|
| Department layer | `../Unified_IAM_Billing_Across_Products_v1.md`; `IAM_Department_Layer_Readiness_v1.md`; `../Tenant_Project_Ownership_Baseline.md` | `A-IAM-DEPARTMENTS-SCHEMA-001` | `PSSM-R6-DEPARTMENT-LAYER-READINESS-001` | Do not create recursive org hierarchy or Token Factory-only `department_id`. |
| Product scopes and API keys | `../Unified_IAM_Billing_Across_Products_v1.md`; `../Platform_IAM_Model_v1.md`; `../Service_Account_Model.md`; `../Platform_Access_Credential_Model_v1.md` | `A-IAM-MULTIPRODUCT-SCOPE-REGISTRY-001`; `B-UX-UNIFIED-API-KEYS-SERVICE-ACCOUNTS-001` | `PSSM-R6-SCOPE-KEY-READMODEL-READINESS-001`; `PSSM-R6-UNIFIED-API-KEY-UX-READINESS-001` | Do not create separate product key types or scope strings outside the platform registry. |
| Usage units and rating | `../Unified_IAM_Billing_Across_Products_v1.md`; `../Billing_Platform_Overhaul_v1.md`; `../Billing_Current_State_Gap_Matrix_v1.md`; `../Billing_Architectural_Invariants_v1.md` | `A-BILLING-MULTIPRODUCT-USAGE-UNITS-001` | `PSSM-R6-USAGE-RATING-READINESS-001` | Do not mutate ledger entries from product request paths or hardcode unregistered usage units. |
| Gateway decision | `../API_Gateway_Evaluation_v1.md`; `../Token_Factory_Gateway_Product_Model_v1.md`; `Token_Factory_Readiness_Decision_Packet_v1.md` | `D-TOKEN-FACTORY-GATEWAY-ADR-001` | `PSSM-R6-GATEWAY-ADR-READINESS-001` | Do not put a generic gateway in front of GPUaaS platform APIs or replace Pomerium authority. |
| Secrets and key custody | `../platform-foundation/Secrets_PKI_Runtime_Trust_Model_v1.md`; `../Platform_Vault_Secrets_Baseline_v1.md`; `../../operations/runbooks/Key_Rotation_and_Compromise_Response_Runbook.md`; `../../operations/runbooks/Vault_Bootstrap_and_Root_Token_Runbook.md` | `Agent_Work_Queue.yaml` Vault-backed secrets baseline task; operations key-rotation runbooks | `PSSM-R6-SECRETS-CUSTODY-READINESS-001` | Do not store raw API keys, gateway credentials, provider credentials, or long-lived bearer secrets in product config/read models. |
| Analytics boundary | `../Data_Tiering_and_Database_Operations_Work_Plan_v1.md`; `../platform-foundation/Platform_Architecture_Gap_Register_v1.md`; `../Unified_IAM_Billing_Across_Products_v1.md` | `OD-012`; M3 in the gap register | `PSSM-R6-ANALYTICS-BOUNDARY-READINESS-001` | Do not build high-volume request/token dashboards on hot OLTP tables. |
| Release evidence | `../platform-foundation/Platform_Evidence_Status_Slice_v1.md`; `../../operations/Platform_Control_CI_CD_Target_Model_v1.md`; `../../operations/GPUaaS_Security_CD_Current_State_Gap_Roadmap_v1.md`; `../platform-foundation/Product_Onboarding_Checklist_v1.md` | M11/M17 in the gap register; platform-control evidence tasks | `PSSM-R6-RELEASE-EVIDENCE-PRODUCT-PROOF-001` | Do not treat CI pass/fail alone as product readiness; prove named IAM, billing, policy, runtime, portal, and rollback invariants. |

## Scope And API-Key Readiness Contract

This readiness work maps to existing queue task
`A-IAM-MULTIPRODUCT-SCOPE-REGISTRY-001` and future Fairway task
`PSSM-R6-SCOPE-KEY-READMODEL-READINESS-001`.

| Boundary | Required future output | Source of truth |
|---|---|---|
| Scope grammar | `<product>:<resource>:<verb>` registered as platform data | `../Unified_IAM_Billing_Across_Products_v1.md` |
| Service-account identity | project-scoped machine identity with org and project context | `../Service_Account_Model.md`; `../Platform_IAM_Model_v1.md` |
| API-key shape | scope-bearing service-account credential with expiry, lifecycle, rotation, revocation, labels, and audit | `../Unified_IAM_Billing_Across_Products_v1.md`; `../Platform_Access_Credential_Model_v1.md` |
| Registry snapshot | issued key records snapshot granted product scopes and scope registry version | `../platform-foundation/Platform_Registry_Contract_v1.md`; `../Unified_IAM_Billing_Across_Products_v1.md` |
| Runtime read model | product gateway or app runtime can read key validity, scopes, revocation, project, department, and policy hints without owning IAM tables | `packages/platform/iam`; `packages/platform/auth` |
| UX/portal | product-specific entry points call the same IAM contract and cannot mint parallel credential types | `../../product/UX_Implementation_Spec.md`; `../../product/UX_Journeys.md` |

Non-goals for current readiness:

- no Token Factory-only API-key table;
- no separate GPUaaS and Token Factory key types;
- no product code inventing unregistered scope strings;
- no long-lived perpetual keys as the default;
- no raw key material in read models, portal pages, logs, traces, or evidence.

## Usage And Rating Readiness Contract

This readiness work maps to existing queue task
`A-BILLING-MULTIPRODUCT-USAGE-UNITS-001` and future Fairway task
`PSSM-R6-USAGE-RATING-READINESS-001`.

| Boundary | Required future output | Source of truth |
|---|---|---|
| Usage units | registered `request`, `token_input`, `token_output`, and `cached_token` units with version evidence | `../Unified_IAM_Billing_Across_Products_v1.md`; `../Billing_Platform_Overhaul_v1.md` |
| Accepted usage event | append-only/replayable event or ingestion input carrying org, department, project, product, actor/key, resource/model, unit, quantity, version, pricing snapshot reference, and correlation ID | `../../api/asyncapi.draft.yaml`; `../Unified_IAM_Billing_Across_Products_v1.md` |
| Rating boundary | rating converts accepted usage into priced line items; product request paths never write ledger entries | `../Billing_Platform_Overhaul_v1.md`; `../Billing_Architectural_Invariants_v1.md` |
| Ledger boundary | ledger posting remains append-only and platform billing-owned | `../Billing_Architectural_Invariants_v1.md`; `../Billing_Current_State_Gap_Matrix_v1.md` |
| Reconciliation | gateway/backend/reported/rated/ledger counts must be reconcilable before high-volume production traffic | `Token_Factory_Readiness_Decision_Packet_v1.md`; `../platform-foundation/Platform_Architecture_Gap_Register_v1.md` |
| Evidence | release evidence captures usage ingestion health, rating lag, reconciliation drift, and ledger posting posture | `../platform-foundation/Platform_Evidence_Status_Slice_v1.md` |

Non-goals for current readiness:

- no Token Factory metering implementation today;
- no product request path ledger mutation;
- no invoice rendering or customer-facing token analytics dashboard;
- no unregistered usage units or mutable historical pricing reinterpretation;
- no hot OLTP dashboard path for high-volume request/token analytics.

## Gateway ADR Readiness Contract

This readiness work maps to existing queue task
`D-TOKEN-FACTORY-GATEWAY-ADR-001` and future Fairway task
`PSSM-R6-GATEWAY-ADR-READINESS-001`.

The future ADR should decide between Envoy-direct, Kong, Tyk, or another
candidate only after the platform contracts below are ready enough to evaluate
the gateway as a product component, not as a replacement platform edge.

| Boundary | Required future output | Source of truth |
|---|---|---|
| Edge placement | gateway sits below Pomerium/managed ingress and does not front GPUaaS platform APIs | `../API_Gateway_Evaluation_v1.md`; `../Token_Factory_Gateway_Product_Model_v1.md` |
| Identity handoff | trusted route identity, tenant/project context, API-key principal, and correlation context are preserved from edge to gateway | `../API_Gateway_Evaluation_v1.md`; `../Platform_Proxy_OSS_Data_Plane_ADR_v1.md` |
| Product control plane | model routing, per-model policy, request streaming, and usage capture are product-owned | `../Token_Factory_Gateway_Product_Model_v1.md` |
| Platform contracts | IAM scopes/revocation, billing usage/rating, policy/budget, evidence/status, registry, and secrets are consumed through platform services | `../platform-foundation/Platform_Shared_Services_Model_v2.md` |
| Spike criteria | future spike proves authz, fail-closed limit behavior, streaming, usage capture, status/evidence, and fallback criteria | `Token_Factory_Readiness_Decision_Packet_v1.md` |

Non-goals for current readiness:

- no gateway deployment today;
- no Token Factory API implementation today;
- no generic API gateway in front of `cmd/api`;
- no moving IAM, billing, or ledger authority into the gateway;
- no ADR closure until the future spike criteria can be tested.

## Unified API-Key UX Readiness Contract

This readiness work maps to existing queue task
`B-UX-UNIFIED-API-KEYS-SERVICE-ACCOUNTS-001` and future Fairway task
`PSSM-R6-UNIFIED-API-KEY-UX-READINESS-001`.

| Boundary | Required future output | Source of truth |
|---|---|---|
| IA placement | one account/access surface for service accounts and API keys across products | `../../product/UX_Implementation_Spec.md`; `../../product/UX_Journeys.md` |
| Creation flow | user selects project, with department resolved from the project; enterprise UX may expose department filtering when multiple departments exist | `../Unified_IAM_Billing_Across_Products_v1.md`; `../Service_Account_Model.md` |
| Credential reveal | raw key material is shown once at creation; later surfaces show fingerprint, key id, labels, lifecycle, last-used, and audit evidence | `../Platform_Access_Credential_Model_v1.md`; `../Service_Account_Model.md` |
| Scope display | scopes render as product/resource/verb with product-friendly descriptions and no provider internals | `../Unified_IAM_Billing_Across_Products_v1.md`; `../platform-foundation/Platform_Registry_Contract_v1.md` |
| Portal docs | developer portal explains key creation, SDK examples, curl/OpenAI SDK usage, rotation, revocation, and failure behavior | `../../PORTAL_SYNC.md`; `../../product/GPUaaS_Documentation_and_Developer_Portal_Docusaurus_v1.md` |

Non-goals for current readiness:

- no product-specific key page;
- no raw credential redisplay;
- no embedded gateway internals in the UX;
- no public API playground until API-key custody and mock/live target rules are decided.

## Secrets And Key Custody Readiness Contract

This readiness work maps to future Fairway task
`PSSM-R6-SECRETS-CUSTODY-READINESS-001`.

| Boundary | Required future output | Source of truth |
|---|---|---|
| Custody tiers | distinguish API-key hashes, encrypted private key material, gateway signing material, provider credentials, and operational bootstrap secrets | `../platform-foundation/Secrets_PKI_Runtime_Trust_Model_v1.md`; `../Platform_Vault_Secrets_Baseline_v1.md` |
| One-time reveal | API keys and generated secrets are returned only at creation and never stored in portal/read-model text | `../Service_Account_Model.md`; `../Platform_Access_Credential_Model_v1.md` |
| Rotation/revocation | rotation cadence, immediate revocation, audit, and evidence are policy-driven | `../../operations/runbooks/Key_Rotation_and_Compromise_Response_Runbook.md` |
| Runtime delivery | gateway/product runtimes receive secrets by reference or short-lived delivery path, not checked-in config | `../platform-foundation/Secrets_PKI_Runtime_Trust_Model_v1.md`; `../../operations/runbooks/Vault_Bootstrap_and_Root_Token_Runbook.md` |
| Evidence | release evidence proves custody posture, rotation status, and no raw-secret leakage in logs, traces, portal, or exported evidence | `../platform-foundation/Platform_Evidence_Status_Slice_v1.md` |

Non-goals for current readiness:

- no new gateway secret today;
- no raw provider credentials in product config;
- no long-lived bearer secrets in app manifests;
- no broad Vault replacement work beyond the documented coordination layer.

## Analytics Boundary Readiness Contract

This readiness work maps to `OD-012`, M3 in the gap register, and future
Fairway task `PSSM-R6-ANALYTICS-BOUNDARY-READINESS-001`.

| Boundary | Required future output | Source of truth |
|---|---|---|
| Hot OLTP | accepted usage, rating input, ledger references, and reconciliation anchors stay transactional and append-only | `../Data_Tiering_and_Database_Operations_Work_Plan_v1.md`; `../Billing_Platform_Overhaul_v1.md` |
| Rollups | high-volume request/token dashboards read from rollup, warehouse, or summary paths, not raw hot tables | `../Data_Tiering_and_Database_Operations_Work_Plan_v1.md`; `../platform-foundation/Platform_Architecture_Gap_Register_v1.md` |
| Dimensions | rollups preserve organization, department, project, product, model/resource, key, unit, version, and pricing context | `../Unified_IAM_Billing_Across_Products_v1.md` |
| Reconciliation | raw accepted, backend-reported, rated, and ledger-posted counts can be compared by correlation and time window | `Token_Factory_Readiness_Decision_Packet_v1.md` |
| Retention | raw usage compaction waits for rating, invoice/reconciliation, dispute window, audit review, and PII minimization gates | `../Billing_Current_State_Gap_Matrix_v1.md`; `../Data_Tiering_and_Database_Operations_Work_Plan_v1.md` |

Non-goals for current readiness:

- no analytics dashboard implementation today;
- no data warehouse selection today;
- no raw-token telemetry in read models;
- no direct product joins against billing/IAM source tables.

## Release Evidence Readiness Contract

This readiness work maps to M11/M17 and future Fairway task
`PSSM-R6-RELEASE-EVIDENCE-PRODUCT-PROOF-001`.

| Boundary | Required future output | Source of truth |
|---|---|---|
| Product invariant evidence | release packet proves IAM scopes/keys, policy deny, accepted usage, rating/ledger posture, runtime health, portal docs, rollback, and residual risk | `../platform-foundation/Product_Onboarding_Checklist_v1.md`; `../platform-foundation/Platform_Evidence_Status_Slice_v1.md` |
| Environment profile | evidence is tied to profile, host/route/cert posture, component versions, and deployment artifact versions | `../../operations/Platform_Control_CI_CD_Target_Model_v1.md`; `../platform-foundation/Platform_Shared_Services_Completion_Roadmap_v1.md` |
| Security posture | release packet includes scan status, secret custody posture, authz failure evidence, audit evidence, and exception expiry | `../../operations/GPUaaS_Security_CD_Current_State_Gap_Roadmap_v1.md` |
| UAT proof | UAT proves product invariants, not only page load or command completion | `../platform-foundation/Platform_Evidence_Input_Mapping_v1.md`; `../platform-foundation/Platform_Evidence_Status_Slice_v1.md` |
| Fairway integration | queue task evidence links commands, artifacts, guard reports, reviews, and handoffs into release evidence | `.fairway/platform-foundation-implementation-track.yaml` |

Non-goals for current readiness:

- no production exposure without named product invariants;
- no “CI passed” as the sole release signal;
- no untracked manual exception without owner and expiry;
- no demo environment mutation for this readiness work.

## Future Completion Target

Token Factory is considered onboarded when it can prove a managed-inference
request path through platform-owned shared services without rebuilding those
services inside the product.

Minimum proof:

1. API client calls a Token Factory endpoint through Pomerium plus product
   gateway without browser redirect.
2. IAM validates API key/service-account identity, project scope, and product
   scopes.
3. Gateway enforces per-key/per-model rate limits and fail-closed policy.
4. Gateway records durable accepted usage before returning successful
   completion.
5. Billing rates accepted usage asynchronously and creates immutable ledger
   impact only through platform billing paths.
6. Audit/Evidence records deny decisions, accepted-usage health, release gates,
   and reconciliation drift.
7. Status/Ops exposes gateway, model backend, usage-ingestion, and drift
   posture.
8. Developer portal has API contract, key flow, examples, and playground
   direction.

## Future Workstream Sequence

| Phase | Workstream | Goal | Depends on |
|---|---|---|---|
| T0 | Decision closure | Convert `OD-004/005/006` packet into bounded spike and final ADR criteria | PSSM L5 decision packet |
| T1 | Product onboarding map | Define ownership maps, route families, package target, tables, events, workers, frontend/portal surfaces | T0 |
| T2 | Contract-first API | Draft OpenAI-compatible external API, internal gateway control API, usage event contract, and error/failure contract | T1 |
| T3 | Gateway spike | Prove Envoy-direct plus thin control-plane path or reject it in favor of Kong/Tyk | T2 |
| T4 | Platform service integration | IAM scopes/keys, Billing usage units, Audit/Evidence, Status/Ops, Registry, Policy, Secrets | T2/T3 |
| T5 | Runtime/model router | Stub model backend first, then model-router contract and backend health evidence | T3 |
| T6 | Analytics/reconciliation | OLTP/OLAP boundary, usage reconciliation, drift evidence, dashboard data contract | T4 |
| T7 | Portal/release proof | Developer portal/API reference, UAT smoke, release evidence, runbooks, security review | T4/T5/T6 |

## Future Fairway Task Seed

These tasks should be imported or added only when the Token Factory track
starts. They are intentionally kept out of the current PSSM implementation
queue. IDs are product-scoped so they can live independently when the future
track begins.

| ID | Role | Kind | Dependencies | Output |
|---|---|---|---|---|
| `TF-EPIC-READINESS-TO-ONBOARDING` | orchestrator | epic | `PSSM-L5-REMAINING-GAPS` | future Token Factory product onboarding track |
| `TF-T0-GATEWAY-ADR-SPIKE-PLAN` | architecture | architecture-map | `TF-READINESS-DECISION-PACKET-001` | final spike plan for Envoy/Kong/Tyk decision |
| `TF-T1-OWNERSHIP-MAPS` | architecture | architecture-map | `TF-T0-GATEWAY-ADR-SPIKE-PLAN` | package/route/schema/event/worker/frontend ownership maps |
| `TF-T1-PRODUCT-REGISTRY` | governance | architecture-map | `TF-T1-OWNERSHIP-MAPS` | product registry entry, product scopes, usage units, audit actions, notification/evidence types |
| `TF-T2-OPENAI-CONTRACT` | backend | task | `TF-T1-OWNERSHIP-MAPS` | OpenAI-compatible API contract fragment and error contract |
| `TF-T2-USAGE-EVENT-CONTRACT` | backend | task | `TF-T1-PRODUCT-REGISTRY` | accepted-usage event and reconciliation event contract |
| `TF-T3-ENVOY-DIRECT-SPIKE` | backend | spike | `TF-T2-OPENAI-CONTRACT`, `TF-T2-USAGE-EVENT-CONTRACT` | gateway spike with authz, streaming, metering, and correlation evidence |
| `TF-T3-KONG-TYK-FALLBACK-EVAL` | architecture | spike | `TF-T3-ENVOY-DIRECT-SPIKE` | explicit fallback decision if Envoy-direct fails criteria |
| `TF-T4-IAM-KEY-SCOPE-READMODEL` | backend | task | `TF-T1-PRODUCT-REGISTRY` | API-key/service-account scope and revocation read model |
| `TF-T4-IAM-DEPARTMENT-READINESS` | architecture | architecture-map | `TF-T4-IAM-KEY-SCOPE-READMODEL` | department-layer readiness and production closure plan for the fixed org -> department -> project model |
| `TF-T4-BILLING-USAGE-RATING` | backend | task | `TF-T2-USAGE-EVENT-CONTRACT` | token/request usage units, rating path, ledger-safe ingestion |
| `TF-T4-AUDIT-EVIDENCE-STATUS` | backend | task | `TF-T2-USAGE-EVENT-CONTRACT` | deny audit, accepted-usage evidence, Status/Ops component rows |
| `TF-T4-POLICY-QUOTA` | backend | task | `TF-T1-PRODUCT-REGISTRY` | per-key/model/tier limit policy and budget-state contract |
| `TF-T4-SECRETS-KEY-CUSTODY` | security | task | `TF-T4-IAM-KEY-SCOPE-READMODEL` | API-key/gateway secret custody and rotation model |
| `TF-T5-MODEL-ROUTER-CONTRACT` | backend | task | `TF-T3-ENVOY-DIRECT-SPIKE` | model registry, endpoint health, routing policy, runtime placement evidence |
| `TF-T6-ANALYTICS-OLAP-BOUNDARY` | architecture | architecture-map | `TF-T4-BILLING-USAGE-RATING` | OLTP/OLAP split, rollup/warehouse event plan, dashboard read model |
| `TF-T6-RECONCILIATION-DRIFT` | backend | task | `TF-T4-BILLING-USAGE-RATING`, `TF-T5-MODEL-ROUTER-CONTRACT` | gateway/backend/rated/ledger drift detection and correction path |
| `TF-T7-DEVELOPER-PORTAL` | frontend | frontend-contract | `TF-T2-OPENAI-CONTRACT` | portal path for API keys, examples, API reference, playground decision |
| `TF-T7-UAT-RELEASE-EVIDENCE` | ops | release-evidence | `TF-T3-ENVOY-DIRECT-SPIKE`, `TF-T4-AUDIT-EVIDENCE-STATUS` | UAT smoke, security evidence, runbook, release gate packet |

## Platform Readiness Gap Map

| Gap / OD | Closure path |
|---|---|
| `OD-004` | `TF-T4-POLICY-QUOTA` plus gateway spike evidence |
| `OD-005` | `TF-T0-GATEWAY-ADR-SPIKE-PLAN`, `TF-T3-ENVOY-DIRECT-SPIKE`, and fallback eval |
| `OD-006` | `TF-T2-USAGE-EVENT-CONTRACT`, `TF-T4-BILLING-USAGE-RATING`, `TF-T6-RECONCILIATION-DRIFT` |
| `M2` | registry/version fields in product scopes, usage units, accepted-usage events, audit/evidence types |
| `M3` | `TF-T6-ANALYTICS-OLAP-BOUNDARY` |
| `M4` | `TF-T4-POLICY-QUOTA` |
| `M5` | model capacity reservation added after model-router contract; defer if stub backend only |
| `M8` | `TF-T4-SECRETS-KEY-CUSTODY` |
| IAM department layer | `TF-T4-IAM-DEPARTMENT-READINESS`; future production follow-ups `IAM-DEPARTMENT-*` |
| `M11` | `TF-T7-UAT-RELEASE-EVIDENCE` |
| `M12` | `TF-T5-MODEL-ROUTER-CONTRACT` plus runtime cleanup/quarantine evidence |
| `M19` | `TF-T1-PRODUCT-REGISTRY` and product onboarding checklist exit criteria |

## Future First Implementation Boundary

Do not begin by creating a large `packages/products/tokenfactory` tree.

The future product track should start with:

1. product onboarding map;
2. OpenAI-compatible API contract;
3. accepted-usage event contract;
4. gateway spike with stub backend.

When that future spike starts, it may use the current single-org/project IAM
model. Future production Token Factory must close
`IAM_Department_Layer_Readiness_v1.md` department-layer follow-up tasks before
department/cost-center budgets, department-scoped delegation, or
department-level analytics are exposed.

Only after the spike passes should code expand into durable product packages.
This keeps the work consistent with the PSSM rule: maps first, guard visibility
second, facade/product implementation third.

## Current Non-Goals

- No Token Factory product implementation today.
- No Token Factory gateway code today.
- No `packages/products/tokenfactory` tree today.
- No generic gateway in front of GPUaaS platform APIs.
- No direct ledger mutation from Token Factory gateway request handlers.
- No customer-facing analytics dashboard before OLTP/OLAP boundary is defined.
- No external launch until API-key custody, portal, security review, and release
  evidence gates pass.
- No model runtime placement dependency on GPUaaS allocations for the first
  gateway proof; use a stub or explicitly provisioned model endpoint.

## Future Checkpoint

After `TF-T3-ENVOY-DIRECT-SPIKE`, stop and decide:

1. keep Envoy-direct and proceed to platform-service integration;
2. switch to Kong/Tyk because first-release API-management requirements exceed
   the thin-control-plane model;
3. defer Token Factory if model-router/runtime ownership is not ready.