design: program, deployment and execution as three objects — an immutable program, a deployment that binds capabilities, policies, placement and triggers, and execution records; the readback, revision, import and delete contract that Terraform, policy revisions and drift detection need

Written against b015dc6.

Observed behavior

Three different things share one message and one startup path:

• Workflow carries the author's program, the compiler's stamp, deployment intent, the control-plane record and source provenance in fifteen fields (#1563's audit), so "the program" has no boundary a digest can mean anything over (#1569, #1232).
• Policy is process configuration read once at startup (cmd/flow/taskpolicy.go:55-80, egress.go:167, main.go:205), not a resource with a revision (#1590), so nothing can say which policy a run executed under.
• A schedule reads back the cadence the author wrote rather than the one the cluster enforces (#1890), and changing it is delete-and-recreate (#1666). The assessing pass's unpaused-schedule probe shows the shape: every still read one hour while next_run_times had two-hour gaps.
• A Terraform provider (#95, #559's journey) would have to reproduce cmd/flow's startup assembly (3,590 lines in main.go) to say what a deployment is, because no object names it.

Desired outcome

A design record deciding three objects and their relationships:

1. Program: immutable, content-addressed, exactly the fields #1563 classes as the author's program plus the compiler stamp. Says what the application does. The bundle of #1573 is its distribution form.
2. Deployment: binds a program to an environment: capability bindings (#1527), policy revisions (#1590), placement (#156), triggers (schedules, webhooks) and the tenant. Has a stable identity, a revision, desired and effective state, and structured diagnostics when they differ.
3. Execution: what actually ran, referencing the program digest and the deployment revision it ran under, so an audit record can name both.

Terraform then manages deployments and their triggers as stable resources with meaningful readback (effective state), revision checks (drift), import (by identity) and deletion semantics (what happens to in-flight executions). It should not need to reproduce the CLI's startup.

Acceptance criteria

• The record names, for every Workflow field in #1563's classification, which of the three objects owns it.
• One deployment can be described by an RPC and the answer distinguishes desired from effective state for at least schedules (#1890) and policy revision (#1590).
• An execution record carries the program digest and the deployment revision; flow get prints both.
• A drift case: change a schedule under Flowstate, describe the deployment, and assert the diagnostic names the drifted field.
• The Terraform journey in #559 is re-walked against the three objects and the remaining holes are listed.

Constraints and dependencies

• Adjacent: #1563, #1569, #1232, #1573, #1590, #1527, #1890, #1666, #107 (the control plane), #528 (one program model), #156, #95, #559.
• Invariant 1: the three objects are Protobuf messages; the YAML files are projections.
• Invariant 10: a deployment must be describable without any cloud dependency.

Open questions

1. Is a deployment per program or per environment holding many programs?
2. Does the policy revision live on the deployment or does the deployment reference a policy resource that revisions on its own?
3. What does deleting a deployment do to a running execution: nothing, cancel, or refuse until drained?

Start with the Workflow field classification in #1563, then read cmd/flow/taskpolicy.go, egress.go, and main.go to trace current startup assembly and policy handling. Re-walk the Terraform journey in #559 and the linked schedule and policy issues. Done means a design record assigning fields to Program, Deployment, or Execution and covering RPC readback, effective-state drift, execution references, import, and deletion semantics.