ACRA Platform

Digital Architecture for High-Risk, Low-Trust Environments

1. Introduction and Position

Organisations are operating at the intersection of accelerating technological capability and escalating security risk. Data-driven systems, AI-enabled workflows, and real-time communications offer decisive advantages in speed, scale, and coordination. At the same time, organisations need to retain control over data, execution, and system behaviour.

Adopting modern digital platforms often requires placing sensitive workloads on shared infrastructure, external control planes, and opaque service dependencies. These environments introduce risks, including geopolitical pressure, supply chain exposure, insider activity that may be malicious or inadvertent, and jurisdictional uncertainty, all of which contribute to system vulnerability.

For organisations operating in high-risk, high-consequence environments, these vulnerabilities directly impact resilience, accountability, and sovereignty over critical systems.

Valarian enables organisations to adopt advanced digital capabilities without ceding architectural control.

ACRA is Valarian’s enforced execution platform for environments where trust cannot be assumed and failure must be contained. It provides isolated execution environments (secure enclaves) within which applications and supporting services operate under explicit, platform-enforced constraints. Isolation, identity, policy enforcement, and audit are implemented at the platform architecture level rather than delegated to individual applications or layered on through configuration.

This approach allows organisations to deploy workloads, data processing pipelines, AI systems, secure communications platforms, and bespoke applications while retaining authority over where code executes, how data is accessed and how failures are constrained and observed.

2. The Structural Problem

Contemporary complex systems are typically assembled from a combination of shared infrastructure, managed services, bespoke applications, and flat or semi-flat networks. Even when individual components are well engineered, the resulting system exhibits common structural failure modes:

• Implicit trust relationships between services, environments, and networks that were not designed to be adversarial.
• Shared control planes where compromise or misconfiguration propagates beyond intended boundaries.
• Configuration-driven security, dependent on sustained human correctness over time.
• Operational vulnerability under degraded connectivity, partial outages, or organisational stress.

These failure modes are not the result of poor implementation, they are properties of platforms that assume cooperation, availability, and discipline as baseline conditions.

3. Architectural Position and Threat Assumptions

For systems operating in adversarial, degraded, or high-consequence environments, these assumptions cannot be relied upon. Architecture must therefore begin from explicit threat assumptions rather than optimistic operating conditions.

For this reason, ACRA is designed around these explicit assumptions:

• Infrastructure is conditionally reliable but non-authoritative for security decisions.
• Networks may be hostile, misrouted, or observed.
• Applications are fallible and may be vulnerable, misconfigured, or malicious.
• Human operators and developers will make mistakes, particularly under time pressure.

From these assumptions follows a core architectural position in which security, isolation, and assurance are enforced by the platform itself rather than inferred from correct behaviour elsewhere.

ACRA therefore treats trust as a bounded and constrained relationship, enforced at explicit boundaries and observable in operation.

4. Platform Architecture

ACRA realises its architectural position through a layered design that separates authority (ACRA Control Plane), enforcement (ACRA Core), and execution (ACRA Enclaves). Each layer has a defined responsibility and trust posture, operating independently of the underlying infrastructure, whether cloud, on-premise, or edge.

4.1 Infrastructure Provider

The infrastructure provider is treated as a resource provisioner rather than a security authority. It supplies compute, storage, and basic networking primitives, but does not participate in identity, policy, or access decisions and does not define trust boundaries. ACRA does not rely on the infrastructure layer for isolation guarantees beyond basic execution.

As a result, ACRA’s enforcement behaviour and authority model remain consistent despite differences, misconfiguration, or instability in the underlying infrastructure. Variations or compromise at this layer may affect capacity or availability, but they do not alter the platform’s security posture or enforcement semantics.

4.2 ACRA Core

The base layer of the ACRA Platform is ACRA Core. ACRA Core is the runtime policy-enforcing system layer that realises the platform’s security, isolation, and assurance guarantees. It operates above the underlying infrastructure and below the ACRA Control Plane, translating declared intent into enforced system behaviour.

Key functionality behind ACRA Core:

• Enforce isolation across compute, network, and storage.
• Implement identity-bound, default-deny service communication.
• Provide encrypted, scoped persistence for stateful workloads.
• Execute access, network, and data protection constraints issued by the control plane.
• Emit telemetry and audit artefact.

ACRA Core components are hardened and opinionated, configured by the platform to execute policy rather than originate authority.

