Release and security lifecycle

Portable applications add a software supply chain to the platform. A release can contain executable transforms, pages, actions, dependencies, and requests for data or device access. Reproducible hashes and explicit capability grants therefore belong in the base contract rather than in catalog policy added later.

Application identities and roles

Keeping these roles separate allows several installations to pin different releases while preserving one logical app and publisher lineage. Catalog visibility grants neither installation authority nor dataset access.

Current pipeline signing boundary

A current PipelineSpec content hash is BLAKE3 over the canonical CBOR encoding of:

nodes + output_node_ids + spec_name + cli

The author signature verifies that hash. The optional cli value contains the published command name, aliases, and help text; changing that surface creates a new content revision. version_tag, description, tags, latest, and timestamps are excluded. Changing those metadata fields does not create a new content revision. The stable revision key is spec_name + spec_hash; latest is a mutable registry pointer.

Function source and compiled artifacts have their own content hashes. When a pipeline carries pin_ast_hash or pin_artifact_hash, resolution must use that exact source or binary. A human version_tag remains useful for display and release notes, while the hash is the reproducibility boundary.

Application signing contract

AppRelease.content_hash is computed over canonical package bytes with content_hash, author_hash, author_signature, and the publisher identity fields in provenance cleared. It is a publisher-independent digest of the package graph. A separate publisher attestation binds signer identity to that digest. The local compiler implements canonicalization and deterministic hashing, then emits an unsigned candidate. Managed publication verifies the publisher attestation and referenced registry evidence before it stores the immutable release.

The shared release validator separates structural validity from publication evidence. Local callers can supply the authored manifest whose hash is carried by the release and prove the normalized resolved graph still matches it. The cryptographic/registry evidence fields are opaque and cannot be asserted by a caller. The release-bound verifier strictly rejects unknown schema fields and tags, binds authored source bytes and their hash to the exact normalized manifest and release digest, verifies the publisher attestation, and issues an opaque signed receipt. Local unsigned candidates remain inspectable and ineligible until they pass that managed boundary.

The canonical release is intended to cover:

• application identity and release format version;
• exact schema descriptor references;
• exact pipeline revisions;
• exact transform and asset artifacts;
• surface trees, bindings, actions, and navigation;
• dataset declarations and migration policy;
• capability requests;
• exact dependency releases;
• collaboration, offline, and compatibility policy;
• provenance and fork parent.

The release signature authenticates that full graph. Each referenced artifact also retains its own hash and signature, so an inspector can verify both the package and its components.

Lifecycle

flowchart LR
    Draft --> Validate
    Validate --> Sign
    Sign --> Publish
    Publish --> Install
    Install --> Run
    Run --> Upgrade
    Upgrade --> Run
    Run --> Rollback
    Rollback --> Run
    Publish --> Fork
    Publish --> Revoke

Draft

The author works with readable schema, pipeline, surface, and release files. References may use local paths or qualified names. rac app validate, build, and inspect exercise the local draft lifecycle. Drafts cannot be installed outside their development workspace.

Validate

Local validation rejects unknown TOML fields, malformed pipeline graphs, incompatible entity merge policies, unsupported v1 surface/action shapes, dangling references, undeclared effect capabilities, direct self-dependencies, and incompatible resolved dependency versions. Building also resolves referenced pipeline sources to exact PipelineSpec hashes. Resolved dataset sources and sinks must be covered by matching read/write capabilities. An http_fetch stage requires a matching network capability, and an authenticated fetch also requires a secret capability matching the referenced secret name. The same resolution check runs in rac app validate. Publication validation additionally rejects unknown schema fields and tags; binds authored source bytes to the exact normalized manifest, resolved package graph, and release digest; and verifies the transitive dependency graph, descriptor and artifact registry evidence, runtime compatibility, route ownership, publisher keys, and migrations through a release-bound receipt.

A local scaffold report may omit checks that need a registry. A publishable verdict is separate and fail-closed: a skipped required gate produces an incomplete release rather than a publishable one.

Runtime v1 also validates parameterized pipeline actions as a signed, four-field filter binding: input key, destination column, comparison operator, and scalar kind. Partial bindings are invalid. invoke_function actions are rejected at publication until the client host has an authenticated invocation transport and an ABI-compatible input/output encoder.

Sign and publish

The publisher attests to the publisher-independent package digest, binding its signer identity to those exact contents. Publication stores immutable release metadata, the attestation, content references, and the verifier's signed receipt in the managed registry. An owner can create a private catalog projection for trusted account or tenant grantees, or submit the exact current release for public review. Public discovery requires an operator approval recorded in the append-only app catalog review log.

Native function references are resolved against the dedicated DTS code registry. Pipeline execution and future runtime materialization require the exact function name, source-AST hash, artifact hash, ABI, symbol, target, and verification evidence. The registry keeps the function-to-artifact association append-only, so rebuilding the same AST cannot make an older signed release unresolvable.

Install

Installation validates the release and dependency closure, records accepted grants, registers its verified entity descriptors, and pins the exact release for a tenant. The registry signs the complete mutable installation projection, including its state, grants, projected revocation metadata, and monotonically increasing revision. Remote clients verify that attestation and the immutable publication receipt before persisting or activating the bundle. Discovery permission and installation permission are distinct.

