A durable chart should remember the facts that explain its behavior. It should not become a serialized copy of every file, secret, connection, model, or external system that behavior touches.
Durable history
State, facets, accepted events, outcomes, and planned work.
Schema-encoded truthStable identities such as draft.md or customer-42.
Resource.acquire(key)Process-local execution
Raw output that must become a stable external identity.
Resource.OutputSecrets, handles, connections, and large external documents.
Resource.InputDurability is a selection, not a copy of memory
Motive can recover a chart because its committed state is Schema-owned data. That does not mean every value available to an Activity belongs in the commit. Durable state should contain the smallest complete explanation of the application: which state is active, which decisions were accepted, which outcomes occurred, and which external things those facts refer to.
A database connection cannot be recovered by decoding its JavaScript object. A secret should not be copied into every retained snapshot. A hundred-megabyte document may be valid data while still being the wrong unit for a chart timeline. Those values need durable identity, not durable material.
Keep identity durable and material local
A Resource gives one external kind three separate Schemas: a durable key, the process-local
resource acquired for an Activity, and—when the application creates external things—the local
material from which a provider produces a key.
That separation is useful even when confidentiality is not the concern. A chart can remember
draft.md, recover on another runner, and ask the provider to open the document again. It can
remember customer-42 without serializing an ORM session. It can retain an evidence id without
retaining the raw credential that created it.
Schema validation does not make a value safe to persist. The boundary is a product decision: durably encode the facts future execution must reproduce; keep ambient authority and replaceable material behind the Resource contract.
Resources own both directions across the boundary
Resource.Input marks a field whose authored value is a durable claim but whose Activity-side
value is the acquired Resource. The runner resolves the claim before invoking the Activity, then
releases the process-local value when that attempt leaves its scope.
Resource.Output points the other way. An Activity produces process-local output material; the
provider prepares a durable key, then confirms the committed Publish intent before the Activity's
Done outcome may be committed.
The chart therefore never needs a loose “load this later” convention. Input and Output placements preserve the Resource definition, field path, provider authority, and typed failure contract as part of the authored model.
Providers are authored authority
A Resource definition describes a capability; provide(...) mounts an occurrence of that
capability in the topology. A consumer is closed only when one compatible provider dominates its
whole active lifetime. Child charts carry open requirements upward until some ancestor can prove
that closure.
This is deliberately different from an ambient service lookup. The topology records who may acquire or create the external value, and runtime bindings implement only the provider occurrences the chart actually authored. Later, attenuation narrows what Resource authority a child may receive instead of handing the whole parent environment downward.
Choose the boundary you need
Where the category leads
Resource Boundaries decides what may cross between durable history and the outside world. Capacity & Settlement follows by deciding who may cross now, what happens under contention, and when a durable Resource may be consumed, expired, or erased.