Platform · Track 2

Decision-process governance

A governance layer for production agents: policy-as-code gates, approval and veto routing with separation of duties, council-style voting on high-stakes decisions, fail-closed escalation, and an immutable (append-only, tamper-evident) audit log of every decision — who proposed, who approved, who could have vetoed, and why. Framework-native (MCP/LangGraph).

In Build

Open-source core

An open-source core is part of the strategy: standard-setting, design-partner trust, and integration adoption all require inspectable reference code.

Designed

Hosted tier

The hosted tier is specified, not yet built. Per-seat pricing is a hypothesis to be validated in the design-partner phase.

Runtime toolkits govern what runs; SICA governs who decides.

LLM observability

Observability platforms record what happened. Useful after the fact — but recording a decision is not the same as governing how it was made.

Content guardrails

Guardrail vendors filter what is said. SICA governs the decision process itself — who proposed, who approved, who could have vetoed, and why.

Enterprise GRC & runtime toolkits

Enterprise GRC platforms automate org-level policy; runtime toolkits enforce allow/deny per action. We have not found mainstream tooling that natively governs the decision process.

Policy as code

Governance rules are written, versioned, and enforced as code — not as prose in a prompt. A gate is a deterministic check that a proposal must pass before any deliberation.

# Illustrative — not production policy
gate:
  action_type: approve
  target_entity: generic
  policy_check: deterministic

Illustrative — not production policy. Abstract fields only.

Live and product — deliberately separate

The System is the LIVE internal reference deployment — our dogfood. This platform is the product we are building from it. The reference system proves the mechanics; the product makes them deployable by your teams.