Technical enablement · 03

Feature reference

A catalogue of what {{product.name}} does. Every entry follows the same structure — what it does, how it works, how it's built and how it's linked — so you can read across the product consistently. Filter by domain or search, and click any entry to expand it.

ⓘ

Status. Everything listed here is in the product repository and deployed to the Azure instance, unless an entry says otherwise. Formula parameters, thresholds and calibration values are protected and are intentionally not given here.

Govern

The diagnostic surface: what was spent on AI, on what, and how much of the picture the platform can actually see.

What it does
Shows total AI spend for a chosen period with a coverage badge beside it, then breaks it down by provider, workload, model family, pricing model and resource group. Unattributed spend is shown as its own ranked item and is never redistributed.
How it works
Reads the authoritative billing stream. Periods are URL parameters (?period=YYYY-MM, thirteen months by default), and the trend can be viewed by day, week or month. Sub-penny amounts display as "< £0.01" rather than zero. Estimated (non-invoice) cost is called out above the figures, not in a footnote.
How it's built
lib/db/repositories/govern.ts, lib/domain/baseline.ts; components in components/govern/. Decisions in ADR 008.
How it's linked
Depends on active connections. Feeds checkpoints G1 and G2 and the Diagnostic export.
What it does
Surfaces findings a provider console does not: cache underuse, retry and failure spend, oversized models for the task, context growth, gateway bypass, provisioned-capacity underuse, abandoned workloads and agentic loop spend.
How it works
Each driver is a pure function. A driver that has too little data returns "insufficient data" with a reason rather than a zero. Addressable amounts are marked as inferred until validated with the client. Cached share is measured against all input tokens.
How it's built
computeAllDrivers registers every driver; page at govern/drivers; tests in tests/domain/govern-drivers.test.ts.
How it's linked
Drivers feed the opportunity list and, from there, Optimise.
What it does
States what share of AI spend the platform can see and reconcile against a named source, lists the named gaps, and shows open discrepancies by class and age.
How it works
The reconcile job compares real-time aggregates with billing, classifies differences and recomputes the completeness score. Below 100 per cent means a named gap exists. Applications that bypass the gateway are a named gap, not a silent one.
How it's built
lib/tdal/reconcile.ts, lib/domain/discrepancy-labels.ts, components/govern/CoverageBadge.tsx.
How it's linked
Coverage caps checkpoint confidence and CPVO state. Gate G1 asks whether scope is sufficient.
What it does
The Diagnostic deliverable: ranked findings, each with evidence, an inferred addressable amount, implementation difficulty and who has to act (client, Capgemini or platform).
How it works
Built from the drivers. Unattributed spend is never named as a workload in a finding. A finding can be turned into an Optimise recommendation.
How it's built
lib/domain/recommendation-from-opportunity.ts; tests govern-opportunities.test.ts.
How it's linked
Feeds Optimise recommendations and the Govern export.

Attribute

Turns spend into unit economics: cost per verified outcome and, where a baseline exists, verified yield.

What it does
Assigns each workload a risk tier (T1 to T4) with rationale and approver, and shows the oversight policy per tier. This is the artefact checkpoint G3 accepts.
How it works
Client mode shows the policy in words and the resulting checkpoint frequency; the parameters column is omitted entirely. Each change is versioned and recorded in the audit log.
How it's built
oversight_config table; lib/domain/oversight-params.ts; the page checks the viewer's role on the server before rendering protected columns (ADR 008).
How it's linked
Tier assignments drive oversight economics and Optimise approvals.
What it does
Lets a workload and its outcome definition be authored in the product: what one outcome is, how it is verified, what it is worth and on what basis. Both the client owner and the Capgemini engagement lead countersign (checkpoint G4). A later change creates a new version.
How it works
Nothing is computed for a workload until its definition is signed. Gateway traffic that arrives without a workload is listed above the workload list, biggest estimated spend first, and a key can be named there; stored events are backfilled in the same action.
How it's built
lib/db/repositories/workloads.ts, lib/domain/definition-state.ts, components/attribute/definition-forms.tsx, gateway-key-adopt.tsx.
How it's linked
Prerequisite for CPVO. Outcome events arrive through /api/ingest/outcomes.
What it does
Computes cost per verified outcome for each workload and period, with cost composition and a provenance view of every input.
How it works
Six explicit states: OK, LOW_CONFIDENCE, COVERAGE_CAVEAT, RECONCILIATION_PENDING, NOT_ATTRIBUTABLE and NO_OUTCOMES. For any state other than OK there is no number, only the blocking reason. It reads only the authoritative billing stream. Each recompute appends a new immutable run.
How it's built
Engine in lib/jobs/recompute-engine.ts; ADR 009; test tests/domain/attribute-cpvo.test.ts.
How it's linked
Needs a signed definition and reconciled data. Feeds yield, the attribution report (G5) and AYCI.
What it does
Shows verified yield and yield ratio per workload, and net advantage against the alternative once a baseline is recorded.
How it works
Net advantage needs a recorded, signed baseline. Without one the page shows the ratio and says what baseline capture requires. Sensitivity to the outcome value is shown first because that input is the most challengeable.
How it's built
One shared implementation imported by both the recompute engine and the demo seed, so screens agree with stored runs.
How it's linked
Depends on CPVO; page attribute/yield.
What it does
Weighs the cost of human oversight against the errors it catches, per workload, at the bounds of the calibrated range. Recommendations are phrased as rebalancing, never as removal; the most critical tier carries a floor that overrides the arithmetic.
How it works
Internal mode shows the figures; client mode shows consequences in words. Parameters are held per tier.
How it's built
lib/domain/oversight-value.ts, oversight-params.ts, components/attribute/oversight-value-table.tsx.
How it's linked
Reads the active calibration set; depends on checkpoint history.
What it does
The G5 artefact: CPVO by workload with states intact, movement against the prior period, and AYCI with its four components. The spend view shows what each workload spent on, and divides a shared billing scope between the applications in it.
How it works
Movement is decomposed so that a CPVO that fell because coverage fell is not reported as an improvement. Shared scopes are divided by what the gateway observed; the remainder is shown as spend no application accounts for.
How it's built
lib/domain/trend.ts, lib/domain/run-economics.ts, lib/jobs/attribute-spend.ts.
How it's linked
Export route /api/export/attribute.

