org.tech / Platform / Developer modules Glass box. Pilot · first client build

The first real test of whether this is a platform others can safely extend, or a service with a platform underneath it.

Your people build. Your administrator promotes. The platform refuses the rest.

A client's own people author a business capability, in their own repository, with their own coding agent. Nothing they write can widen what the deployment allows, and nothing reaches production because a script decided it was ready. The contract is machine-checked five times, and then a person signs.

Book the strategic assessment → 01 What a module is

Every translation through an outside builder loses something.

WHY · WHERE THE INTENT LIVES

A written brief is a lossy description of how work is really done. It can be accurate, pass review and still miss the detail that decides whether the thing gets used. The organization holds the business intent, and every hop out to an external builder and back costs a little of it. So the question is not how to write better briefs. It is what has to be true for the person holding the intent to hold the build, without any of the platform's promises getting softer.

Built and exercised

First client build pending

Refused by the contract

The person who holds the business intent should be able to hold the build. The platform's job is to make that safe, not to make it impossible.Why developer modules exist

Incremental, and saying so is the point

Nothing an organization already bought changes. The deployment, the boundary, the content policy and the modules already running stay exactly as they are. What changes is who is allowed to author a capability on that foundation. This is not a developer ecosystem. It is one more person, inside one organization, building inside the same contract we build inside. The contract itself →

Built for people with intent, not for platform engineers.

THE KIT · FOUR PIECES

The authoring kit is four packages, and every choice in it answers one question: what does someone who is not a cloud engineer hit first, and does the tooling answer in words or in a stack trace? The barrier we lowered is the interface, not the standard.

A scaffold that runs first time.

One command writes a working module, a build, deploy scripts and a CI workflow. A test asserts both templates pass strict validation unedited, so the starting point is never what is broken.

A validator that says why.

Schema, paths, interface constraints, declared connect hosts, tool-to-resource binding, bundle shape, strict rules. A failure names the file, the line and the fix. It approves nothing.

A publish path with no stored secret.

The workflow builds, re-validates, stamps provenance and assumes a role bound to one repository and one branch through workload identity. A caller holding a long-lived key is refused by construction.

Instructions for the coding agent.

One source file of contract guidance generates the instruction files three different AI coding agents read on their own. When the agent wanders, the validator is what notices.

1.1

Manifest · schema version

Enforcement · points

15min

Credential · maximum life

400days

Access records · retained

The tool that tells you exactly where you left the contract.

VALIDATION · A REFUSAL IN WORDS

Deterministic, not advisory

A refusal that names the file, the line and the fix.

The contract is one strict schema plus four static conformance rules written as pure functions in a shared package. The command-line tool and the server run literally the same code, so the answer on your own machine is the answer the platform will give.

01
Undeclared hosts fail. If the bundle talks to a host the manifest did not declare, it does not publish. The run-time content security policy is built from that same declaration.
02
Verification comes first. The server half of the kit requires a verify call before anything else. Governed accessors do not exist until it has run.
03
Scope beyond the admission is flagged here, long before the broker would refuse it at run time.

How the runtime holds it →Enforced in cloud policy

module-author · local validate

RUNNING

orgos validate --strict

[validate] manifest schema 1.1 · module api 1.0.0

Manifest shape✓ strict, no unknown keys

Resources requested by name✓ 3 logical, 0 identifiers

Tool bound to a declared resource✓ 4 of 4

verify() before any handler✓ server entry

Undeclared connect host in bundle✕ src/panels/feed.ts:41

fixdeclare the host, or drop the call

Scope within admission△ reports:write · review

1 refused · file and line named · nothing published

Illustrative outputexit 1

Local validation·Same rules the server runs·Illustrative

Each one is a gate, and none of them trusts the last.

ENFORCEMENT · FIVE POINTS

The same contract is checked five times, in five places, by parties with different reasons to be careful. The server never trusts the tool that ran on the author's laptop, and the runtime never trusts the server that accepted the upload. That redundancy is what makes it safe to hand someone outside our practice the keyboard.

01Your machine

Local validation
The author runs the validator: schema, paths, interface constraints, declared connect hosts, tool-to-resource binding, bundle shape and the strict rules. Failures name the file and the line.

Gate
Does the bundle satisfy the contract, exactly?
Decides: the validator, deterministically
02Your repository

Continuous integration
The workflow builds, re-validates what it built, stamps immutable provenance and assumes a role through workload identity bound to one repository and one branch. Nothing is stored, and the upload link it receives is short-lived.

Gate
Is this build from the repository and branch we said, with no stored secret?
Decides: the identity policy on the role
03The server

Re-parse and hash
The publish service re-parses the exact bytes received, repeats the shared rules, and checks module slot, publisher identity, provenance, limits and the artifact hash against the hash the upload declared. A failure is quarantined, not discarded.

Gate
Are these the same bytes, and do they still pass?
Decides: the publish service, on its own reading
04Deploy time

Admission
Your parameter file resolves logical resources, account, model, residency and quota into a recorded ceiling, and every piece of the module's cloud identity policy is built from it at deploy time. Nothing published later can raise it.

