Promise Creation Protocol¶
Construction protocol — instantiates Deferred Fulfillment Placeholder
Mints the deferred placeholder — a handle bound to an expected value type, a responsible fulfiller, and an initial pending state — before the value it stands for exists.
Every deferred value has to be born before anyone can wait on it, and Promise Creation Protocol is the birth certificate. It is the constructor step that turns "a value will arrive later" into a concrete, passable object: it allocates a stable handle, records what would count as fulfillment, names who or what is on the hook to supply it, and stamps the object as pending from the first instant. Its defining move is that it produces a placeholder that is deliberately empty — it holds no value yet and must never be mistaken for one. Everything downstream (waiting, resolving, cancelling, auditing) depends on this object existing first, so creation is the mechanism that establishes identity and obligation, and nothing else. It does not resolve, observe, or expire the placeholder; it only brings a well-formed, still-pending one into the world.
Example¶
A web app lets a user request a large export of their account history. The server can't produce the file in the split-second the request arrives, so the request handler runs the creation protocol instead of blocking. It allocates a handle — export/9f2a — that the client can hold and re-query. It records the expected value specification: a downloadable ZIP, roughly this schema, ready to fetch once built. It binds a fulfillment commitment: the background export worker pool is the responsible producer, and the job is enqueued to it. And it writes the initial pending state: status: pending, created_at: 14:02:10, distinct from any success or error the object might later carry.
The handler returns export/9f2a immediately. The user sees "your export is being prepared," the client can navigate away and come back, and the worker can pick the job up whenever it has capacity. Critically, the object that came back is not the file — dereferencing it now yields "still pending," not an empty ZIP. That single discipline is what lets the rest of the system coordinate around the export honestly instead of pretending it already exists.
How it works¶
Creation is a short, ordered construction sequence, and its whole art is doing exactly these steps and stopping:
- Allocate identity. Generate a handle that is unique, stable, and referenceable independently of the eventual value — often before any work has begun. This is what lets the placeholder be passed across boundaries and stored.
- Specify the expected value. Record the type and acceptance criteria of what will fulfill the promise, so later a resolution can be checked against "is this actually the thing we promised?"
- Bind the commitment. Attach the responsible producer, resolver, or condition — the answer to "who owes this, and under what obligation?" — so accountability exists from birth.
- Initialize pending state. Set the lifecycle to an explicit
pending, timestamped, visibly not-yet-a-value.
The protocol then hands the handle back and steps aside. It does not attach consumers, decide who may resolve, or set a deadline — those are separate mechanisms acting on the object it created.
Tuning parameters¶
- Identity scheme — opaque token, content-addressed hash, or human-readable slug. Opaque tokens leak nothing and can't be forged from guessable inputs; readable slugs are auditable and debuggable but invite enumeration.
- Specification strictness — how tightly the expected value is typed at creation. A tight spec catches a wrong-typed resolution later but is brittle if requirements shift; a loose spec is flexible but weakens the "is this really fulfillment?" check.
- Commitment strength — whether the bound fulfiller is a hard obligation, a best-effort producer, or merely a named condition. Stronger commitments support accountability; weaker ones fit speculative or cancellable promises.
- Eager vs. lazy fulfiller dispatch — enqueue the producing work at creation, or defer it until the first consumer actually waits. Eager cuts latency; lazy avoids doing work no one ends up needing.
- Pre-population of pending metadata — how much context (owner, ETA, correlation IDs) is written at birth versus filled in later.
When it helps, and when it misleads¶
Its strength is that it manufactures a first-class deferred object — a future[n1] you can name, pass, store, and reason about — so consumers stop blocking prematurely and stop confusing a promise with possession. Getting creation right is what makes the entire lifecycle auditable, because every later event hangs off the identity minted here.
Its characteristic failure is the orphan placeholder: a handle created with no real fulfiller behind it, or with a commitment so vague that nothing can ever resolve, fail, or expire it — a pending state with no path out. A classic misuse is minting placeholders to make an interface feel responsive while quietly having no worker actually assigned, so the promise is a facade. The guarding discipline is a creation-time invariant: refuse to construct a placeholder unless some named party, process, or condition is genuinely capable of resolving it, and unless a later mechanism owns its expiry. Create nothing you cannot, in principle, complete or kill.
How it implements the components¶
Promise Creation Protocol fills the origination components — the ones that must exist before any other mechanism can act:
placeholder_identity— allocates the stable, referenceable handle that is the placeholder.expected_value_specification— records the type and acceptance criteria that define what fulfillment would be.fulfillment_commitment— binds the responsible producer, resolver, or condition behind the promise.pending_state_record— writes the explicit, timestampedpendingstate the object starts in.
It does not implement resolution_authority_rule, terminal_state_model, idempotent_resolution_guard, or resolution_evidence_record — those belong to the resolution-side twin, Resolution Event Commit, which acts on the object created here rather than creating it.
Related¶
- Instantiates: Deferred Fulfillment Placeholder — creation is the origin step every other mechanism depends on.
- Sibling mechanisms: Resolution Event Commit · Await or Subscription · Callback or Continuation Registration · Pending State Polling · Cancellation Propagation · Failure Propagation · Dependency Graph Scheduling · Resolved Value Memoization · Timeout Expiration Handler
Editorial Notes¶
Form Classification¶
Form family: Protocol, Workflow & Routine
Rationale: Promise Creation Protocol operates as a repeatable ordered procedure or handoff sequence that coordinates action because it mints the deferred placeholder — a handle bound to an expected value type, a responsible fulfiller, and an initial pending state — before the value it stands for exists.
Independent corroboration: The frozen evidence defines Promise Creation Protocol as 'Mints the deferred placeholder — a handle bound to an expected value type, a responsible fulfiller, and an initial pending state — before the value it stands for exists', so its operative form is Protocol, Workflow & Routine.
Nearest alternative: Representation, Specification & Plan — Promise Creation Protocol includes features of a static representation, map, specification, schema, or prospective plan that externalizes information, but its defining operation is a repeatable ordered procedure or handoff sequence that coordinates action.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Single lineage
Present-day reach: Specialized
Rationale: Promise Creation Protocol is most plausibly rooted in the computer_science tradition because its characteristic form depends on algorithms, data structures, formal interfaces, and software-system practice. The assignment tracks that formative lineage, not the many settings in which the mechanism can now be applied.
Review outcome: Independent reviewer agreement; high confidence.
Notes¶
Creation is deliberately incapable of finishing what it starts — it cannot resolve the placeholder it mints. That asymmetry is the point: separating who may create a promise from who may resolve it is what keeps a producer from both making and secretly fulfilling its own obligations, and it is why resolution_authority_rule lives with the commit mechanism, not here.
[n1] The future (or promise) as a first-class construct — a value a computation will supply later, usable as a reference before it exists — traces to the 1970s Actor-model lineage and Multilisp; the placeholder minted here is that construct made general across software and institutional settings. ↩