ASKA v5

ASKA is a proposed architecture for computers and networks that enforce explicit limits on what each participant may do. A program may be allowed to read a document without being allowed to send it. A network may carry a request without authorizing it. An AI assistant may prepare a payment without holding the keys that approve it.

The specification describes how hardware, applications, and network services would enforce those limits together. ASKA v5 is an architecture specification and research program. The complete system remains a research target.

Read the specification on GitHub · Start with the system architecture

From a request to an authorized action

ASKA calls its protocol family the Accord Suite. PACT (Protocol for Authority, Consent, and Transactions) negotiates requests. It checks the evidence, restrictions, and approvals that apply to each operation. The result moves through four distinct records:

• Claim: evidence of identity, a relationship, a duty, or a right. A claim alone grants no access.
• Contract: the accepted terms for an operation: who participates, which data or devices it affects, and what restrictions and approvals apply.
• Grant: machine permission with explicit limits, derived from the contract and installed where the action is controlled.
• Receipt: a record of the outcome. Different receipts establish whether an action ran, data was stored or disclosed, or notice reached its recipient.

A grant specifies the permitted operation, data, recipients, expiration, and resource limits. The component that owns the data or controls the final effect checks that permission when it acts. Changing a pointer, route, prompt, or request descriptor cannot create a right to another owner’s resources.

When claims conflict, PACT records the conflict and follows the applicable institutional procedure. That may mean denying a request, suspending it, or referring it for review. A signature establishes who signed a statement; it cannot settle whether a legal order is just or make unavailable encrypted data accessible.

Authority rules · PACT negotiation

Four active planes and an independent witness

The reference endpoint separates personal, civic, commercial, and untrusted activity. These planes have different purposes and authority rules. A legitimate civic service still needs permission to receive personal data.

This is the 4 + 1 endpoint: four active planes plus the Steles witness plane. Keystone separately protects local consent, trusted display and input, key custody, and recovery. It cannot assume the decision rights of a court, employer, or other institution.

The arrows show where authority is checked. They do not depict physical connections. The native high-assurance design requires protected compute, memory, and physical communication resources for the active planes. Independent guards check access at the boundaries. Any deployment that shares equipment must state which guarantees that sharing weakens.

Planes and Keystone · Physical substrate

Execution with limited reach

An Isolated Execution Stack (IES) owns assigned physical compute and writable-memory resources for a trust domain. Within it, a cell runs for a bounded lifetime. Separate services own persistent objects and external effects, including storage, display, network publication, and device commands.

A parser can therefore process a hostile document with private scratch memory and a limited output buffer. Even if an attacker takes over the parser, the independent guards must continue to deny foreign memory and ungranted actions. Memory reuse, delayed device access, reset, and revocation are part of that requirement.

Applications connect these components through explicit contracts. The implementation may use an existing processor and compiler if the surrounding ownership and effect checks satisfy the required profile. Physical isolation and conformance still require their own evidence.

Execution semantics · Memory lifecycle · Native applications

How the AI assistant works

The AI environment interprets requests, searches permitted context, drafts contracts, and builds candidate programs. Context owners decide what it can see. Separate checkers evaluate its proposals, and the services controlling each action enforce the resulting grants.

For an action requiring approval, Keystone presents the actual recipient, selected data, amount or resource limits, expiration, and relevant uncertainty. Approval binds to that fixed proposal. A changed payment account or substituted output needs a new authorization decision unless an existing bounded grant already covers the change.

Routine work can use standing grants: read a named collection, for example, and write drafts to a particular workspace within stated limits. The assistant cannot enlarge those limits, install its own grants, forge approval events, or approve a change to its own authority.

The security tests start with an attacker already controlling the planner, the component that proposes tasks. Owners and guards must enforce its limits while permitted tasks still work.

AI environment and trusted interaction

An invoice from the public Internet

An unknown supplier sends an invoice. Wilder receives it, and a disposable parser extracts selected fields within fixed size limits. Neither the supplier nor the parser has payment permission.

1. A guarded transformation proposes importing selected invoice fields into Agora.
2. An assistant compares those fields with a purchase order it is permitted to read.
3. PACT prepares a payment contract. Keystone displays the exact amount, recipient account, source information, restrictions, and fee.
4. After the required approval and business checks, a one-use grant permits the payment owner to debit the account or reject the request.
5. The user receives the outcome. Steles records a minimal witness commitment.

If tax reporting is required, a separate release contract defines the civic record sent to Polis. Settling an invoice does not give the revenue service access to the business’s customer list.

Worked transaction and attack scenarios

Networks and data release

ASKA extends purpose separation through household, campus, community, regional, and upstream networks. Local services may continue during some upstream outages. Their actual availability depends on installed links, reserved resources, power, and shared infrastructure.

Before data crosses a domain boundary, the source must authorize the exact output and its route. The recipient must separately agree to accept it. Permission to read is distinct from permission to export, print, or publish. The receiving system still confines its parser, even when the sender is authenticated.

Separate network names do not prove independent physical paths. A deployment claiming that independence must account for transceivers, queues, device memory access, switches, management, power, and upstream carriers. Shared infrastructure can remain an observation point or a common cause of failure.

Network fabrics · Cross-domain release · Protected delivery

Witness records and failure handling

Steles records protected evidence with a stated scope. It can retain a cryptographic commitment, which lets a later check verify a record without storing its plaintext in the witness log. Receipt types distinguish a proposed action from an executed action, a durable commit, a disclosure, or a delivered notice.

Witness outages follow the declared operating policy. An action may have to wait; a policy that permits bounded queued operation must report its reduced guarantee. A local record cannot establish that an offline recipient received notice.

Revocation stops future actions under the revoked permission. It cannot make a recipient forget information already received. A malicious insider can misuse an authorized disclosure, and a compromised guard or shared update authority can defeat guarantees within its reach. The threat model and dependency records must identify those limits.

Steles and notice · Compromise and failure cases

What the research must demonstrate

The specification defines staged work, from executable models to independently administered systems. Each stage must support useful authorized work while surviving the attacks it claims to contain.

A software model can test contract behavior without proving physical separation. A successful board experiment can establish properties of that apparatus without proving production cost or independence from its administrator. Results must distinguish requirements satisfied, assumed, unestablished, or violated.

The open work includes usable approval interfaces, authority conflicts, crash and revocation behavior, hardware independence, implementation cost, and useful applications that do not accumulate broad privileges. The research program must measure these properties before claiming success.

Research program · Validation and costs · Conformance tests

Read the technical specification

The GitHub repository contains 34 chapters covering authority, institutions, hardware, applications, networks, accountability, deployment, and validation.

Start with system architecture and requirements and threat model. Use the glossary for terminology and the transaction traces to follow the rules through complete workflows. The formal model sketch states the safety and liveness obligations that further work must establish.