Gate
Is this inside the ceiling recorded when the module was installed?
Decides: your parameter file, through a release
05Every request

Runtime
A ticket redeemed once, a host-scoped session cookie, a five-minute assertion pinned to that module, role entitlement, the intersection of request with admission, a per-request content security policy, then the broker's fail-closed checks and a fifteen-minute credential carrying required tags and the person's identity.

Gate
Should this person, in this module, hold this credential right now?
Decides: the broker, fail-closed

Publishing is automatic. Reaching production is not.

PROMOTION · A SEPARATE ACT

Everything above ends at staging. Production is a different route on a different interface, open only to an administrator signed into the product. The module interface has no promote route at all, and that absence is the control. The approved hash must equal the hash on staging, and the same bytes are copied server side, so nothing is rebuilt between the review and the release.

Two administrators, and what happens when there is only one

A promotion requires two distinct administrator identities. A deployment with a single administrator may self-approve, with a written justification stored verbatim and recorded as not implying a second signature. We do not call that segregation of duties. Everything else we do not claim →

Who may do what	Module author	Your administrator	org.tech
Scaffold, build and validate a module	✓Yes	✕Not their role	✓On request
Publish a build to staging	✓Through CI	✕No	✓Yes
Approve an exact artifact hash	✕No	✓Yes, named	✕No
Promote that hash to production	✕No	✓Yes	✕Our automation cannot
Pause a channel immediately	✕No	✓Yes, a real runtime pause	✓Yes
Widen what a module may reach	✕No	✕No	△Through a release, written into your parameter file
Refuse admission outright	✕No	✕No	✓On contract, security, reliability or responsible-AI grounds

Read the last two rows together. Your own people author and publish; the ceiling those builds run inside is changed through a release, recorded in a parameter file you hold. Shared responsibility, in writing →

Three modes, and the fourth one is deliberately missing.

HUMAN AND AI · TASK ALLOCATION

An author working this way is working with an AI coding agent most of the time, so it is worth being exact about which parts of the work a person is still doing. Each step gets a mode, and there is no mode called delegate.

Building is collaborate.

Author and coding agent work together inside the contract. The generated instruction files hold the agent to it, and when it drifts the validator refuses in words that name the file. Neither party is trusted alone.

Author and agentValidator arbitrates

Requesting promotion is escalate.

Asking for a grant, or for a build to reach production, goes to a person who can say no. The decision is recorded with approvers, reason and artifact hash, whether it promotes or refuses.

Author to administratorRecorded either way

Accepting correctness is own.

Whether the module does the right thing for the business is the author's to accept and cannot be handed anywhere else. It is the judgment this whole arrangement exists to keep close to the intent.

AuthorNot transferable

Why there is no delegate mode

No step here is safe to hand to AI without a human accepting the result. The one component that runs unattended is the validator, and it is deterministic tooling rather than a model: same bytes, same judgment, every time, on the author's machine and on the server. The five decision rules this comes from →

Status, stated exactly

Proven by us acting as the client. The first client-authored build is a pilot.

The scaffold, the validator, the publish path, the admission and the runtime are built and exercised end to end, against the same contract a client's author works inside.

01
Client-authored modules are in pilot. The path is proven end to end by us acting as the client.
02
Staging today, production path built. Client modules in use today run on the staging channel; the production promotion path is built and exercised on our own deployment.
03
Incremental on purpose. Nothing already bought changes. Only who may author changes.

The questions an IT lead asks first.

QUESTIONS · DEVELOPER MODULES

01Do we need cloud engineers for this?

No, and that is the design goal. You need someone comfortable with a code editor, a repository and a build, working with an AI coding agent. They never touch infrastructure: resources are requested by logical name, and the mapping to real ones happens at admission, on our side.

It is a technical role. The barrier is a code editor rather than a cloud console.

02What stops a coding agent writing something unsafe?

Four things in order. The generated instruction files keep it inside the contract. The validator refuses anything outside it, naming the file and the line. The server re-checks the exact bytes for itself. And the ceiling was fixed when the module was admitted, so even a valid module cannot reach past what your parameter file allows. Then a named administrator approves a hash before any of it reaches production.

03Does anyone have to hold cloud credentials?

Not on this path. The publish role is assumed through workload identity bound to one repository and one branch, nothing is stored, and a caller presenting a long-lived key is refused by construction. At run time the module holds no standing credential either.

04Can a module our people write call a model?

Only if its manifest asks for an inference capability and the admission agrees, and then only through the governed route with your content policy attached by cloud identity policy. The browser half of the kit has no model method at all, and in practice most authored capabilities do not want one. Most modules never call a model →

05What happens when the path needs knowledge nobody wrote down?

It becomes a product change. Every repeated support issue turns into a validation check, a scaffold change, a documentation page or a recorded administrator decision. That is a standing rule rather than good intentions, and it is what the pilot is for.

⎯⎯ Book the strategic assessment ⎯⎯

Your private AI, inside your control ·

A bounded first step that establishes whether you have a person who should hold the build, and what the first authored capability would be.

Book the strategic assessment →Open the demo first →