As part of this enforcement model, ACRA Core validates workload artefacts prior to execution, including signature verification and vulnerability policy checks, denying admission to workloads that do not meet declared constraints.

When operating under partial failure or degraded conditions, ACRA Core preserves the last known valid policy state and prevents any action or access that cannot be safely enforced.

4.3 ACRA Control Plane

The ACRA Control Plane is the platform’s authoritative decision and coordination layer. It defines intent, evaluates policy, and manages system state, but does not directly participate in runtime enforcement.

The ACRA Control Plane is responsible for:

• Identity resolution, authentication and authorisation.
• Evaluation of authorisation decisions based on platform policy.
• Definition, validation, and distribution of policy state.
• Lifecycle orchestration of enclaves and platform components.
• Coordination of configuration, upgrades, and change control.

Under partial degradation or loss of control plane availability, policy evaluation and state changes are frozen. ACRA Core continues to enforce the last known valid policy state, preserving isolation and denial properties rather than relaxing constraints.

4.4 ACRA Enclaves

Applications run within isolated execution environments referred to as enclaves. Each enclave defines a bounded execution scope with a constrained blast radius, explicit and policy-enforced connectivity, and independent governance.

Access, communication, and lifecycle control are enforced by ACRA Core rather than embedded in application code. As a result, enclaves are observable as discrete operational units, with runtime behaviour and enforcement outcomes attributable to the enclave boundary rather than to individual application implementations.

5. Trust Boundaries and Failure Domains

ACRA separates concerns of trust and failure deliberately. Trust boundaries define where authority, identity, and policy must be explicitly evaluated. Failure domains define where faults, compromise, or degradation are allowed to have effect.

By separating failure domains from trust boundaries, ACRA ensures that loss of function does not result in expanded trust and that degradation remains explicit, bounded, and predictable.

5.1 Trust Boundaries

Trust boundaries in ACRA define where authority must be explicitly evaluated rather than implicitly assumed. They mark the points in the system where identity and policy are reasserted and where trust does not automatically propagate based on proximity, network position, or prior state.

These boundaries exist between the infrastructure provider and the ACRA platform, between the control plane and runtime workloads, between isolated execution environments, and between platform-level enforcement and application logic.

At these boundaries, identity is evaluated and policy is applied explicitly, with resulting behaviour observable and attributable. Integrity and provenance requirements for workloads are enforced at admission to execution, ensuring that only validated artefacts enter the trusted runtime environment.

This ensures that access and control are intentional, auditable, and enforced consistently in production operation.

5.2 Failure Domains

Failure domains in ACRA define how far faults, compromise, or degradation are permitted to affect system behaviour. They constrain the impact of failure without attempting to eliminate it.

Failures within an execution environment may affect the availability or correctness of workloads in that environment, but are prevented from affecting other enclaves or expanding access. Failures in the control plane may limit the ability to change policy or configuration, but do not relax existing enforcement. Infrastructure-level failures may reduce capacity or availability, but do not alter trust relationships, authority, or enforcement behaviour.

6. Enforcement Model

The enforcement model is defined by a set of architectural invariants that constrain system behaviour rather than express aspirational goals:

• Isolation by Default: Execution environments are isolated unless explicitly connected.
• Identity-Bound Interaction: All access, human or machine, is evaluated against identity and policy, not location or network topology.
• Policy Enforced by Architecture: Enforcement occurs in ACRA Core, independent of application intent or control-plane availability.
• Observable and Attributable Behaviour: Enforcement decisions produce evidence as a side effect, not as optional logging.
• Predictable Degradation: When assumptions fail, the system degrades in controlled, inspectable ways.

These invariants constrain what the system is allowed to become, not merely how it is configured.

7. Developer Interaction and Error Containment

ACRA assumes developer error is inevitable and therefore removes entire classes of developer-driven security decisions from the system design.

Developers:

• Do not define network trust implicitly.
• Do not manage cryptographic material directly.
• Do not implement access control primitives as first-class security boundaries.

Instead, developers declare intent within constrained interfaces. The platform enforces defaults that deny unsafe states and limit the impact of mistakes. This approach optimises for predictable behaviour under error.

8. Operational Opinionation and Standardisation

ACRA is intentionally opinionated about operational patterns, not as a matter of convenience but as an assurance strategy. Deployment workflows, identity and policy models, execution environment structure, and telemetry and audit semantics are standardised to reduce variance across environments and operators. This operational homogeneity simplifies review and accreditation, improves operator handover and incident response, and reduces configuration drift as a risk factor. Operational freedom is deliberately constrained in favour of repeatability and inspectability.

