Are you an LLM? Read llms.txt for a summary of the docs, or llms-full.txt for the full context.
Skip to content

ENC Flow

ENC Flow is the enclave-resolution engine. It bridges UI authoring, ephemeral dev backends, and helper configs into the protocol-canonical AppSpec — the definition the rest of the pipeline consumes. It is where an app's declarative manifests are derived and reconciled.

How it works

Flow owns four spec-pinned responsibilities:

  1. UI → AppSpec. A resolver reads ui.json + flow.json + enclaves/*.json and derives the canonical schema.json → app.json → infra.json. flow.json is the source of truth (encryption, tableMap, derived fields, sources, enclaves); each later file is a pure function of the ones before it — so you can hand-author schema.json and skip the UI inputs entirely.
  2. Ephemeral → real. UI-Kit "ephemeral" mode flushes through Flow's resolver into real protocol events that must be byte-equal to direct commits — an app behaves identically whether driven through the dev backend or the real node.
  3. Helper-config bridge. Actions, reads, derived views, plugin bindings, validators, aggregators, notifiers, and migrations become first-class AppSpec fields.
  4. DataView runtime. Flow serves the cross-enclave reads (dataviews) that public apps project from.

What makes it sound

Each derivation stage is a pure function of its inputs, and the whole chain is spec-pinned in the app-codegen formalization: the ephemeral-vs-direct equivalence is a named invariant (events must be byte-equal), and the helper-config extension to the AppSpec is formalized too. So "author in the UI" and "author the schema directly" converge on the same canonical AppSpec, and "run in dev" and "run in prod" produce the same events.

See also