The most complete subsystem we have built, and the one that decides whether this is a platform or a service with a platform underneath it.
A module is an application your people open from the dashboard and never think about again. Underneath, it is held at arm's length from the platform hosting it: its own origin, a ceiling fixed when it was installed, and credentials that are vended one request at a time and expire.
A module is a manifest-declared application that runs inside your deployment and is framed inside your dashboard, so your people reach it by signing in once. It is not a plugin inside the platform. It is a separate application the platform will talk to under conditions written down in advance.
Every module is served from its own hostname under your deployment's domain, never as a path inside the dashboard. The shell frames it across an origin-checked message bridge. A content security policy built from its manifest is applied on every request, so what the page may connect to is declared, not discovered.
What a module may reach is recorded in your deployment's parameter file when it is installed: module, channel, publisher, resources, ceiling. Every piece of cloud identity policy it runs under is built from that entry at deploy time.
The module holds no standing credential. It presents a short-lived signed assertion, the broker runs its fail-closed checks, and only then does a credential exist: fifteen minutes at most, tagged with the module, the channel, the lease and the person whose click caused it.
Admitting a module is a deploy-time parameter changed through a release, like the model allowlist, the content policy, the tier and residency. An administrator can pause a module and promote a reviewed build, but cannot widen what one may touch. What an administrator can and cannot do →
The more interesting finding from running a module platform inside an AI product is what gets built on it. Most modules do not call a model at all. What organizations use every day is governed business software: intake, scheduling, records, rosters, forecasts. Inference is one capability among several, requested by name through the broker like storage or a table. These are the kinds that exist today, described generically.
An upload-only drop into a private store, with the file fingerprinted in the browser before it leaves. Nothing reads back out through the module.
A tool that reads an organization's own operational records and projects from them. The arithmetic is arithmetic, which is exactly the work a model should not be doing.
Microsites and lead capture, serving public pages on the organization's own domain. At that point the platform is serving an organization's customers, not only its staff.
Field-level encrypted columns over a real roster, with an audited reveal path: reading a protected field writes a record of who read it.
The kind that does broker an inference capability, requested by name in the manifest and agreed at admission, then travelling the same governed route chat does with your content policy attached.
Most modules do not call a model. That is not a gap. It is what a governed AI platform looks like once the business chooses what the computer should actually do.
Inference does not belong in a zero-error critical path. AI is sometimes the runtime, and sometimes it is the tool used to build the runtime.How we decide where a model belongs
A person clicks something inside a module. Between that click and any resource it touches: a ticket redeemed once, a host-scoped session cookie, a signed five-minute assertion pinned to that one module, a check that the person's role entitles them, an intersection of the request with the admission, then the broker. The broker is the control point, and it fails closed.
None of these is an application setting. Each is a property of how the infrastructure is built, a deny in cloud identity policy, or a check the server runs on bytes it re-reads itself. Where a guarantee is enforced matters more than the guarantee.
| Guarantee | What the platform does | Fixed at |
|---|---|---|
| Own origin | Each module is served from its own hostname, never a path on the dashboard. A same-site rule is enforced both when the infrastructure is built and on every request. | Build and request |
| Per-request content security policy | Composed from the module's manifest for each request, so the connect hosts a page may use are the ones it declared. | Run time |
| Permission boundary | A module's identity carries a boundary that denies the platform's own tables. Reaching them is not a permission it can be granted. | Deploy time |
| Audience-pinned assertion | A signed assertion valid for five minutes and pinned to one module audience. It is not a session and cannot be presented anywhere else. | Run time |
| Short-lived credentials | At most fifteen minutes, carrying required tags for module, channel, user, lease and tenant plus a source identity. A missing tag is a failed assumption, not an unattributed session. | Run time |
| Access record first | The record of the grant is written before the credential is returned, and an unwritable store refuses to mint. No record means no credential. Records are kept 400 days. | Run time |
| Resources by logical name | A module asks for a capability by name under a pattern that cannot express an infrastructure identifier. The mapping to real resources is yours, made at admission. | Install time |
| No model method in the browser | The browser half of the authoring kit gives session, authenticated fetch and the message bridge, and has no model method at all. A module page cannot call a model even by mistake. | By construction |
| No walking around your tier | Admitting a directly-inferring module on a tier that promises a private model endpoint fails the infrastructure build, because module compute is not attached to that network. | Build time |
Every row above is built and exercised. Client modules in use today run on the staging channel; the production promotion path is built and exercised on our own deployment.
The publish service re-parses the exact bytes it received, repeats the shared conformance rules on them and checks the artifact hash against the one the upload declared. The answer the tool gave on the author's machine has to hold again on ours, on the same bytes, before anything lands. The five points the contract is checked at →
Every module record exists per channel. Continuous integration can publish to staging and nowhere else: the stage type in the command-line tool admits exactly one value, and the module interface has no promote route at all. That absence is the control.
A module's screen is always framed by your dashboard and always isolated the same way. What differs is where its back end lives, and who has to cut a release before a change reaches your people.
The back end runs as part of your deployment, put there by our factory as its own stack, discovered from your admissions. Its source sits in the product repository, so a change to that module can require a product release.
The back end runs in the publisher's own cloud account, from their own repository and their own continuous integration. Nothing waits on us. The admission in your parameter file still fixes what it may reach, and the broker still vends every credential, tagged to the person using it.
Either shape leaves us able to refuse admission and able to pause. Those two levers are the reason a client's own people can be given the build without the platform's promises getting softer. Who owns what, in writing →
And if the access record cannot be written, the credential is never issued. The ordering is the point: evidence first, capability second.
No. A module's identity carries a permission boundary denying the platform's own tables, so it is not a grant that can be added later by mistake. It reaches only the resources named in its admission, asked for by logical name under a pattern that cannot express an infrastructure identifier.
No credential is issued. The record is written before the credential is returned, an unwritable store refuses to mint, and records are kept 400 days. Account-level audit logging underneath that, multi-region with file validation and one-year retention, is a Standard and Strict control. Posture tiers, and what each buys →
Only if its manifest asked for an inference capability and the admission agreed, and then only through the governed route, with your content policy attached by cloud identity policy exactly as it is for chat. The browser half of the kit has no model method, so a module's front end cannot reach one accidentally.
We do, through a release, by writing the admission into your parameter file. Your administrator promotes reviewed builds and can pause a channel, but cannot widen what a module may touch. Nothing in the running system can create a role or a permission. Administration, precisely →
No, and it is not being built. No cross-deployment catalogue, no module price, no revenue share. A module belongs to one deployment and the organization that owns that account.
An administrator disables its channel. That is a real runtime pause rather than a listing change: it stops in the running system, immediately, without waiting on us or on a release.
A bounded first step that ends with the shape of your deployment written down, including which business capabilities belong in a module and which of them need a model at all.