The harness | Jivoo
The harness decides what the machine must prove.
An orchestration engine decides how work runs. A harness decides what the machine may do, what it may touch, and what record it leaves behind. Most organisations buy the first and improvise the second, which is why the speed grows faster than the control.
Five rules the harness enforces.
Each rule is paired with the mechanism that enforces it. A rule in a person's memory is not a guardrail.
AI drafts, people decide.
Rule 1
No AI tool merges to a protected branch, applies infrastructure or releases to production on its own.
One thread.
Rule 2
The work item ID links the request, the design, the code, the tests and the release. The pipeline refuses to go on when a link is missing.
Guardrails are configuration.
Rule 3
One canonical standard, generated into each runtime's rule file, plus managed settings and pipeline gates, all versioned and reviewed like code. That is what makes the factory independent of any one AI vendor.
Least privilege for AI.
Rule 4
AI tools run with the person's own non-production access. No AI identity holds production access, and infrastructure pipelines use a federated identity per environment.
Evidence by default.
Rule 5
Every step leaves a record in a system of record, including which runtime, model, tier and policy version drafted the work, so an audit sample can be produced on demand rather than assembled before an audit.
The last ten lines of a gate run on this site's own repository, 1 November 2026. One failed check stops the run, so a page is never uploaded on a partial pass.
Four layers of configuration.
A rule that lives in a person's memory is not a guardrail. Each layer has an owner, and each one narrows what the layer above it allows.
Four layers, each narrowing the one above it, and the ban list that holds at every layer.
| Layer | Owner | What it sets |
|---|---|---|
| Organisation | Security | The approved runtimes and tool connectors, the commands that are denied, single sign-on, and the data rules. |
| Engineering standard | Architect | One canonical rule file imported by every repository and generated into each runtime's own rule file: secrets through the vault, parameterised data access, logging with the tenant and no customer data, commits that cite the work item. |
| Repository | Tech lead | Build and test commands, the folder map, the tier rules for sensitive code, and hooks that run formatters, analysers and the secret scan before a push. |
| Product project | Product and architect | The story template, the architecture document, the glossary and the data classification the assistant drafts from. |
The four configuration layers of the harness, with the owner and what each one sets
What never enters a model's context.
A rule that is not written down is a rule that will be broken politely. The ban list is part of the standard, and the connectors are chosen so data is queried with filters rather than pasted.
- Production customer data of any kind.
- Credentials, keys, tokens and connection strings.
- Restricted or regulated data outside its approved workspace.
- Penetration test reports and customer contracts outside a security-owned workspace.
- Logs, query results and data dumps pasted into a prompt.
Review, in two stages.
An automated first pass is welcome: it comments, and it never merges or deploys. A named person approves every pull request that changes authentication, tenant isolation, data access, infrastructure, pipelines or deploy scripts, enforced with code owners and branch policies.
A person approves every production release in the protected environment, and the release deploys by digest, so the image that ships is the image that was tested.
The traceability chain.
Six links from a request to the evidence an auditor reads. Each role adds one, and a missing link stops the change.
Six links from a story to the evidence, and the gate that stops a change when one is missing.
Story to decision
Link 1
The decision record is linked from the work item.
Story to code
Link 2
The work item ID is in the branch, the commits and the pull request.
Story to test
Link 3
Tests are tagged with the work item, and results publish to the run.
Code to release
Link 4
The release is built from a merge and deployed by digest.
Release to approval
Link 5
A named approver, in a protected environment, at a recorded time.
Everything to evidence
Link 6
One query joins work items, changes, runs and approvals into a sample.
The measures that say it is working.
- Merged changes linked to a work item: 100%.
- Production releases with a named human approver: 100%.
- Stories closed with a linked passing test: 95% or more.
- AI or shared identities with production access: 0.
- Open critical or high findings older than 30 days: 0.
- Deployment frequency and lead time: no worse than before.
A harness is designed, not bought.
It is written once for your estate: the layers, the ban list, the identities, the review gate and the record. Then it stays in force while the runtimes change underneath it.