The Apps UI lists owner, grantee, and approved-public catalog scopes. A private share grants read/discovery permission over the stable app_id; it does not copy the publisher's installation or widen access to the publisher's datasets. Installation into the active workspace still requires tenant owner/admin authority and explicit acceptance of every required capability. Trusted contacts become eligible share targets only after their email matches an active, authenticated workspace member.

The attestation issuance time is a second monotonic replay barrier within a single installation revision. The registry allocates it from persisted state while locking the installation, root release, and sorted transitive dependency closure. Clients reject older issuance times, require an equal issuance time to carry the same bundle hash, and retain a verified root revocation or dependency-driven suspension as terminal for that sequence and release.

Upgrade and rollback

An upgrade diff groups changes by:

• schemas and migrations;
• pipeline and transform revisions;
• pages, bindings, and actions;
• dependencies and assets;
• newly requested or broadened capabilities;
• compatibility with stored data and the client runtime.

The installation pin moves only after validation and approval. Rollback points to a previously accepted compatible release. Append-only data and operation history remain intact.

Fork and revoke

A fork receives a new project and publisher identity with provenance pointing to the source release. Data is copied or granted through a separate explicit operation.

Revocation blocks new installation and dependency resolution. Existing installations follow policy: warn, quarantine, disable, or roll back to a known release. The decision and reason remain auditable.

Capabilities

Capabilities are names and scoped parameters, never embedded credentials.

Dependencies contribute their own capability requirements. Installation shows the transitive closure and records which release requested each grant. An upgrade that broadens that closure requires renewed approval.

Server and client execution boundaries

The server remains authoritative for identity, authorization, secrets, privileged network access, large dataset scans, and durable writes. Deterministic client expressions may run over rows already available to the installed application. Optimistic client operations become authoritative only after server acceptance.

WASM has three separate maturity boundaries:

• A feature-gated server request-handler host is implemented with local unary, streaming, and WebSocket fixtures. Production routing does not currently select it.
• The deployed dataflow executor provides a default-on, capability-limited Wasmtime UDF tier with fuel, memory, and wall-time bounds and no WASI. Its other callable tiers are built-in operations, trusted native batch transforms, and Firecracker isolation for opted-in untrusted native/Python workloads. The backend is implemented; the first WASM route remains staged for publication.
• The portable Rust/WASM runtime verifies strict installed bundles, binds durable canonical-CBOR state to the installation/tenant/user/site identity, queues and replays CBOR entity operations through Capacitor Preferences, preserves state across a verified release rebind, hydrates exact entities in batches, and sends causal metadata to the descriptor-bound server merge path. Custom client transforms and arbitrary descriptor-generated subscriptions remain planned.

The authenticated service response supplies the registry verifier key. The runtime pins that key with the durable bundle and refuses replacement or sequence rollback. Offline use therefore inherits the trust of the previous authenticated exchange. Persisting the key beside the bundle cannot defend against an attacker who can replace the complete local storage record; a native hardware-backed trust anchor would be a separate host integration.

Registry signing-key rotation retains receipt continuity. Atomically replace the existing DATA_ENGINE_SIGNING_KEY_FILE contents with one 64-hex seed per line: the new current seed first, followed by every retained prior seed. The optional DATA_ENGINE_SIGNING_KEYRING_FILE can hold additional retired seeds. Keep an old seed available while any installed release receipt names its public key; installation refresh and lifecycle updates fail closed when that exact key is unavailable.

These paths may share artifact and ABI primitives. Their deployment status and capability sets remain explicit.

Data sharing

Application sharing and dataset sharing solve different problems:

• catalog visibility lets a principal discover release metadata;
• installation permission lets a workspace pin and run a release;
• dataset grants let principals read selected application data;
• write authority remains a separate scoped grant and server policy;
• public data visibility does not imply public application publication, and a public application does not imply public user data.

The existing append-only dataset-share record, grant id, catalog review verdict, and soft revocation provide the starting primitives for shared app data. Application discovery and installation grants are implemented separately from dataset access, so sharing an app never grants its data implicitly.

Publication gates

A release is eligible for managed publication only when:

1. its wire bytes contain no unknown schema fields or tags and reproduce the claimed package digest;
2. its authored source bytes or source hash bind to the exact normalized manifest and resolved release graph;
3. every artifact is available under its declared hash;
4. every pipeline parses, lowers, and resolves exactly;
5. every schema reference and binding type-checks;
6. every requested capability is declared and reviewable;
7. dependencies are exact, acyclic, and compatible;
8. migrations are additive or carry an approved explicit procedure;
9. the golden application conformance suite passes for the affected contract;
10. the release has a supported client/runtime compatibility range;
11. the catalog audience and revocation policy are set;
12. the publisher attestation verifies against the package digest and signer identity;
13. the verifier returns the opaque receipt bound to all of this evidence.

A local unsigned build cannot produce that receipt by itself. The managed publication path issues it after the registry-backed checks pass; public self-service publication remains future work.

The first public proof is the collaborative board. Return to the Pipeline Apps mental model for the artifact overview.