Evaluating Septa for your organisation

Know what runs. Control what it can do. Exact code identities, explicit effects and scoped authority provide a foundation for reviewing dependencies and limiting their reach.

For an organisational evaluation, begin with a bounded workload and a threat model. Decide which data, operations and failure modes matter. Then examine how the runtime, native host and deployment environment enforce that boundary together.

Ask for a precise system boundary

Identify the managed core, the trusted runtime, native adapters, identity provider, storage and external services. A capability boundary inside the runtime does not replace host hardening or the authority held by a native process.

Actor isolation gives state and communication an explicit model. It does not imply a separate operating-system sandbox for every actor. Resource limits, lifecycle policies and deployment isolation need their own assessment.

Evaluate four connected controls

Control	Evaluation question
Code identity	Can the deployed code and dependencies be tied to the reviewed inputs?
Scoped authority	Which authenticated subject may request each sensitive operation?
Admission and disclosure	What happens when permission changes after work has been accepted?
Evidence	Which tests or observations apply to this code, environment and workload?

A declared interaction is not a grant. A previously accepted operation and a later request to disclose its result can require different decisions. Retained history must not become a route around current data-access policy.

Qualify the intended workload

Choose a small real service with an external boundary and durable state. Test allowed and refused requests, supported restarts, uncertain external outcomes and a dependency update. Measure performance using the workload shape, state size, log size and host conditions you expect to operate.

Keep local tests, integration tests, fault-injection results, formal proofs and live observations distinct. Each carries different assumptions. A statement that a system is “verified” is useful only when the verified property and its scope are explicit.

Plan deployment deliberately

The first-release model is a local runtime foundation. A managed cloud, cross-node execution and recovery after losing all local storage require separate capabilities and operating decisions. Native Rust integration gives infrastructure teams a concrete boundary to own and audit.

Read guarantees and boundaries alongside effects and authority. Those pages are a better basis for an evaluation than a blanket comparison with another platform.