On this page
Development

Reference Host

Informative implementation guide, not an additional conformance profile.

Authorization

The agreed Host authorization design uses execution-account settings and allow / deny / delegate. Local can use one execution account; Cloud can delegate application-user authorization without registering every user in Core. Immediate delegation answers need no dummy Checkpoint; deferred answers use the existing durable continuation. Human approval and application routing belong to the Host. Conflicting account settings are errors, not a rule-priority system.

Encrypted evidence, secure defaults, retention and recovery guarantees remain unchanged.

The OSS authorization behavior draft details Local configuration, immediate/deferred adapters, CLI resolution and crash recovery. Its pending product choices are not changes to current defaults.

Adopted local product boundary

The official Local Host target includes durable execution, encrypted private evidence, scoped authorization and secure key/store/policy defaults without asking ordinary users to paste secrets during setup. There is no ephemeral API that silently abandons those guarantees. Private storage and the logical-item ledger are part of the Host execution contract.

The Host retains logical request fingerprints and item reservations, fences workers, reuses original Preview/dispatch keys during recovery and reconciles uncertainty before resend. SQLite or a Cloud store is an implementation choice, not provider exactly-once evidence. Engine and contract pins survive review waits. Stages can span several tasks; task scheduling does not redefine stage success.

Resolved allow can authorize independent multi-Effect stages without human checkpoints or mandatory risk claims. If a Host requires a risk claim for delegation, authenticate and bind it to the decision's exact scope. Target drift tolerance issues a new Preview and renewal authorization under explicit finite Host rules. Private inspection independently checks data-read scope even for approvers; keys themselves are never inspectable. SDK progress distinguishes accepted, provider-completed and Program-completed states. Single-row/value access checks exact arity and does not truncate Results.

Follow-up connection and recovery defaults

The revised target runs stages through the common Run Graph scheduler, with ordinary local-unit admission and separately authenticated graph membership. Changing a downstream notification preserves unchanged upstream templates; launching a new revision still needs admission, and success reuse needs an explicit recovery link. Semantic risk and cumulative actual spend are useful Host routing inputs, not mandatory restrictions on application authorization. Decision reuse and optimization must preserve the bound scope, context and validity of the actual decision inputs.

The proposed mail-attachment connection preset issues unlabelled captures as confidential when the published policy permits that default. Stronger parent policy wins; unknown labels/missing defaults fail. Configure an admitted model destination/account/region/training policy once at connection setup, not by asking for classification per PDF. The supplied fake preset is not proof that live Gmail/model integrations meet these terms; live setup remains explicit.

Operator recovery UI offers “exceptionally commit this captured range”, not “mark successful”. Show exact unmet duties, outcomes, loss/delay risks and abandon/handoff destinations. It requires separate current operator authority, fencing, signed state-bound claim and durable ownership transfer before ack. Unknown retains reconciliation obligations; business allow cannot release it. Source batch ownership prevents refetch under a fresh request id as recovery. Stamp bookkeeping writes appear separately beside business writes and their combined permissions are checked without switching to a stronger service identity.

Collection integration admission

The Host snapshots the Program and options before asynchronous authorization, requires concrete bindings, and admits an immutable private request. This contains canonical bindings, the exact Check Environment, bound identities, checked Plan, input materializations and provenance. A Host receiving or rechecking this request verifies the bound environment and request before dispatch; a different environment or changed input/binding is a mismatch, not permission to start a different invocation. The helper does not replace current authorization.

Local schema snapshots use actql-local-input-schema/0.1 and retain the actual checked schema. Local Relation snapshots pair completeness with a materialization CID when a capture is claimed, retaining the IntegrationBinding CID when applicable; static-only schema evidence omits those claims without implying empty or complete data. Compilation checks recursive assignability to the authored declarations and uses the stronger schema as checking evidence without rewriting Program source.

Durable local execution

The Execution specification owns capture, admission, replay and outcome guarantees. The Run protocol owns Checkpoint and Resolution envelopes. The Artifacts protocol owns retained Result delivery and reference availability.

The local Host realizes durable decisions and continuation claims through its storage interface. It commits verified Resolution storage, Checkpoint closure and the resume intent together. Claim identity prevents a stale worker from completing a newer claim. This does not make an external provider mutation exactly-once: unknown outcomes still require reconciliation.

Result delivery uses its own durable request/attempt ledger. A completed delivery is not dispatched again by status polling. Uncertain publication remains unresolved; it is not treated as a safe failed retry.

Collection's finite serial Host API reserves remaining consumption before dispatch and uses a Host-provided durable compare-and-swap callback. The callback is an implementation port for the Collection protocol, not a requirement to implement a general Run Graph scheduler.

This editorial split does not relax the existing transaction requirements. Replacing them with storage-independent transition guarantees requires a separately reviewed semantic change and failure/concurrency evidence.

Installed Effect cleanup

The installed Effect Site retains target-read authorization, input pins, physical execution, prepared-payload release and provider-stage disposal as separate cleanup duties. Its completion is their conjunction. Revoking further use does not prove that a callback, borrow or physical release has finished. Consumer pins are released before Compute reclamation; completed child duties are not invoked again while another child remains pending.

Target-read gates expose their existing authorization owner's synchronous close, cleanup and cleanupPending facts. An in-flight delegated decision can outlive timeout or abort, so close() === false remains pending until that same owner confirms completion. A close-only child must be synchronously retryable: a normal return other than false confirms release; false or an exception retains that child for another close attempt. Cleanup never reruns Compute, provider dispatch or authorization. Construction failure transfers any already-held, unfinished gates through the existing cleanup-handle protocol. The dispatch owner may record physical stop and retire custody only after every retained child confirms completion.

Standard Local configuration

A standard Local project uses actql.config.json for Program-facing project configuration and host.json for Host-owned connections, credentials and policy references. actql init creates a selected project template; creating files does not start a Run, acquire business data, call a model or apply an Effect. The public configuration reference owns these filenames and user-facing options.

Absent account_config uses the explicit, durably adopted standard Local bootstrap defined by execution policy routing. Reads from configured connections and registered INFER tasks are allowed; Effects delegate to effect_policy, defaulting to review. An explicit account deny always prevents dispatch. Project configuration never grants itself authority, and an invalid configured policy never falls back to these defaults. Mock fixture replacement remains explicit and cannot substitute fixture credentials or permissions into a real connection.

Source: actql/actql/docs/design/reference-host.md at d904416674e4 · Edit on GitHub