Operating Specification

The durable enterprise asset behind the platform.

The Aegora Operating Specification captures how an enterprise outcome should be governed and executed independently of any single model, cloud, workflow tool, or service provider.

Every product in the modular platform either discovers it, creates it, enriches it, governs it, tests it, executes it, measures it, or improves it.

Design Principles

Open enough to inspect, structured enough to govern.

The specification is meant to support portability and review without collapsing into a model-specific prompt wrapper.

Open and inspectableThe operating definition should be understandable by enterprise architects, operators, partners, and developers rather than hidden inside proprietary agent state.
Portable and versionableA path definition should move across environments and evolve through explicit versions instead of being locked into a single model, provider, or workflow product.
Policy-aware and identity-awareThe specification must be able to express policy boundaries, role participation, human approvals, evidence requirements, and validation expectations.
Model-independentThe operating definition should outlast the participating model so enterprises can evaluate and change models without redesigning the entire operation.
What It May Define

The specification can describe the full governed operating model.

An Operating Specification can define the signals, context, policies, roles, decisions, tools, actions, evidence, outcomes, and learning requirements behind an enterprise result.

Signals
Required context
Decisions
Governance
Approvals
Allowed actions
Evidence
Validation
Memory
Current Authoring Model

Use the existing authoring and validation flow today.

The current repository already includes starter templates and CLI validation flows for path definitions. The deeper guided authoring experience belongs in Helix and Aegora Studio rather than in thin public documentation pages.

{
  "signals": ["canonical.events", "source findings", "approvals"],
  "context": ["entities", "risk", "policy", "identity"],
  "decisions": ["recommended_action", "approval_requirement"],
  "execution": ["bounded actions", "human fallback", "evidence capture"],
  "validation": ["outcome checks", "risk after execution", "decision memory"]
}
Current Versus Roadmap

Be explicit about what exists now and what is still being built.

The site distinguishes the current authoring and validation foundation from the broader ecosystem and standardization vision.

Current foundation

Aegora has starter templates, validation commands, example paths, and a runtime import model that stores imported paths as governed drafts before activation.

Draft specification direction

The Operating Specification is being developed as an open foundation for governed enterprise AI execution with portability, validation, and reusable path packaging.

Planned extensions

Signed path packages, broader private registry controls, and expanded publishing workflows are roadmap capabilities rather than present-day claims of a fully mature public standard.

Next Step

Move from the open definition into a governed runtime.

Define the path once, validate it, import it as a governed draft, and then decide where and how it should run.