SigmaEra for Developer
Show me the contract before you show me the demo.
Every SigmaEra service publishes an OpenAPI spec that CI refuses to let drift: Spectral lint on every PR, a pinned breaking-change gate, and a catalog validator that hard-fails on spec drift in either direction.
Read the contract, then decide whether to trust the demo.
The arc an engineer walks integrating with SigmaEra: what the surface actually is, what stops it moving under you, and what happens when you get something wrong.
- 1First look
What am I actually building against
Someone has decided you are integrating with this. Before you estimate anything, you want to know whether there is a real specified surface or a set of endpoints somebody will describe to you over a call.
What you have to answer
- Is there a published spec, and is it generated from the implementation?
- How many services am I talking to, and which ones matter to me?
- Is the documentation the source of truth, or a stale copy of it?
The layer that answers it
Spec-first services
Every service publishes an OpenAPI specification, linted by Spectral on every pull request, with a catalog validator that hard-fails CI on drift between spec and catalog in either direction. Response schemas are forbidden from allowing arbitrary additional properties.
What changes for you
You start from a specification that CI forces to match reality, rather than from documentation that was accurate at some point last year.
- 2Authentication
Getting a token without inventing a scheme
Half the integration pain in your career has been somebody’s bespoke auth. You want a standard flow, standard validation, and no shared secret in an environment variable.
What you have to answer
- Is this standard OAuth, or something shaped like it?
- How do service-to-service calls authenticate?
- What is the token model — and can one token span tenants?
The layer that answers it
Standard identity, strictly enforced
A single OIDC issuer with authorization-code and PKCE for users, and OAuth 2.1 client credentials with private-key JWT for machines — no shared secrets. Delegation uses RFC 8693 token exchange. One tenant per token is an absolute invariant, and symmetric signing algorithms are rejected in CI.
What changes for you
You use libraries you already trust, and the tenancy model is simple enough to reason about: one token, one tenant, no exceptions to memorize.
- 3Going asynchronous
Consuming events without losing data
Polling will not scale and you know it. But event integrations fail in ways that are miserable to debug — duplicate delivery, out-of-order arrival, and payloads that turn out to contain things they should not.
What you have to answer
- What is the delivery guarantee, and is replay safe?
- What is in a payload — and what is deliberately not?
- How do deletions propagate to me?
The layer that answers it
Outbox-only events
Publishing goes through an outbox rather than directly from request handlers, with a CloudEvents envelope over registered stream subjects. Tenantless events are forbidden and payloads carry identifiers and counts only. Deletion uses tombstones so a late-arriving derivation event for a deleted item is suppressed rather than resurrecting it.
What changes for you
Replay is safe by construction, and you never accidentally build a second copy of sensitive content out of an event stream.
- 4Extending it
Adding your own tools and agents
The interesting work is teaching it about your systems. That is also the point where most platforms hand you a loaded weapon and wish you luck.
What you have to answer
- How are tool arguments validated, and when?
- What stops an agent doing something it should not?
- Is authorization checked before or after the tool runs?
The layer that answers it
Agent and tool registry
Tools are registered with argument schemas that are validated before governance and authorization run, enforcing by default. Agents are bound to their run owner, and a registrant-subset rule constrains the scopes a registered tool can request.
What changes for you
A malformed or over-reaching tool call fails at the boundary with a clear reason, rather than half-executing inside your integration.
- 5Six months later
The upgrade that does not break you
The real cost of an integration is not writing it. It is the morning you discover a response shape changed and nobody told you.
What you have to answer
- What counts as a breaking change here?
- Is that enforced, or a convention people mostly follow?
- How much notice do I get?
The layer that answers it
Pinned breaking-change gates
A breaking-change checker runs pinned — not resolved as "latest" at build time — and must pass clean on every pull request, with a changeset required on every spec change. The tooling itself was pinned after an unauthenticated build-time fetch was identified as a supply-chain weakness.
What changes for you
The surface you build against this quarter is the surface that still exists next quarter, and that is enforced by CI rather than by good intentions.
Control register
Every layer above is documented there in full, including the threat model and the control-status register.
Beneath the controls, the platform itself.
The five capabilities every SigmaEra deployment runs, read through the lens of this role.
Five stages · Protect → Emerge- 01
Protect
Service-to-service auth is OAuth 2.1 client credentials with private-key JWT — no shared secrets — and symmetric signing is rejected in CI, not merely discouraged.
- 02
Orchestrate
Typed contracts everywhere: a shared sensitivity taxonomy shipped as TypeScript and Python siblings with parity tests, so the same tag means the same thing in both runtimes.
- 03
Automate
Events use an outbox-only publish path with a CloudEvents envelope and registered stream subjects. Tenantless events are forbidden and payloads carry identifiers, never content.
- 04
Compound
Agents and tools live in a registry with argument-schema validation applied before authorization, so a malformed tool call fails at the boundary rather than inside your integration.
- 05
Emerge
Because the contracts are pinned and the catalog is validated, the surface you build against this quarter is the surface that still exists next quarter.
The Compound Effect
Intelligence that builds on itself.
- 100%
- of AI interactions governed — every call through one policy enforcement point, with a full audit trail. Source: Platform security white paper — Governance & AI policy
- 8
- must-follow platform standards, each with a named enforcement gate in CI — control coverage mapped to SOC 2, GDPR and HIPAA expectations. Source: Platform security white paper — Standards alignment
- 1
- company-specific model — your corporate knowledge compounds into a private intelligence layer that gets smarter every week. Source: Platform security white paper — Model processing & training
Stop leaking data. Start compounding intelligence.
Talk To Us About Integrating
- Runs air-gapped inside your own boundary
- Full audit trail on every interaction
- 100 agents, one control plane