Agentic

Two mechanisms: Gate A refuses an agent session without an authorised budget, and Component 8 watches it in flight.

What it does
Authorises, reduces or refuses an agent session before its first model call. An unregistered workload is refused, which is how shadow agent deployments become visible.
How it works
The caller posts the workload, agent identity, requested budget and limits, and declared external actions. Policy is evaluated in a fixed order, with the kill switch and circuit breaker ahead of policy checks. Every decision writes an immutable gate_a_decision row with the request, outcome and evaluation trace, so a refusal can be explained without reading logs. In gateway-enforced mode the caller receives a scoped gateway key with a hard budget.
How it's built
ADR 010; authenticated with a bearer token; tests gate-a-auth.test.ts.
How it's linked
Requires the LiteLLM gateway for strong enforcement. Traffic that bypasses it is flagged.
What it does
Classifies every session GREEN, AMBER or RED and acts on it. AMBER pauses the session and starts a timed human decision; RED stops it.
How it works
Zone evaluation is a pure function over a signal snapshot. A session that bypassed Gate A, or agentic overage, goes straight to RED with no AMBER state and no L1 override. The browser follows over Server-Sent Events fed by Redis pub/sub. Repeated RED stops can trip a workload-level circuit breaker.
How it's built
SSE route app/api/agentic/sessions/[sessionId]/events; ADRs 003 and 010. Threshold values are protected.
How it's linked
AMBER decisions appear in the checkpoint console.
What it does
Policy sets per-workload ceilings and permitted actions; history is the audit trail of every session and refusal; economics shows cost per completed agent task and the share of agentic spend consumed by sessions that never completed.
How it works
Server-rendered pages with an export at /api/export/agentic.
How it's built
lib/db/repositories/agentic.ts.
How it's linked
Agentic cost feeds Attribute as a workload cost input.

Optimise

Turns findings into authorised, executed and measured changes.

What it does
Raises recommendations in eight categories (cache underuse, model routing, model right-sizing, batch conversion, SaaS consolidation, abandoned workload, provisioned underuse, other), then takes each through authorise, execute and measure.
How it works
Authorisation is checkpoint G6; nothing is executed before it. Savings carry the window they were estimated over, and notes can be recorded against a recommendation.
How it's built
Routes optimise, authorise, [id]/execute, [id]/measure; export /api/export/savings.
How it's linked
Starts from the opportunity list.
What it does
Shows, for each billing scope, how much of the invoice the instrumented applications account for, and the actionable remainder.
How it works
A scope's cost is the sum of the applications in it; the remainder is spend no application accounts for. Providers that bill one undivided organisation have no scope to name and report as "no grouping reported".
How it's built
lib/domain/gateway-key.ts, lib/db/repositories/gateway-keys.ts.
How it's linked
Depends on gateway telemetry; see gateway.

Checkpoints & delivery

The operating model that lets a generalist consultant run an engagement, with experts available for exceptions.

