The Digital SME in the Box, and the Signature That Proves It

We have written before about what a governed AI operator looks like: a named identity with a named human owner, supervised by default, with transcripts, budgets and a kill switch. Two questions kept coming back from the teams evaluating that story.

The first: "That is the governance. Where is our first operator?" The second, from the other end of the table: "How do we know the thing that enrolled is the thing that was reviewed?"

Both now have concrete answers.

A working Digital SME on day one

The AI operator pack no longer requires you to bring your own agent on day one. It ships with the OpsChain SME, the product's own question-and-answer expert. It is enrolled and working minutes after you turn the pack on, with one configuration decision: your model key, held in your custody.

Ask it how to put an approval policy on production changes and it answers, citing the documentation pages it used. Three properties make that safe to approve:

• Its knowledge is version-matched. The SME's entire product knowledge is the documentation built into your server. It cannot describe a feature your build does not have, because the page is not there to read.
• Its knowledge is entitlement-gated. Ask about a capability you have not licensed and the SME cannot teach it. The documentation gating that applies to you applies to it. There is no stale wiki and no invented roadmap.
• Estate answers run on your authority. When the SME needs to look at your environment to answer a question such as "what environments does this project have right now?", the read is delegated to the asking user's own permissions. It is read-only and lives only for that exchange. The same question from two users gets two answers, each bounded by what that user may see. The assistant cannot become a privilege-escalation path, by construction.

The SME also holds no write capability at all. It answers. It does not act. It operates under every control we sell: pack-gated at the door, capped at the supervised ceiling, its transcripts sealed and redacted, every request in the audit trail. The SME that supports you is governed by the product it supports.

It is also the reference implementation: the governed pattern, SDK and hardened image your own Digital SMEs are built from.

The signature: provenance for operators

Governance of what an operator does is only half the risk conversation. The other half is what the operator is. This is the supply-chain question: how do you know the process that enrolled tonight is the build your people reviewed?

Every operator now ships as a signed release. Its manifest and artifact are signed and verified against your key registry at enrolment. A tampered build, an unsigned build or a build signed with a revoked key is refused by name, before any identity exists, and the refusal is audited.

Releases then promote like change, one stage at a time through dev, test and prod. The signature is re-verified at every stage, and the promotion into production is held for human approval in the same funnel that governs every production change on the estate. A quorum of named people decides whether this build gets near production, on the record.

The identity your trust grants, ceilings and approval policies act on is therefore also a provenance-attested build. The fleet view shows you, for every operator, which release it runs and what stage that release has reached.

The bundled SME arrives the same way, as a signed release. We run our own product under the same rule.

The pattern

Put the two together and the onboarding story for an AI operator reads like the onboarding story for a person, only stricter. Provenance is verified before the door opens. The identity has a named owner. Authority is granted explicitly and capped by default. Every consequential act is approved by people, and everything is on the record.

That is what we mean when we say AI operators join your team as another set of governed operators. You can see all of it run, live, in a demo.