DON'T WAIT ON A ROADMAP. COMPILE YOUR OWN.

A governance vendor shipping SaaS owns your upgrade clock. The moment a staff engineer customises it, the customisation is a fork to maintain or a support ticket that blocks a release. systemprompt.io inverts that. It is a Rust crate you pull into your workspace. Add systemprompt = "x.x" to Cargo.toml, implement one trait, run cargo build --release, and the binary you ship contains the governance core and your proprietary extensions in one process. Your code never leaves your build.

The trait the core team uses is the trait you use. The in-tree domain extensions, from AI to Files, are ordinary implementations of it, not a privileged host. The AI extension contributes model providers and schemas. The OAuth extension contributes HTTP routes and RBAC roles. The MCP extension contributes tool providers and background jobs. An extension you write sits alongside them. The build-vs-buy answer for a CTO is "keep the extension model you would have built, without maintaining the host".

Extensions are not a runtime module system with version-skew risk. Registration wires your type into the binary at link time through the inventory crate. If the crate compiles against the workspace, the extension is present. No dynamic loading, no dlopen, no manifest negotiated over a socket, no "did my extension start" question at deploy.

A staff engineer evaluating an extension model wants one answer. What is the minimum code to ship a new endpoint that inherits the governance library's policy? In systemprompt.io it is one trait. Return a router for HTTP routes. Return schema and migration lists for new database tables. Return job objects for background work. Return AI provider or MCP tool-provider lists for new capabilities. Return role definitions for new RBAC tiers. The governance pipeline (the request-path gate described in Governance Pipeline) applies to every route and every provider your extension adds, because the gate sits ahead of the dispatcher.

The trait lists these surfaces deliberately so the full contract fits one screen, not a half-dozen "extension point" interfaces. Every method defaults to returning nothing, so a narrow extension contributing a single route is three lines. A wide extension contributing schemas, routes, jobs, providers, roles, and admin pages uses the same interface. The only mandatory method is the metadata call that names the extension and declares dependencies.

Every surface you add inherits cross-cutting behaviour without wiring. A route mounts behind the same JWT and audience middleware that guards core routes. A table runs through the same migration ledger with checksum verification, so schema drift fails at startup. A job runs on the built-in scheduler and writes to the same audit log as core jobs. You do not opt into governance. You cannot opt out.

When an extension that should only add one endpoint can technically return a database schema or a background job, the class of bug where an extension claims one thing and quietly does another is a runtime surprise. For narrow extensions, the crate ships typed variants so the type system enforces what the extension is for: an API-only variant exposes a base path and an auth flag, a config-namespace variant carries JSON-schema validation, and there are job-only, provider-only, and schema-only variants alongside them. An extension that should only add routes cannot return a schema or a job, because the type it implements has no method for it.

Dependencies between extensions are checked at compile time, not boot. The builder that composes an extension set uses a type-level list. An extension whose declared dependencies are not already in the list fails to compile. The error names the missing dependency. "My extension crashed at startup because a sibling was not registered" becomes "my build fails and the compiler tells me which sibling".

At runtime, every extension is treated uniformly. The registry stores extensions behind a trait object with downcasting methods, so code that needs "all extensions that contribute a schema" asks once and gets a typed view without reflection. A lookup by string ID serves admin surfaces. A lookup by Rust type serves code composing features at build time. One store, one validation pass, one load order.

An extension that only surfaces a problem under traffic is an incident waiting to happen. systemprompt.io runs the extension pipeline at startup, before the HTTP listener opens. Every extension linked into the binary registers through the author's macro. At boot, the registry collects registrations, instantiates each extension, inserts by ID, and sorts by declared priority (lower priorities load first). If the binary compiled with the extension, the extension is present. No directory scan, no manifest volume, no sidecar handshake.

After collection, a validation pipeline runs four checks before the application accepts a request. Dependency resolution walks each extension's declared dependencies and fails if an ID is missing from the registry. A depth-first cycle check returns the exact cycle path on failure, so a staff engineer reads the ordered loop rather than "circular dependency somewhere". API path validation checks extension routers against the eleven reserved core prefixes, /api/v1/oauth and /api/v1/mcp among them, and rejects collisions. Duplicate IDs fail registration immediately, so a typo never lands silently on top of an existing extension.

For the two less common shapes (standalone MCP server binaries and CLI extension binaries), the loader scans an extensions directory for manifests, parses them into discovered-extension records, and runs the same validation pipeline. Dependencies must resolve. The graph must be acyclic. Paths must not collide. IDs must be unique. A CISO asking "what code runs inside this binary" gets one answer from one validation path, whether the extension compiled in or was discovered from disk.

A CTO buying SaaS governance buys the vendor's upgrade clock. Buying systemprompt.io is buying a Cargo dependency. Pin the version, update when the team is ready, and the binary compiled today runs identically in five years as long as the crate sits in your lockfile. The migration struct tracks version, name, SQL, and a checksum, so schema changes are deterministic and auditable. An auditor answers "what DDL ran in production" from the migration ledger, not a vendor's changelog.

Every deployment is shaped by its use case. A healthcare company adds HIPAA audit tables and retention jobs through the schema and job surfaces of the trait. A financial services firm adds compliance reports and RSS feeds through the page-data and feed surfaces. A dev tools company adds a marketplace UI through the router, component renderer, and template data extender. The core provides governance, auth, and observability. Your extensions make it your product, on the same trait and through the same registry.

The model covers three deployment shapes. Library extensions compile into the main binary and inherit everything including the governance pipeline. MCP server extensions run as standalone binaries discovered through manifests, useful when a tool integration has different resource or lifecycle needs. CLI extensions add subcommands for operators who live in a terminal. All three pass the same validation and share the same capability traits. "Will my extension work" reduces to "does it compile".