Effects describe. Grants authorize.

A well-typed request can still be unauthorized. Septa treats the shape of an operation and permission to perform it as separate questions.

An effect is a typed interaction understood by the compiler and runtime. A capability interface or handle provides typed access to an operation; possessing that handle does not itself grant authority. Scoped grants authorize use, and admission checks determine whether a particular request is allowed in its authenticated context.

A useful analogy

An operation contract is like a form: it says which information a request must contain and what response to expect. A grant is like an access permission: it says who may submit that request for a particular purpose.

The analogy stops there. Runtime decisions bind to concrete identities, policies and execution state. A form’s existence never serves as evidence of permission, and a human-readable diagram is not the enforcement mechanism.

Follow one request

Suppose Checkout asks Inventory to reserve stock for an account. Conceptually, the system needs to establish:

1. The operation and message shape match the checked contract.
2. The caller has an authenticated identity and the intended target is identified.
3. The scoped grant permits this operation in this context.
4. Admission satisfies the runtime’s current rules.
5. The outcome is recorded and disclosed under the applicable contract.

A mismatch should produce an inspectable refusal. Changing the type declaration is not a way to widen authority.

Requests and replies have direction

Inventory’s reply belongs to the reservation interaction. Receiving that reply does not authorize Inventory to initiate arbitrary operations on Checkout. Request direction, reply ownership and any later command are distinct parts of a communication contract.

This matters for dependencies as well as application code. A helper that receives a narrow capability should not gain the host’s unrelated authority simply because it runs in the same system.

Completion and disclosure differ

Permission may change after an operation has been admitted. Completing accepted work and revealing protected data afterward are separate decisions. Recorded history does not provide fresh authorization to read sensitive state or results.

Review inspection tools under the same principle. A topology or trace can contain protected information. Its visibility must respect the requesting subject and the coverage of retained observations.

Read the three views correctly

View	Answers	Does not establish
Declared	Which interactions the checked program describes	Current permission
Permitted	Which operations are allowed in a named authority context	That they occurred
Observed	Which interactions retained evidence records	All possible behaviour or complete history

Each view needs a code and policy context. Dynamic targets and incomplete coverage should remain visible.

These controls reduce the reach of mistakes and untrusted code within their enforcement boundary. Native adapters hold their own operating-system authority; include them in the trusted system boundary.