01
Executive sponsor.
Owns the strategic outcomes and the priority order. Decides whether governed AI creates enough value here to proceed at all, and settles a conflict between two capability owners.
The worst time to work out who owns a decision is the hour you need the decision made.
Who owns what {inside} your account. Written down first.
You own the account, the data and the business decisions. We own the architecture, the platform controls and the releases. The line between them is written into the service agreement before the first build, because a boundary discovered during an incident is not a boundary, it is an argument.
What we can warrant, and what we cannot.
THE PRINCIPLE · ONE SENTENCE
Most vendor relationships leave this implicit and both sides assume the generous reading. Ours states it: business logic you author is yours; platform controls we operate are ours. We can warrant the controls we operate. We cannot warrant your code.
That sounds like a disclaimer and it is the opposite of one. Because the platform is deployed in an account you own, you genuinely can build things in it that we did not write and would not have written. The freedom is the product. The clause is what keeps the freedom from quietly becoming our liability, or yours.
Yours by design
Shared, with named owners
Ours to operate
Where this lives
It is not a web page in place of a contract. The split below goes into the service agreement, is reviewed by counsel before either party relies on it, and is settled before the first module is built. This page is the version you can read without asking for a document.
Fifteen lines, and no ambiguous ones.
THE SPLIT · ROW BY ROW
A responsibility with two owners has none. Each row below has exactly one, except the last, which is deliberately joint and says how the joint decision is made.
| Responsibility | You | org.tech | Note |
|---|---|---|---|
| The cloud account and its root credentials | ✓Yours | ✕ | Opened in your name. We never hold root, and we cannot recover it for you. |
| The compute bill | ✓Yours | ✕ | Your provider bills you directly at list price. We never sit between you and it. |
| The data, and how it is classified | ✓Yours | ✕ | We hold no client data on our own infrastructure and cannot classify what is not ours. |
| What the AI may access | ✓Yours | ✕ | Your decision. We apply it in configuration and enforce it in policy. |
| Who holds which role | ✓Yours | ✕ | Your administrator edits grants at runtime, without a redeploy. |
| What goes into the knowledge base | ✓Yours | ✕ | Everything loaded is readable by every user of that deployment. Load only what all of them may see. |
| Business impact and risk acceptance | ✓Yours | ✕ | We present options and implications. We do not accept risk on your behalf. |
| External communication, to anyone | ✓Yours | ✕ | Customers, regulators, staff, press. We will help you draft. You decide and you send. |
| Business logic your people author | ✓Yours | ✕ | We can review it and validate it against the contract. We cannot warrant that it does the right job. |
| Promoting a module to production | ✓Yours | ✕ | A named administrator of yours approves the exact artifact by hash. Our own automation cannot promote. |
| Architecture and implementation standards | ✕ | ✓Ours | How the deployment is shaped, and what a correct build looks like. |
| The platform controls we operate | ✕ | ✓Ours | The controls in the matrix, with their verdicts. This is the part we warrant. |
| Releases and the deploy path | ✕ | ✓Ours | Every deployment from a tagged release and a clean checkout, rolled one at a time and confirmed. |
| Technical remediation and root-cause analysis | ✕ | ✓Ours | We find it, we fix it, and we write down what happened. |
| Relaunch criteria after an incident | △Joint | △Joint | We own technical readiness. You own business readiness and the risk acceptance. Both are required. |
The wording here is the plain-language version. The operative text is in your service agreement, and where the two differ the agreement governs.
Your code, our controls, one account.
THE MODULE RULE · WHERE THE LINE FALLS
Modules are where the split earns its keep. A module runs on its own origin inside your deployment, reaches platform resources only through an admission fixed at deploy time, and receives short-lived credentials tagged to the named person using it. We operate every one of those controls. What the module then does with its own business logic is authored by whoever authored it.
org{•}tech / governance / responsibility-lineWarranted by us · authored by you
Your people
Deployment administratorGrants, promotion, pause
Module authorBusiness fit and acceptance
Cloud account you own One organization · one account
Module on its own originAuthored by you
Admission and brokerOperated by org.tech
Platform resourcesReached only through it
Access recordWritten before the credential exists
Your data and rolesYours throughout
Managed model service
InferenceContent policy applied before it arrives
Solid outline is the account you own. The hot node is the control point we operate: the admission set at deploy time, intersected again by the broker at run time. If the access record cannot be written, no credential is issued.
Where this stands today
Client modules in use today run on the staging channel, and client-authored modules are a pilot. The production promotion path is built and exercised on our own deployment. See developer modules for exactly where that stands.
Six people, named by role.
ROLES · NAME THEM ON DAY ONE
Every row in the table above resolves to a person on your side. We ask you to name them before the deployment, not because it is ceremonial but because an unnamed owner is a decision that will be taken by whoever is in the room.
02
Business process owner.
Owns the definition of success for a given capability. Without this role a capability gets measured by whether it shipped, which is the wrong measurement and a comfortable one.
03
Content owner.
Owns source quality, permissions and currency, and treats documentation as the source of truth. Decides what enters the knowledge base, knowing every user of the deployment can read it.
04
Security owner.
Owns risk acceptance and is the escalation point for a suspected exposure. Signs the posture commitment, including the written acknowledgement that we hold no third-party attestation.
05
Finance owner.
Validates the baseline and reviews value against cost. The compute bill arrives from your provider, so this role reads a real invoice rather than our estimate of one.
06
Deployment administrator.
Holds the day-to-day authority inside the product: users, roles, grants, quotas, enabling or pausing a channel, and approving a promotion by hash. Cannot change models, policy, tier or residency, by design.
Contain first, then consult.
WHEN SOMETHING GOES WRONG
How we behave, in order
Stop the exposure, stabilise, then put the decision in front of you.
We are a small senior practice, not a staffed operations centre. What we publish is the order in which we act and who owns each decision, so both sides know it before the hour it matters.
- 01Immediate risk of data exposure: we shut down first and consult after. A channel can be paused at runtime. We would rather explain an unplanned pause than a quiet continuation.
- 02Stabilise into a controlled state. Contain, preserve the evidence, and stop the situation getting worse before anyone debates what caused it.
- 03Present options and implications. What we can do, what each choice costs, what each one leaves open. Written, not narrated over a call.
- 04You decide the business response. Including whether to accept, reject or disclose the residual tradeoff, and everything said to anyone outside your organization.
- 05Relaunch is joint. We confirm technical readiness. You confirm business readiness and accept the risk. Neither alone is enough.
When something goes wrongGOV-SR
- Who you reachThe founder, directlyThe person who built the platform. No queue, no account manager relaying answers
- First move on suspected exposureContain, then consultA channel can be paused at runtime
- Who decides the business responseYouIncluding anything said to anyone outside your organization
- Root-cause analysisorg.techWritten down, and dated in the operations journal
- CommitmentsWritten into your service agreementSettled before the first build, not during an incident
Order of actions·Each with a named owner
01So there is no service-level agreement?
There is no published response-time or availability commitment, correct. What you get instead is a direct line to the person who built the platform, releases rolled one deployment at a time and confirmed, and an operations journal with dates in it.
If your procurement needs a contractual response time, say so at the assessment. It is a conversation, not a form field we will quietly leave blank.
02Our team builds a module and it leaks something. Whose problem is it?
Both, in different directions. The platform controls that should have contained it are ours: the admission ceiling, the broker checks, the isolated origin, the access record. If one of those failed, that is our defect and our remediation.
The business logic inside the module is yours, as is the decision about what data it was pointed at. We will help you contain it either way, and the containment happens before the attribution.
03Can you access our data to investigate?
Only if your posture tier gives us a role, and only as that role allows. At Standard and Strict we hold a scoped, session-capped management role. At Baseline no cross-account role exists at all, which means an investigation depends on your people running what we ask them to run.
An administrator reading a user's chat transcript is itself written to the audit record, including when the administrator is us.
04What if we lose access to the account?
We cannot recover it. Root credentials are yours and we never hold them, which is the point of the arrangement and also its sharp edge. Treat root recovery, billing contacts and break-glass access as part of your own continuity planning, and we will walk through it during deployment.
05What happens to all this if we stop paying you?
The platform and its data are in your account and stay there. The monthly fee buys the service, not access to the thing. Running it afterwards needs a competent cloud engineer, which is precisely why runbooks and infrastructure as code are deliverables rather than internal documents. See ownership and exit.
The clause, in one line
We can warrant the controls we operate. We cannot warrant your code.
Every step that makes building easier gives your people more power inside your own environment, and with it more accountability for what they build and authorize. The answer is not to lower the bar. It is to make the boundary explicit and keep the consequential decisions human and recorded.
- 01Named, not implied. Each responsibility has one owner, by role.
- 02Signed, not published. The operative version is in your agreement.
⎯⎯ Book the strategic assessment ⎯⎯
Your private AI, inside your control ·
We will walk the split line by line at the assessment and name the owner on your side for each one.