Architecture

Enterprise architecture · Consequence control

Consequence control, composed with your enterprise.

Aarmos adds consequence control to the enterprise systems you already use.

Agents and software may originate through different frameworks and protocols. When a specific proposed consequence reaches a supported Aarmos boundary, Aarmos evaluates it under enterprise policy and applicable Authority before governed execution.

Aarmos is a consequence-control layer inside an existing enterprise architecture. It does not replace identity, credential, network, application, or evidence systems.

Logical enterprise architecture

Actor / agent / software

Proposes a consequential action

Framework / protocol / orchestrator

Different origins can carry the same consequence

Supported consequence boundary

Receives the declared consequence where supported

Decision · applicable Authority

Policy returns a Decision; any required Authority remains a separate prerequisite to governed execution.

Governed execution path

The enforcing path controls dispatch

Enterprise target / provider

Applies its own permissions and service behavior

Effect evidence

Recorded only where observable

Enterprise controls inform the boundary

IAM and identity · policy and organizational authority · credential and secrets systems · network controls

Paths that do not traverse an enforcing Aarmos boundary are not assumed governed.

Evidence leaves the lifecycle

Local or customer-controlled evidence · optional configured evidence delivery

From proposal to consequence

The boundary—not the orchestrator—determines placement.

Aarmos does not need to occupy one fixed position relative to an agent framework or orchestrator. It governs where a proposed consequence reaches a supported enforcing boundary.

  1. 01

    Actor proposes

    A consequential action is requested

  2. 02

    Supported boundary

    The proposal becomes a canonical consequence

  3. 03

    Decision and Authority

    Policy returns a Decision; required Authority is established separately where applicable.

  4. 04

    Governed execution

    The enforcing path controls dispatch

  5. 05

    Effect evidence

    Only what the boundary can observe is recorded

Many actors and orchestration patterns → supported origins → canonical consequences → one governance model. Different consequences from the same orchestrator may reach different supported boundaries.

Compose with existing controls

Add a consequence decision without replacing the systems around it.

Databases did not make identity obsolete when they added access control. Networks did not replace application permissions when they added firewalls. Aarmos adds another bounded control: whether this proposed consequence should proceed under enterprise policy and Authority.

IAM and identity

Remains responsible for
Who the principal is and what it can access
Aarmos adds
Whether this specific consequence is authorized under declared policy and applicable Authority

Secrets and credentials

Remains responsible for
Credential creation, storage, rotation, and scope
Aarmos adds
Governance of whether a credential-backed consequence should proceed where supported

Network controls

Remains responsible for
Reachability, segmentation, and transport policy
Aarmos adds
Consequence-level authorization at supported boundaries

Target permissions

Remains responsible for
What the target system itself permits
Aarmos adds
Independent pre-consequence governance before supported dispatch

Enterprise policy and authority

Remains responsible for
The organization’s intent and human or organizational authority model
Aarmos adds
Deterministic evaluation of that declared intent for a proposed consequence

Evidence systems

Remains responsible for
Retention, downstream analysis, and destination controls
Aarmos adds
Verifiable governed-execution evidence and supported optional delivery

Enterprise IAM and identity systems remain authoritative for identity and access. Aarmos does not replace the identity provider.

Supported consequence boundaries

The boundary determines what can be governed and known.

These are explanatory architectural groupings, not a replacement for Run’s qualified boundary inventory.

Structured consequence boundary

Receives enough declared context to identify the consequential action, Actor, Resource, and consequence-relevant facts required by policy. It can support application-level consequence semantics.

Aarmos sees the information the supported boundary needs to govern the declared consequence. This does not mean every request payload is inspected.

Provider or structured relay

Carries consequence-level semantics and, where qualified, a provider acknowledgement that the supported connector can observe.

Provider accepted request does not establish that an email was delivered or that a business Outcome occurred.

Coarse network boundary

Uses destination or connection-level information for a consequence such as network.connect.

It does not infer a request body, HTTP operation, application action, or business meaning.

See current boundary and path states

Local, hosted, and external

Local-first is not cloud-free.

The architecture separates local governance capability from hosted administration, customer enterprise systems, and external targets or providers.

Customer environment

Actors, orchestration, IAM, policy intent, credentials, network controls, evidence systems, and applications remain under customer authority.

Customer-controlled Aarmos governance

Policy evaluation, receipt signing, and governance key custody run on customer infrastructure.

Aarmos-hosted administration

Account, entitlement, team administration, static delivery, and optional supported services remain separate dependencies.

External targets and providers

Targets, providers, and configured destinations govern their own permissions, service behavior, data handling, and downstream results.

The exact deployment topology depends on the supported boundary and customer environment. Aarmos produces verifiable evidence about governed execution. Evidence can remain within the customer-controlled environment or use supported optional delivery mechanisms. Integration with a specific SIEM, storage system, or evidence destination depends on the configured supported capability.

What Aarmos knows—and what it does not

Path truth stays separate from system-wide assumptions.

  • A governed path can be enforcing while the total path set remains unknown or incomplete.
  • A coarse network boundary does not infer application meaning from encrypted or unavailable request semantics.
  • A path that does not reach Aarmos is not silently treated as governed.
  • Missing evidence remains unknown rather than becoming proof of an Effect or Outcome.

Run reports enforcing, shadow, unconfirmed, known bypass, and unavailable paths. Completeness remains a separate fact.

Govern · Run · Prove · Trust

Architecture composes four truths. It does not redefine them.

Architecture answers how these pieces fit into the enterprise environment.

GovernIs this specific consequence authorized?Open Govern →RunWhere and how is governed execution mediated?Open Run →ProveWhat lifecycle evidence was recorded, and what can it establish?Open Prove →TrustWhy can the enterprise rely on Aarmos, and where does that trust end?Open Trust →

Technical references

Follow each boundary to its canonical owner.