This constraint is what allows security and assurance properties to remain stable during production operation, rather than degrading over time through accumulated operational variance.

9. Observability and Telemetry

In ACRA, telemetry and audit artefacts are enforced and derived directly from runtime behaviour, rather than from optional instrumentation or operator configuration.

• Access decisions: Identity-attributed allow and deny outcomes recorded with policy context.
• Network enforcement: Explicit allow/deny evidence at ingress, egress, and east–west boundaries.
• Policy evaluation: Authorisation decisions emitted independently of application behaviour.
• Lifecycle events: Immutable records for creation, modification, and destruction of enclaves and platform components.
• Operational telemetry: Metrics, logs, and traces describing enforcement health, capacity, saturation, denial rates, and anomalies.
• Isolation preservation: Platform telemetry separated from workload logs and application metrics.
• Derived operations: Dashboards, alerts, and automation consume telemetry but do not influence enforcement.

This model supports sustained day-2 operation, incident response, and assurance under scale, stress, and partial failure.

10. Application Registry and Controlled Reuse

ACRA provides an Application Registry as an architectural control mechanism rather than a convenience feature. The registry governs how software components are introduced, composed, and reused, and exists to prevent the uncontrolled introduction of new trust relationships through ad-hoc integration.

Applications and platform components are registered as governed entities with declared dependencies, constraints, and execution requirements. Registration establishes an explicit contract between the workload and the platform, defining the boundaries within which the application is permitted to operate. This contract includes artefact integrity requirements, with images subject to signature validation and vulnerability policy thresholds prior to deployment.

Registered components are deployed only within explicitly bounded execution environments and are subject to uniform identity, policy, and lifecycle control.

Reuse is permitted only where composition remains reviewable, attributable, and constrained by platform policy. This ensures that system complexity increases through deliberate design rather than accidental coupling, and that new trust assumptions or failure modes cannot be introduced without visibility and control.

11. Assurance and Regulatory Posture

ACRA should be understood as an assurance-enabling platform rather than a certifying authority. It establishes architectural conditions under which claims about isolation, access control, workload execution, and auditability can be demonstrated and verified during production operation. Evidence is generated as a direct consequence of enforcement, not through optional configuration or post-hoc instrumentation.

These enforcement-derived artefacts provide concrete inputs to accreditation, risk assessment, and operational review. They allow assurance claims to be evaluated against observed system behaviour rather than inferred intent or documentation.

Formal accreditation, regulatory approval, and organisational governance remain external responsibilities. ACRA provides the mechanisms and attributable evidence that make these processes technically meaningful, inspectable, and repeatable over sustained operation.

12. Shared Responsibility Model

ACRA operates under an explicit, asymmetric shared responsibility model that distinguishes between platform-provided enforcement and customer-owned responsibilities:

1. ACRA platform services enforce architectural constraints, including isolation, identity, policy, and access control, and generate attributable evidence as a direct result of enforcement.
2. Platform users, meaning authorised personnel with administrative access to ACRA, define policy intent, manage identities and access grants, and respond to observed behaviour using the evidence produced by the platform.
3. Application teams, operating outside the ACRA platform boundary, remain responsible for application correctness, business logic, and data semantics within the execution and access constraints enforced by ACRA.

This separation is intentional and ensures that responsibility is explicit, auditable, and cannot be obscured by shared tooling or implicit trust.

13. Operational Applicability

ACRA is suited to environments requiring strong control over software execution, including:

• Sovereign and regulated data environments.
• Disconnected or degraded operational contexts.
• Secure internal communications platforms.
• Legacy application containment.
• Controlled data and compute workloads.

The platform provides execution boundaries and enforcement. Workload-specific assurance remains the responsibility of the operator.

14. Conclusion

ACRA is an architectural response to environments where trust cannot be assumed and failure must be contained, not a collection of security features assembled after the fact. It is designed to replace implicit trust with enforced structure and to make control explicit rather than assumed.

By enforcing isolation, identity, policy, and observability at the system level, ACRA establishes clear authority boundaries and predictable behaviour in production operation. Both human and software actions are constrained by design, not by convention. This allows organisations to operate critical systems with controlled failure modes, attributable behaviour, and defensible assurance, even when infrastructure, applications, or operating assumptions break down.