Pipeline apps

Current managed contract

The current contract has a deliberate ownership boundary:

A coding agent may author changes inside the customer-controlled column. The customer reviews those artifacts before Redgold validates and deploys the managed application. Start with the artifact walkthrough.

The sections below describe how this managed backend grows into a portable application package. Their maturity tables distinguish current runtime behavior from component previews and planned distribution features.

A pipeline app expresses application behavior as artifacts the platform can inspect: typed records, dataflows, routes, transforms, datasets, and deployment state. The application contract adds page surfaces, client actions, synchronization policy, capabilities, and exact dependency pins. The managed registry and installation runtime load verified remote releases inside the shared Redgold web, Android, and iOS client code.

Mental model

flowchart LR
    Project["Logical app id"] --> Release["App release\nlocal compiler"]
    Release --> Schema["Rust serde schemas"]
    Release --> Pipelines["Pipeline specs"]
    Release --> Surfaces["UI surfaces\nlocal host"]
    Release --> Assets["Assets"]
    Release --> Policy["Capabilities + merge policy\nvalidated"]
    Pipelines --> Server["Engine + executor\ncurrent"]
    Surfaces --> Host["Shared Vue host\nweb + Android + iOS"]
    Policy --> Portable["Portable Rust/WASM dataflow core\ncomponent preview"]

The application envelope belongs above the execution DAG. A pipeline remains a reusable graph that can be invoked by several applications. An application release groups exact pipeline revisions with its schemas, surfaces, assets, and security policy. An installation pins one release for one workspace and records the capabilities that workspace accepted.

What exists at each maturity level

The five layers

1. Schema defines durable meaning

Checked-in Rust serde types define stored records and over-the-wire payloads. A dataset reference can carry a type URL and a pinned schema-descriptor hash, which lets a runtime distinguish revisions of the same logical type. Schema remains the source of field names, types, validation inputs, form generation, and merge policy.

This layer is current. See data and pipelines and the Developer Preview schema.

2. Pipelines define server behavior

A Dataflow is one relational execution. A registered PipelineSpec is a named DAG. A PipelineManifest is the readable TOML desired state that CI lowers into a runtime spec. Routes, reads, writes, subscriptions, schedules, and transform stages use this path.

Manifest authoring is Developer Preview and publication remains managed. See the pipeline manifest preview.

3. Transforms provide the escape hatch

The declarative target covers filter, project, map fields, validate, aggregate, join, sort, merge, and emit. The current strict compiler supports the unary subset and fails closed on two-input stages until the executor supplies an independent right-hand branch. A custom transform is appropriate when the operation needs domain code. Its ABI, input/output schemas, artifact digest, resource limits, and allowed host access form part of its contract.

Trusted Rust batch transforms and their content-addressed artifact pins are current. A deterministic client transform format that can use the same typed expression model is planned.

4. Surfaces define client behavior

The preview ComponentNode contract is a constrained component tree with typed data bindings and actions. A local Vue host prototype currently allowlists stack, grid, card, text, markdown, form, input, button, list, board, tabs, and navigation. Its golden collaborative-board fixture uses host-owned lower-snake-case callbacks such as create_card, open_card, and add_example_card.

The host validates component and action graphs and routes effects through injected host ports for pipeline invocation, entity operations, navigation, local state, capabilities, and events. The installed-package source fetches the tenant installation and verifier key over the authenticated service channel. It verifies both the immutable publication receipt and the registry-signed mutable installation projection before opening the shared durable runtime. The signed installation sequence prevents revision rollback. Within one sequence, the service atomically allocates and persists each attestation issued_at_ms while locking the installation and its exact transitive release closure. The runtime rejects an older projection, requires equal timestamps to reproduce the same projection hash, and retains root-release revocation or dependency-driven suspension as terminal state for that sequence and release. The checked-in fixture remains useful for local authoring. The descriptor-driven entity adapter validates and queues create, scalar edit, set-membership add/remove, move, and comment records. Authoritative batch hydration is folded with cached and queued state before rendering. Arbitrary descriptor-generated subscriptions and native host effects remain planned. The renderer lives in the canonical Vue application, which Capacitor packages for Android and iOS.

Portable action effects have a narrow v1 host contract:

