Core

SOIT is organized around four core pillars. They describe how teams move from agent design to production operation without losing control over execution, data, cost, and risk.

Pillars

• Build: assemble agents, workflows, tools, knowledge, models, and plugins from typed capabilities.
• Execute: run agents and workflows through governed runtime paths.
• Observe: inspect runs, tasks, traces, costs, approvals, and replay evidence.
• Govern: enforce identity, permissions, secrets, egress, audit, and release policy.

How the pillars connect

The pillars form a loop, not a list:

1. Build defines what is allowed to exist. Every capability is a versioned, spec-validated definition.
2. Execute runs the approved version. Formal execution resolves the published release — never a draft.
3. Observe records what happened. Every execution leaves runs, steps, costs, and trace evidence.
4. Govern constrains and explains every sensitive action — and feeds back into what Build may assemble next.

The loop is enforced by the platform, not by convention: the kernel's runtime ledger makes Observe possible, immutable versioning makes Execute reproducible, and ports and adapters make Govern unavoidable.

Five design principles behind the pillars

• Spec-first — capabilities are JSON Schema definitions before they are runtime behavior.
• Scope-by-default — everything is isolated by tenant and workspace.
• Trace-everything — executable work always creates inspectable evidence.
• Gateway-only — external systems are reached only through governed ports.
• Immutable-versions — releases move pointers; history is never rewritten.

If you are evaluating SOIT, read the four pillar pages in order — they take about ten minutes and explain why the platform looks the way it does. Then move to Capabilities for the concrete product modules.