Build with {{product.name}}
{{product.name}} technical enablement
Everything a technical person needs to implement and run {{product.name}} for, or on behalf of, a client. This portal is the engineering counterpart to the employee learning paths: how the product is built, the components that make it up, how to stand it up, how to deploy it, and how to connect it to a client's own systems.
Built from source. These pages were written from the product repository (README, runbook, ADRs, build brief, workflows and code layout). Where a fact is not in the repository it appears as a bracketed placeholder for the team to fill in. Planned work is labelled as roadmap, never as available.
Latest updates
2026-10-22 — Enablement portal published. The technical enablement portal now documents the architecture, components, features, deployment, integrations, operations and implementation flow. A second instance on AWS is in preparation and is not live.
The journey
The sections group into three phases: understand the system, implement it for a client, then extend and run it. Jump straight to any of them.
Explore the sections
Before you start
You don't need all of this on day one, but a full client implementation of {{product.name}} typically touches:
| Area | What you'll need |
|---|---|
| Environment | An Azure subscription with Container Apps, a container registry, PostgreSQL and Redis; a LiteLLM gateway; permission to create a managed identity. The live instance runs in North Europe; a dedicated stack would use the client's declared region. Creating the resources needs a resource-group level role such as Contributor. Role assignments (for example for the deploy identity) are restricted by an allow-list condition in the live subscription, so ask the subscription owner for those early. |
| Access | Repository access and GitHub Actions permissions; an Entra ID app registration for sign-in; read-only credentials for each AI provider account (see provider connections). |
| Client inputs | Provider accounts in scope, named workloads and their owners, outcome definitions and values to be signed, and the client-side prerequisites for AWS Bedrock (invocation logging) and Google Vertex AI (billing export). |
| Data | Token counts, costs, model and workload identifiers, and outcome-event metadata. No prompt or completion content is stored. Check with your Data Privacy Officer before connecting a real client. |
| Tooling | Node.js 20 or later, npm, Docker, the Azure CLI, make, and the GitHub CLI for pipeline set-up. |
How to use these docs
- The left rail moves between sections; the right rail ("on this page") jumps within one.
- Code blocks have a copy button; the feature reference has a filter + search.
- Paths and configuration keys are quoted from the repository so you can verify each claim against source.
Honesty note. Items marked Roadmap or design intent are not shipped. The AWS instance is not live. The access code on this portal is a deterrent, not authentication: do not publish confidential client information here, and note that formula parameters and thresholds are intentionally omitted.