The only per-client build. This page mirrors the client column of the architecture diagram, band for band:
the seven sections below are the same C1 to C7 you see there, in the same order. Each row is one value the client fills in. "Filled by" names the
Client Discovery section that gathers it; "Takes effect" says when a change lands. No code ever enters the plane; custom logic is built in the
Solution layer and selected here.
The seven bands: every value, in plain language
C1. Experience
| Value | What it sets | Filled by | Takes effect |
|---|
| Channel mix channel_mix | Which channels are switched on, per audience | G | Next output |
| House templates and branding house_templates | The client's document templates and visual identity | C | Next output |
| Output formats output_formats | PowerPoint, Word, Excel or PDF per document type | C | Next output |
| Tone and language tone_language | Writing style and language conventions | C | Next output |
| Notification rules notification_rules | What the platform may send proactively, and to whom | G | Immediately |
| Embedded surfaces embedded_surfaces | Which work tools the assistant appears inside | G | On config deploy |
| Locale conventions locale_conventions | Currency, date, number and language conventions per client | C | Next output |
| Telephony & voice setup telephony_config | Numbers, entry points, voices and the operator console for phone and call-center channels | G | On config deploy |
| Feedback capture scope feedback_scope | Which user corrections may be captured as eval signal, within the data-rights clause | I | Immediately |
C2. Solution
| Value | What it sets | Filled by | Takes effect |
|---|
| Use-case activation use_case_activation | Which agents and workflows are switched on | A | On deploy |
| Orchestration mode orchestration_mode | Serial or parallel per use case, and where checkpoints sit | A, F | Next run |
| Human review placement hitl_placement | Where people review before work advances | F | Next run |
| Custom workflow composition workflow_composition | Client-specific sequences built from reusable agents, never new code | F | Next run |
| Override and exception routing override_routing | How overrides are recorded and where exceptions go | F | Immediately |
C3. Knowledge
| Value | What it sets | Filled by | Takes effect |
|---|
| Ontology version pin ontology_version_pin | The exact Knowledge release this client reads | Set at kickoff; upgraded by release | Through a regression-gated release |
| Overlay selection overlay_selection | Which ontology overlay applies, such as growth equity | B | Through a regression-gated release |
| Stage and gate name mapping stage_gate_mapping | The client's own names for lifecycle stages and approval points | B | Next run |
| Benchmark scope and data rights data_rights_clause | What telemetry may ever reach the shared benchmark shelf | I | Contractual; reviewed at signature |
C4. Intelligence
| Value | What it sets | Filled by | Takes effect |
|---|
| Model tier preference model_tier | Which model tier each use case prefers | H | Next call |
| Cost ceilings cost_ceilings | Spend limits the model router enforces | H | Next call |
| Latency targets latency_targets | Which tasks must feel instant and which can run overnight | H | Next call |
| Approved vendor list approved_vendors | Which model vendors the client permits | E, H | On config deploy |
| Data sensitivity boundary model_data_boundary | Which data classes may reach which model tier and deployment type | E, H | On config deploy |
C5. Integration
| Value | What it sets | Filled by | Takes effect |
|---|
| Source system selection source_connectors | Which of the client's systems connect, from the connector library | D | On deploy |
| Credentials and OAuth grants credentials | How each connection authenticates; stored in the key vault | D, E | On deploy |
| Data contracts data_contracts | What each source promises to deliver, and what happens when it does not | D | On deploy |
| Field mappings field_mappings | The client's field names mapped to the platform taxonomy | D | Next sync |
| Sync schedules and modes sync_schedules | Real-time, daily or weekly, per source | D | Next sync |
C6. Data & Documents
| Value | What it sets | Filled by | Takes effect |
|---|
| Tenant store instances tenant_stores | The client's own stores, stamped from platform templates | Provisioned at setup | At provisioning |
| Source estate inventory source_estate | Their systems of record, VDRs, warehouses and feeds | D | Reference; updated as found |
| Document taxonomy mapping taxonomy_mapping | Their document types mapped to the ontology's taxonomy | C, D | Next ingestion |
| Data residency and regions data_residency | Where their data physically lives | E | At provisioning; changing it later is a migration |
| Retention and legal hold retention_policy | How long artifacts persist and how deletion works | E | Nightly lifecycle jobs; holds immediate |
C7. Environment
| Value | What it sets | Filled by | Takes effect |
|---|
| Tenancy and account mapping tenant_id | Which account or key boundary isolates this engagement | E, H | At provisioning |
| Identity provider idp_config | Entra, Okta or Google; how people sign in | E | On config deploy |
| Platform access endpoint north_gateway | The per-tenant address hosts connect to, and which hosts are allowed | G, E | On config deploy |
| Cloud platform cloud_platform | AWS, Azure or GCP; nothing above the harness changes with this | H | At setup; changing it later is a migration project |
| Token budgets token_budgets | Spend limits per use case, enforced every loop tick | H | Next run |
| Gate approvers and backups gate_approvers | Who approves at each gate, and who covers when they cannot | F | Next transition |
| Alerts and escalation timers escalation | Who gets paged, and how long an approval may wait | F, H | Immediately |