What it does
One console runs the seven gates, AMBER decisions and variance notices. Each checkpoint has a plain question, a platform finding with a confidence signal, two to four bounded options with consequences, an evidence panel, a visible time budget and an always-available escalation. Target: 20 minutes or less.
How it works
Options are generated server-side and recorded with the decision; there is no free-text decision. A checkpoint cannot skip the gates before it. Low confidence changes the option set (a remediate-first path is always offered) but does not block. The timer measures; it never auto-decides a gate. An option that promises caveats requires them to be written. See implementation flow for the gates.
How it's built
lib/domain/checkpoint-options.ts, confidence.ts, gate-guidance.ts, gate-progress.ts; components/checkpoints/CheckpointConsole.tsx.
How it's linked
Internal staff can open and decide any tenant's checkpoint. The queue filters by status, gate and engagement.
What it does
An inbox for L2 and L3 escalations with SLA clocks, sorted by breach risk. An escalation cannot be closed without a recorded decision and rationale.
How it works
L1 escalates with a reason from a defined list and the full context attached; L2 can route to L3 for calibration questions. Each escalation carries sla_target_seconds.
How it's built
listOpenEscalations in lib/db/repositories/checkpoints.ts is the source of truth for what is open; routes escalations/[id]/resolve, route-l3.
How it's linked
Capacity view at checkpoints/capacity shows two escalation-headcount scenarios side by side, never averaged.
What it does
Lets the capability owner prepare, publish and archive versioned parameter sets. A calibration can be prepared before it decides anything.
How it works
Every calculation run records the version it used, so recalibrating never rewrites history. Publication is audited.
How it's built
components/calibration/, lib/domain/calibration-params.ts.
How it's linked
Read by CPVO, oversight economics, AYCI and confidence.
What it does
Engagements lists the portfolio with each engagement's position in the G1 to G7 sequence and lets admins create, edit and delete engagements, workloads and connections. Admin manages users, role assignment and shows the login audit log.
How it works
Server actions with role checks; destructive actions sit in a danger zone component.
How it's built
lib/db/repositories/admin.ts, tenants.ts; scripts/seed-admin.ts creates the first admin.
How it's linked

Platform

Capabilities that cut across the modules.

What it does
Registers a named connection to a provider, verifies it, shows its granted scope, last sync and any provider error, and explains what credential is needed.
How it works
A connection starts disconnected; verification on save promotes it to active, and the Test connection button re-runs it. Credentials can be entered in the app and are encrypted at rest. See provider connections.
How it's built
lib/connections/, components/connections/.
How it's linked
The first thing a new engagement has to do; nothing downstream has data until one is active.
What it does
Every data view has an internal and a client projection, so staff can switch to client mode before a meeting and clients can never receive protected figures.
How it works
A mode badge in the top bar shows the active mode. Client roles are fixed to client mode. Projection happens on the server (ADR 004).
How it's built
components/nav/mode-toggle.tsx, mode-badge.tsx; tests in tests/ip-mode/.
How it's linked
Applies to pages, API responses, event streams and exports.
What it does
The workspace landing page: AYCI, coverage and headline figures. AYCI is a composite of coverage, attribution, verification and control, with a trend.
How it works
A snapshot is recorded only when the index changes. Component weights are protected.
How it's built
ayci.ts, ayci-bands.ts, /api/ayci, components/overview/ayci-trend-chart.tsx.
How it's linked
Computed by the recompute job.
What it does
Client-safe exports for Govern, Attribute, Agentic and savings.
How it works
Exports go through the same domain functions and mode projection as the screens. Govern exports are multi-section CSV with coverage in the first section; spreadsheet (XLSX) output is a named follow-on (ADR 008).
How it's built
Four route handlers under app/api/export/.
How it's linked
Each export states its coverage and carries an AI transparency line.
What it does
Seeds three synthetic tenants (a SaaS company, an insurer and an agentic-heavy technology company) that each show a different mix of states, zones and gaps. Demo tenants show a DEMO badge and are excluded from billing sync.
How it works
make seed-demo; safe to re-run because each tenant is deleted by slug and recreated. Billing and gateway data come from one derivation so the screens agree. Seeding a non-local database needs CONFIRM_PROD=1.
How it's built
Guarded by tests/seed/demo-narratives.test.ts.
How it's linked
Contains no real client data.

Roles

Defined in the role enum and enforced both in navigation and in each route. Internal roles are Capgemini staff; client roles are locked to client mode.

RoleKindAccess
platform_adminInternalFull platform access including admin, calibration and all engagements.
capability_ownerInternalEngagements, checkpoints, escalations and calibration.
expertInternalCheckpoints and escalations.
consultantInternalCheckpoints.
commercialInternalHome only.
client_adminClientClient workspace, administrative functions.
client_operatorClientClient workspace, operational functions.
client_viewerClientClient workspace, read-only.
ⓘ

No L1 role can override an agentic RED, approve a threshold change or approve a change to permitted external actions (design rule, verified by authorisation tests). Component descriptions are in the components catalogue.