Operating Paths
A governed execution model for a real enterprise outcome.
An Operating Path turns an operational objective into coordinated action across people, enterprise systems, providers, automation, AI models, and AI agents.
It is the reusable operating asset that defines what signals matter, how context is interpreted, which policies apply, what actions are allowed, when humans must participate, and how the outcome is validated. Within the modular Aegora platform, Operating Paths sit between the Operating Specification and the governed runtime.
What An Operating Path Is
The path owns the operating logic, not the model.
The Operating Path should stay stable even as models, tools, providers, and deployment environments change. It is designed to capture the enterprise operating definition rather than hide it inside prompts, scripts, or one-off automations.
Lifecycle
How Operating Paths are created, governed, and improved.
Paths are treated as governed, versioned operating assets rather than disposable workflow fragments.
Create the definition
Describe the objective, trigger signals, required context, decisions, policy requirements, allowed actions, evidence, outcomes, and memory expectations.
Version and review
Treat each revision as a governed operating asset that can be compared, validated, approved, and adapted to enterprise conditions.
Run through the runtime
Load the Operating Path into the Runtime Engine so signals become operating cases, context becomes decision-ready, and execution remains policy-aware.
Capture evidence and learning
Preserve decisions, approvals, actions, validation, and lessons learned so the enterprise operating model improves over time.
Portable Authoring
Paths can be authored and validated before they reach runtime.
Aegora supports a specification-backed authoring flow so developers and operators can validate a path, review warnings, and only then import it into a governed runtime context.
{
"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"]
}Representative Examples
Concrete Operating Paths for real operational work.
These examples illustrate the shape of the category without pretending to be a complete catalog.
Critical Vulnerability on a Privileged Device
Turn vulnerability findings, identity risk, business importance, approval thresholds, remediation actions, and risk-reduction proof into one governed path.
Privileged Access Review
Coordinate identity, role, entitlement, business need, approvals, revocation, and evidence through one accountable execution model.
Compliance Evidence and Control Validation
Connect evidence requirements, owners, validation rules, exceptions, and remediation into a repeatable path instead of a manual scramble.
Employee Onboarding and Offboarding
Synchronize identity, devices, applications, approvals, system tasks, provider steps, and evidence for each lifecycle event.
Cloud Provisioning and Change
Apply architecture policy, security controls, cost boundaries, approvals, provisioning actions, and validation across cloud operations.
Humans And Models
Humans remain accountable. Models remain participants.
An Operating Path can recommend, route, score, summarize, or prepare bounded action proposals. High-risk actions still branch through policy and human approval. The path preserves the record either way.
First Path
Start with the path where coordination, approval drag, or proof gaps already hurt.
The right first Operating Path is usually the one where policy, identity, risk, and evidence are hardest to hold together today.