During build
Weekly working review
Evaluation results, open risks, and decisions needed — reviewed with the workload owner and reviewers.
Six stages, five gates, a named decision at each.
Every engagement follows the same lifecycle. Each gate has written evidence requirements and named approvers, so the organization decides on facts.
Lifecycle
Six stages, each with a defined output.
Stages are sequential by default. A workload advances only when the gate's named approvers accept its evidence.
-
01
Assess
Map the workload with the people who do it today: inputs, steps, decisions, owners, failure modes, and what a correct result looks like.
OutputWorkload brief, data inventory, and feasibility assessment.Exit gateG1 Scope -
02
Define
Build the evaluation set with domain reviewers. Agree success thresholds, budgets, access scope, and the human gates that will apply.
OutputEvaluation set, success thresholds, cost model, and access plan.Exit gateG2 Ready to build -
03
Build
Implement context pipelines, orchestration, and tools in an isolated environment, iterating against the evaluation set rather than anecdotes.
OutputWorking system, an evaluation report per iteration, and adversarial test results.Exit gateG3 Ready to validate -
04
Validate
Shadow-run on real inputs alongside the current process. Reviewers compare outputs; Security & IT reviews access, data flows, and logging; runbooks, SLOs, and monitoring are prepared.
OutputValidation report with the shadow-run comparison and security review; runbooks, SLOs, and monitoring ready for release.Exit gateG4 Release -
05
Release
Staged rollout under approval gates and budgets, with runbooks, SLOs, monitoring, and escalation paths in force from the first production request.
OutputRollout record, live dashboards, and an escalation path.Entry gateG4 Release -
06
Operate & improve
Continuous evaluation, cost review, and controlled change for models, prompts, tools, and retrieval configuration.
OutputMonthly operating review covering quality, cost, reliability, and changes.Every change passesG5 Change
Governance
Clear roles, regular cadence.
Accountability for outcomes stays with the organization that owns the work. Our role is to design, build, and evaluate the system, to operate it where the engagement agreement assigns that role, and to report on it plainly.
| Role | Responsibilities | Decides |
|---|---|---|
| Workload owner | Defines the outcome, sponsors the evaluation set, accepts gate evidence. | Go / no-go at G1–G4; approval of material changes at G5 |
| Domain reviewers | Label evaluation data, review outputs, confirm or correct findings. | Whether an individual output is accepted |
| Security & IT | Approve access scopes, integrate identity and logging, review data flows. | Access grants and deployment model; co-approves G2 and G4 |
| FGGJTNBGNCR | Design, build, and evaluate the system; operate it where the agreement assigns that role; report quality, cost, and incidents. | Technical design within agreed constraints |
After release
Monthly operating review
Quality trends, cost against budget, reliability against SLOs, incidents, and proposed changes.
On change
Change control
Model, prompt, tool, or retrieval changes pass G5 Change — re-evaluated and recorded before they reach production traffic.
Quality gates
No gate passes on a demonstration.
Each gate specifies the evidence it requires and who signs off. Evidence is retained with the workload's records.
| Gate | Evidence required | Approver |
|---|---|---|
| G1 Scope | Workload brief, data inventory, identified owners and reviewers. | Workload owner |
| G2 Ready to build | Evaluation set, success thresholds, cost model, access plan. | Workload owner + Security & IT |
| G3 Ready to validate | Evaluation report at or above threshold; adversarial test results. | Workload owner |
| G4 Release | Shadow-run comparison, security review, runbooks, SLOs, monitoring. | Workload owner + Security & IT |
| G5 Change | Regression evaluation on the changed configuration; adversarial re-test for material changes; cost impact estimate. | Workload owner |
At each gate
What a gate decision rests on
Before a gate, the evidence listed for it is assembled in writing. Each named approver reviews that evidence, and the go / no-go decision is retained with the workload's records alongside it.
- Written evidence — the artifacts the gate lists, not a demonstration.
- Named approvers — identified before the gate, never assigned after the fact.
- A recorded outcome — go or no-go, kept with the evidence it was based on.
G4 Release · example/workload
Shadow-run comparisonreal inputs · reviewer comparison attached
Security & IT reviewaccess · data flows · logging · complete
Runbooks, SLOs & monitoringprepared · linked to workload record
Security & IT approvalco-approver · approved
Workload owner decisiongo / no-go · pending
Data handling
Your data is used for your workloads, on terms you approve in writing.
Data handling terms are agreed in writing before any data is accessed. These are the defaults we start from.
- Purpose limitation — client data is used only to run and evaluate that client's workloads.
- No training by default — no model training or fine-tuning on client data without a written agreement.
- Named model providers — every model provider and sub-processor that can receive client data is listed in the data-handling terms; model calls pass only through the governed gateway.
- Least-privilege connectors — read-only unless a workload requires writes, with access inherited from the source system.
- Encryption in transit and at rest, with keys managed in the environment chosen for the deployment.
- Secrets stay out of context — credentials are injected at tool execution, never placed in model prompts.
- Retention and deletion follow the agreed schedule, with written confirmation of deletion on request.
Responsible use
Commitments that hold in every engagement.
These commitments apply regardless of deployment model or engagement scope.
Human oversight
People decide consequential outcomes
Systems that affect people's credit, employment, health, or legal status are only built with qualified human decision-makers in the loop, and with a route for affected people to request human review.
Transparency
Outputs are labeled and limitations disclosed
Generated content is identified as such. Every release report states known limitations, failure modes observed in evaluation, and conditions under which the system should not be used.
Security testing
Adversarial inputs are part of validation
Prompt injection through documents, repositories, and tool outputs — and attempts at data exfiltration — are tested before release and after material changes.
Reporting
Concerns have a direct channel
Security issues or concerns about a system's behavior can be sent to [email protected].
Start with an assessment.
Assess maps the workload with the people who do it today and ends at G1 Scope, where the workload owner decides whether to continue.