The GOVENANT Standard — Part 14: Platform and Packaging
How the standard is packaged, priced, deployed, and updated. Companion to Part 13: Part 13 defines the engagement model (Audit → Install → Staff → Operate); this part defines the product surfaces those engagements land on and the deployment doctrine that keeps them operable.
Rule zero: one codebase, one version, vendor-operated everywhere. There is no deployment in which the customer runs or updates the software. Customer-operated installs produce version sprawl, forked customizations, and an unbounded support matrix — and for a trust product specifically, a stale fork is not an ops burden but a certification violation (§14.5). The platform is architecturally built for this rule: the same governed-role code runs every tenant; all behavioral difference is data (Part 13 §13.5).
14.1 The two doors — what is sold
One platform, one substrate, two products aimed at two buyers:
| AI Staff (SaaS) | Governance Engine (PaaS) | |
|---|---|---|
| The offer | AI employees with jobs, calendars, a boss, and report cards | Your agents, made provable: ledger, gates, roster, approvals |
| Buyer | Businesses that want work done | Teams that already build agents |
| Occupants | Ours (platform roles from domain templates) | Theirs (their prompts/models/logic fill the roles) |
| Integration | OAuth tools + webhooks + doc upload — no code (§14.3.1) | Three API calls: levers, duties, actions (§14.3.2) |
| Price shape | Per role/month (+ metered usage) | Per governed action + per active role/month |
| Trust proof | Daily standup + coverage board | Certification badge + published probe log |
| Mental model | ”Hire staff you can check" | "Stripe for AI actions” |
The audit is the shared top-of-funnel, not a flagship. Package Part 9 as a self-serve “AI reality check” (point it at your agent system, get the scorecard) — cheap or free, marketing for both doors. Full-service audits remain the enterprise wedge per Part 13 §13.2, but the product-led motion must not depend on a staffed consulting practice.
The unit of sale is a role, not a seat. The customer buys headcount, priced like salary (“about the cost of two employees for the whole department”). Governance is never sold as a line-item; it is why the AI employee is safe to hire. Expansion revenue is hiring: the earned-autonomy ladder (Part 7) maps directly to expansion — a role with a proven hit-rate is a role the customer gives more work and budget to.
14.2 Anatomy of the hosted platform
Strip the vocabulary and the platform is five concrete pieces of software:
- A tenant is one customer’s org: their roles, rosters, budgets, locks, knowledge, and their slice of the record — structurally isolated (scope derived server-side from credentials, Part 13 §13.5), individually metered.
- Agents run on the platform, never on customer infrastructure. Customer systems are reached only through the connector layer.
- The console is the product the customer experiences. The coverage board (plan vs. actual with drill-to-proof, Part 3 §3.8) is the demo, the daily habit, and the renewal argument in one screen.
14.3 Integration contracts
14.3.1 SaaS door — no code
- Connect tools (OAuth): each connector arrives pre-registered as lever + tool + outcome assertion.
- Point webhooks at the platform (or the platform polls) → typed events on the bus, each with a named consuming duty (Part 4 S6).
- Upload documents → knowledge fabric → context packs bound to roles (Part 13 §13.4).
- Approve rosters and set the constitution — the onboarding interview of Part 3 §3.7.
Activation metric: time-to-first-standup < 24h.
14.3.2 PaaS door — three API calls
The customer keeps their agents; the platform supplies the governance. The entire contract:
| Call | Registers | Notes |
|---|---|---|
POST /levers | An action: name, owning role, connector or their webhook, and an outcome assertion (a predicate the platform checks, or a URL it calls, to verify the effect really landed) | Law 2 at the boundary: no assertion, no lever |
POST /duties | The roster: what each role does, when (cron/event/dependency), and what each beat must produce | Law 3 at the boundary; coverage invariants C1–C3 run on write |
POST /actions | Every agent action, routed through the gauntlet endpoint: the platform runs ownership + validation, executes (or returns file-a-request), verifies the outcome, writes the record | Law 1 at the boundary; the response is the ledger row ID |
Anything not routed through /actions is ungoverned by definition — which is exactly what the
certification audit (Part 9) will find and say. The badge is the enforcement.
14.4 The two-deployment model
There are exactly two deployments. Both are operated by the vendor.
| Multi-tenant SaaS (default) | Dedicated cell (regulated buyers) | |
|---|---|---|
| Isolation | Row-level scope, structurally enforced | Whole-instance: own database, own compute |
| Where it runs | Vendor cloud | Vendor cloud (dedicated region) or the customer’s cloud account |
| Who operates | Vendor | Vendor — customer never gets root, never patches, never forks |
| Version | Current, continuous deploy | Same release train, at most one ring behind (§14.5) |
| What the customer owns | Their data, exportable | Their data, resident — the record never leaves their environment |
The dedicated cell exists because of what the regulated buyer actually needs resident: the record — the ledger, the evidence, the data (in regulated domains the record is the product, Part 4 S1). Not the dispatcher binary. Hence the split:
MUST NOT: classic self-hosting. No deployment where the customer can defer upgrades indefinitely or modify the code. The refusal script: “You get your own isolated instance, in your region or your cloud account — your data never leaves it. We operate and update it. Nobody runs a stale copy of this software, because a stale copy of a trust product is an untrustworthy product.”
Deferred, deliberately: the embedded SDK / OEM path (governed substrate inside a partner’s codebase). It is real, but it reintroduces the version-sprawl problem this section exists to prevent; take it on only when the certification program (§14.5) is strong enough to police forks.
14.5 Update delivery — how one version stays one version
- Release rings. Internal → multi-tenant → dedicated cells. Cells lag by days, not quarters; there is no opt-out, only a scheduled window.
- Additive-only schema migrations. The append-only record makes this unusually clean: history rows are never rewritten (no UPDATE path exists — Part 4 S1); upgrades add tables, columns, and writers. Customer state migrates trivially because it was never entangled with code.
- Customizations survive by construction. Every customization is a row with provenance —
charters, rosters, prompts, budgets, locks (
source='human', Part 8). An upgrade MAY add new defaults; it structurally CANNOT overwrite a locked row. The sticky lock sold as governance is the same mechanism that guarantees “your customizations survive every release.” - Version-pinned certification as upgrade enforcement. A certificate (Part 13 §13.3) names the platform version whose probe log it cites. A cell that stalls or drifts fails its quarterly re-audit and loses the certificate — the customer’s own compliance incentive pulls updates in.
- Connectors ship server-side. Nothing runs on customer infrastructure except (in a dedicated cell) their database — so a connector fix or a new API version deploys to every tenant the same afternoon.
14.6 Pricing shapes
| Stream | Shape | Fed by |
|---|---|---|
| AI Staff | Per role/month, salary-anchored; usage bundled with fair-use cap or passed through | Role staffing (Part 13 §13.5) |
| Governance Engine | Per governed action + per active role/month | The /actions meter |
| Platform | Per-tenant fee (multi-tenant) / per-cell fee (dedicated) | Tenancy |
| Audit | Self-serve reality check (free/cheap) → full engagement (fixed fee) | Part 9 / Part 13 §13.2 |
| Certification | Per certificate + renewal (annual/quarterly per level) | Part 13 §13.3 |
Metering requires no new machinery: the cost ledger is the invoice detail — every token already attributed by scope × role × model (Part 4 S1, Part 13 §13.5).
14.7 Over the top, or the platform? The occupant spectrum
The recurring positioning question — “does this sit over existing agents, or are we the agent platform?” — has a precise answer: we are the organization platform; the agent is a swappable occupant (Part 0 §0.1, Part 2). The agent-framework layer (LangGraph, CrewAI, AutoGen, vendor SDKs) is the commodity layer this standard deliberately does not compete in. Both doors run on one codebase because every mechanism is enforced at a boundary, never inside the occupant’s reasoning loop: the roster wakes work, the ownership gate permits it, the validation gate ships it, the outcome assertion completes it, the ledger remembers it. None of these care what did the thinking.
14.7.1 The three integration depths — and which Laws each can honestly claim
| Depth | Shape | Laws enforceable | Ceiling |
|---|---|---|---|
| 1 · Watch-only | Read their DB/logs/code; run the Part 9 probes | None — we grade their governance, we don’t provide it | The audit (L1 evidence at best) |
| 2 · Gate the edges (“their brain, our hands”) | Their agent deliberates; every action routes through POST /actions; the platform enforces ownership + validation, executes via its connectors, verifies the outcome row | Laws 1 + 2 | L2–L3 (ALIVE, not COVERED) |
| 3 · Hold the clock (their agent becomes an occupant) | Our dispatcher fires the duty → calls their agent (webhook) → its actions return through /actions | Laws 1 + 2 + 3 | L3–L4 (ALIVE and COVERED) |
The load-bearing asymmetry: Laws 1 and 2 can be enforced over the top; Law 3 cannot. Gating actions and verifying outcomes proves things about work that happened. Coverage — detecting the duty that silently never fired — requires owning the scheduler, because silence is undetectable in a system you don’t wake. An over-the-top integration makes an agent’s work provable; only occupancy makes its job provable. This is the physics of the upsell: customers enter at Depth 2, then discover the coverage board is empty until the platform holds the clock.
14.7.2 The no-side-doors rule (Depth 2 certification requirement)
A gate is only a gate if the fence has no hole. Depth 2 certification MUST verify that the
customer’s terminal credentials are resident with the platform or that every direct actuation
path is provably disabled. An agent that can still email/merge/file directly renders /actions
decorative — precisely the “ownership gate bypassed at every delivery edge” failure the reference
audit caught (AP-5). No side-door keys, no certificate.
14.7.3 The occupant-webhook contract (the fourth API surface)
Depth 3 adds one surface to §14.3.2 — this time the platform calls them:
platform → customer: POST <their occupant URL> { duty_run_id, duty_key, role_key, context_pack, budget }customer → platform: actions via POST /actions (each carrying duty_run_id)platform: verifies outcomes, resolves the duty_run, writes the recordTheir agent keeps its framework, prompts, and models; it simply answers the phone when its duty fires. The occupant is theirs; the job, the rules, the hands, and the proof are ours.
14.7.4 Positioning consequences
- Frameworks are suppliers, not rivals. Every improvement in the agent layer makes the platform better for free, because occupants are swappable configuration.
- The moat vs. frameworks adding governance themselves: a framework governs its own agents from the inside. The platform governs any occupant from the boundary, proves it with an audit the occupant’s vendor doesn’t control, and holds the coverage math no inside-the-loop framework can honestly claim.
- The one-liner: “Bring your own brain. We supply the job, the rules, the hands, and the proof.”
14.8 Packaging anti-patterns
- Selling governance as a line-item. Nobody buys “governance”; they hire staff they can check. Governance is the reason the hire is safe, not a SKU.
- The four-topology menu. Audit-only / SaaS / VPC / SDK as co-equal offers is a consultant’s answer. Two doors, two deployments; everything else is a roadmap item or a negotiation.
- Customer-operated anything. See §14.4. The moment a customer can defer an upgrade, you have N versions in the field; the moment they can modify code, you are a consultancy.
- Certifying what you don’t operate. A badge on a system whose version you can’t verify is an asserted claim, not a certified one — the exact failure Part 13 §13.3 exists to prevent.