A small practice cannot out-shout a software vendor. It can send a better document, and let the reviewer check it.
Most of this already exists before we meet you. It is generated from the code that builds a deployment, so it cannot drift away from the thing it describes. The rest is assembled with you during the engagement, and a short passage at the bottom names what the pack does not contain.
A security review usually opens with a request for documents, and usually receives a brochure, a trust-centre page and a promise that the real answers will come from a specialist. These seven are produced by the system that builds and runs a deployment, which is why we can put them in front of you before there is a contract.
The discipline underneath is one rule: a document about the platform is generated from the platform, never typed alongside it. Where a document is typed, we say so.
Every deploy emits an architecture model discovered from the infrastructure that was actually synthesized, and that model is reconciled against the drawn diagram. A picture that has quietly stopped matching the system is the single most common defect in a vendor pack. Ours is checked, on every deploy.
Seventeen technical control rows mapped to SOC 2 Trust Services Criteria and ISO/IEC 27001:2022 Annex A, each carrying enforced, partial or not enforced, plus the standing exceptions recorded against your configuration. The uncomfortable rows stay in.
Signed in, your people see the deployment's resolved controls and its standing exceptions. It is generated from the same typed object that builds the infrastructure, and a test fails our build if the page and the exceptions table disagree. Evidence your own staff can open without asking us.
Seven sections covering context, residency and its tradeoff, security controls, operational requirements, your compliance programme, the recommended posture and the commitment. It is published, so you read the questions before the call rather than being surprised by them on it.
One typed object resolved from a tier name with any per-control overrides. It drives the infrastructure, the plan page and the control export from the same value, so the three cannot diverge. An override carries a written reason and shows up as a disclosure.
Produced by script from the provider's live catalogue and classified by where each model actually processes a request: in-region, routed within one country, cross-region, or served from elsewhere. At 5 September 2026: 104 active models from 18 labs. Never retyped into copy.
The seventh artifact is the boring one that answers the hardest audit question: what code was running on the day the thing happened. The factory refuses a tag that is not on the mainline, refuses a dirty tree, and stamps the version into the health endpoints so the running system can be asked directly.
These do not exist as templates waiting for a name to be dropped into them. Each is specific to one deployment, and each needs a decision from you before it can be written.
We work through the published questions with you and record the answers. The residency section carries the tradeoff in writing, including the fact that pinning to a jurisdiction removes every current frontier model from the menu. The output is the committed configuration the deployment is built from.
Where each class of data is stored, where inference is processed, what crosses a boundary and what does not. It is written against your resolved configuration, not against the product in general, because those are different documents and only one of them is true for you.
Who owns the account, the data, the classification, the roles and the business decisions; who owns the architecture, the platform controls, the releases and the technical remediation. Written down before the first build, not argued about after an incident.
A pre-written data-flow statement would describe a deployment nobody has. Residency, tier, model set and knowledge-base scope all change what is true, so the document is written once those are decided. See the engagement path for where each of these lands.
We would rather you verified than trusted us. Each row below pairs a question a reviewer actually asks with the artifact that answers it and the thing you can do yourself to test the answer.
| Reviewer question | Artifact that answers it | How to verify it yourself |
|---|---|---|
| Can a user get an ungoverned model call? | The control matrix row for the mandatory content policy | Ask us to remove the policy from a test call. The cloud identity policy refuses it, and our build fails if the deny is weakened. |
| Where is inference actually processed? | The generated model catalogue, classified by route | Pick a model in the catalogue and compare its classification with your provider's own region documentation. |
| What is logged about a conversation? | The invocation log schema and the matrix row | Read the log in your own account. It holds model, caller, latency and token counts, and no prompt or answer text. |
| What has org.tech not closed? | The standing exceptions table on the in-product plan page | Sign in to your own deployment and read it. You do not need us in the room. |
| What code is running right now? | The health endpoints, the deploy ledger, the stack tag | Query the health endpoint in your account and compare it with the release tag on the ledger line. |
| Does the diagram match the system? | The discovered architecture model from the last deploy | Ask for the reconciliation output alongside the diagram. They are produced in the same run. |
| Can org.tech reach our data? | Your posture configuration and the account's role inventory | List the cross-account roles in your own account. At Baseline there is none at all. |
Every check in the right-hand column is one you run in your own cloud account, with your own credentials. That is the point of the account being yours.
A pack that lists only its contents is a brochure, so here is the edge of this one, stated once rather than sprinkled through the page.
No audit firm has examined our controls and issued an opinion, and we hold no independent penetration-test report. There is no certificate and no letter from an assessor. If that is a hard gate in your process, it is a gate we do not pass today. The deployment sits in an account you own, so a test is yours to commission under your provider's testing policy, and we will scope it with you and fix what it finds.
We name no clients and publish no logos. What we offer in their place is the thing itself: our own deployment, running the product, with the same controls and the same in-product plan page your people would read. Bring your reviewer to it and ask it questions.
The recommendation is not "trust Sam". It is: own the environment, inspect the evidence, and keep the exit open.How we ask to be evaluated
Ask for it at the strategic assessment. The published artifacts, the questionnaire and the model catalogue can go to you before we speak. The rest is written against your resolved configuration during the engagement, so it arrives as the configuration is decided rather than in one drop at the end.
The assessment is $2,500, bounded, and you keep the deliverable whether or not you proceed. See the strategic assessment.
Yes, and it is the fastest route. You are dealing with a small senior practice, so the person answering the technical questions is the person who built the thing. There is no support queue in between and no account manager relaying answers.
Yes. We answer in the same register as this page: enforced, partial, or not today, with the reason. Where a question assumes a control we do not have, we will say so rather than answering the nearest question we can pass.
That is the right question. Our answer is that the evidence is checkable by you, which is a different property from being audited and in some ways a stronger one: an attestation is a third party's opinion at a point in time, while the plan page, the health endpoints and the exceptions table are in your account and readable today.
It is not a substitute for an audit, and we do not offer it as one. See what we do not claim.
Send us your reviewer's document list before the assessment and we will tell you, item by item, which ones we can already answer.