AURELIS / PROTOCOL

Portable records. Traceable decisions.

A control protocol is useful only when systems can exchange records without losing the context that makes them meaningful. The AURELIS protocol model links an AI asset and version to evidence, policy evaluation, decision and audit lineage.

REFERENCE SPECIFICATIONJSON-ORIENTEDVERSIONED RECORDS
Lifecycle

From registration to reassessment.

Select a stage to see its purpose, required context and expected output. This is a protocol model; exact endpoint support and enforcement depend on the deployed implementation.

STAGE 01

Register asset

Establish a stable identity and the scope of the system being assessed.

Required context

Asset ID, owner, purpose, version, environment.

Output

Canonical asset record and identity lineage.

Canonical record

A decision should carry its reasons.

Illustrative schema only. Example IDs and values are synthetic; they do not represent customer telemetry or a claim that a particular asset was assessed.

DECISION RECORD / EXAMPLE
{
  "schema_version": "aurelis.control.v1",
  "asset": {
    "id": "demo-finance-agent",
    "version": "4.3.0",
    "environment": "staging",
    "purpose": "invoice_processing"
  },
  "assurance": {
    "state": "CONDITIONAL",
    "assessed_at": "2026-10-01T10:00:00Z"
  },
  "policy_evaluation": {
    "policy_id": "POL-DEMO-17",
    "status": "REVIEW_REQUIRED",
    "reason_code": "EVIDENCE_STALE"
  },
  "decision": {
    "action": "deploy",
    "result": "REVIEW",
    "required_next_step": "reassess_before_release"
  },
  "evidence_refs": ["E-DEMO-1842", "E-DEMO-1843"],
  "synthetic_example": true
}

Record design principles

  • Identity-boundEvery assessment refers to an exact asset, version and environment.
  • Evidence-linkedClaims reference evidence IDs, provenance and freshness.
  • Policy-explainableDecisions identify the policy condition that shaped the outcome.
  • Time-awareRecords carry timestamps and reassessment context.
  • InteroperableStructured data is designed for APIs and downstream workflows.
Decision semantics

Three outcomes. Explicit reasoning.

Decision labels are not risk scores. A decision should be paired with conditions, evidence references, scope and required next steps.

ALLOW

Conditions satisfied

The evaluated request meets the configured requirements within the evaluated scope. This is not a universal guarantee of safety.

REVIEW

Human or additional evidence needed

Required evidence is missing, stale, conflicting or an exception needs a designated reviewer.

DENY

Prohibited or failed condition

A configured rule blocks the requested operation. The record should identify the rule and supporting facts.