• invoke_pipeline accepts an empty input, or one input value declared by the signed action config. A parameter binding names the input key, filter column, comparison (eq, neq, gt, gte, lt, or lte), and scalar kind (string, int64, double, or bool). The host converts that value into the executor's audited dataflow overlay; undeclared keys and type mismatches fail closed.
• query_entity accepts exactly one entity_id or a bounded entity_ids array. It uses the signed entity descriptor and installation-authorized batch endpoint, then returns { entities: [...] } in request order while omitting absent identities.
• emit_event dispatches a browser-local redgold:runtime-app:event with the installation id, verified app id, safe event name, and cloned payload. It creates no server or cross-application side effect.
• invoke_function remains publication-ineligible in runtime v1. Function artifact pins exist, while an authenticated host request/response contract and portable ABI input encoder do not.

The pipeline binding is authored on an invoke_pipeline action node:

[actions.nodes.config]
pipeline_input_key = "column_id"
pipeline_filter_column = "column_id"
pipeline_filter_operator = "eq"
pipeline_filter_value_kind = "string"

5. Releases and installations define distribution

The immutable-release contract pins every schema, pipeline, transform, surface, asset, capability, and dependency it needs. The local compiler lowers an app manifest, validates its graph, resolves each pipeline to an exact content hash, and writes deterministic CBOR and JSON release candidates. The resulting release hash is a publisher-independent package digest. Its installation contract records that exact digest, tenant scope, accepted permissions, and upgrade history. Managed publication verifies the publisher attestation and stores the immutable release and receipt. Tenant installation, upgrade, rollback, capability consent, revocation projection, and runtime write enforcement use that stored release identity. Every installation response also carries a fresh registry signature over its exact state, grants, release projection, revocation state, and revision sequence.

Discovery, installation, and data sharing are separate decisions. Installing an application does not expose another user's data. Dataset grants continue to control shared records independently.

The Apps UI exposes three library scopes. My apps combines authored Vibe projects with installations in the active workspace. Shared with me shows private app entitlements granted to the caller or workspace. Discover shows public catalog entries whose current release an operator approved. Owners can share a released app with an active trusted contact after that contact resolves to a joined workspace member; the share is an APP resource grant over the stable app_id. The recipient installs an independent copy into a workspace where they are owner or admin and explicitly accepts the release capabilities.

Public submission creates a pending catalog revision. Operators review its publisher, exact release, requested capabilities, tags, and description at /admin/apps. Approval makes that revision discoverable; denial records a reason and leaves private owner/grantee access intact. Review history is append-only while immutable release bytes remain unchanged.

Schema plus transforms

The authoring goal is a small common case:

schema       declares records and field policy
pipeline     declares reads, writes, subscriptions, and common transforms
surface      declares pages, bindings, and actions
custom UDF   supplies the domain-specific operation when needed
release      groups and pins the artifacts above

An agent can generate this bounded artifact set, and validators can reject unknown operations, missing schemas, undeclared capabilities, and unresolved references before publication.

Runtime placement

Hashes, versions, and signatures

A current PipelineSpec revision hash and author signature cover the canonical canonical CBOR encoding of its nodes, output node ids, and spec name. The human-readable version_tag, description, tags, registry latest flag, and timestamps are outside that content identity. An exact pipeline revision is therefore identified by spec_name + spec_hash, and an exact compiled transform by its artifact hash.

AppRelease.content_hash covers the canonical package graph and exact referenced hashes with content_hash, author_hash, author_signature, and the provenance publisher fields cleared. It is therefore independent of publisher identity. A separate publisher attestation binds signer identity to that digest. Canonical hashing is implemented for local release candidates; local inspection distinguishes an unsigned draft from registry verification.

Managed publication strictly decodes the wire bytes, rejects unknown fields and tags, binds the authored source to the normalized manifest and release digest, verifies the publisher attestation and referenced evidence, and issues the opaque receipt used by installation and remote loading. A signed pipeline alone does not authenticate a page layout, asset, dependency, capability request, or migration. Read release and security lifecycle for the full boundary.

Continue

• Collaborative board walkthrough shows how the complete target fits together.
• Release and security lifecycle covers signatures, permissions, installation, upgrades, sharing, and forks.
• Managed application artifacts defines the current customer-reviewed backend contract.
• Build a vertical covers the current repository implementation path in detail.