The machine in reference · Volume 06

Volume 06 — Bind Descriptors: Gather, Judge, Publish

CURRENTsnapshot of 14 July 20267 min read← Volume 05 — Activation Knots Volume 07 — The Membrane and Output Controllers →

Reading aids · CoAgnes LabNot part of the specification; where they differ, the volume governs.

At a glance

The bind as one scoped expression: understanding enters through exactly two channels — the activation and the demands; at the barrier (currently all) the bound names become simultaneously available; gates are predicates over the bound scope; and either the service's integration or the verdict of rejection is published. §1
The two descriptor forms of the current machine: the emit descriptor — one activation, no demands, no gates, one fact carrying the activating knot's snapshot at every readiness — and the operator bind — activation, demands, gates and a service crossing the membrane. §2 §3
The rendezvous algorithm: one state per key lane; a latching barrier, met by the presence of every demand name, not by simultaneity; gates in declared order, the first failure winning; one projection per key — a machine-complete service intention, or a bind.rejected verdict, terminal for that rendezvous. §4 §5
The two delegated emit declarations: writes — the discharging controller publishes the validated result as one fact of the declared type — and unfold — the result instantiates a declared template: knot records, the closing bind once, head facts, in exactly that order, each emission stamped emittedBy. §6 §7
A third emit form, cell (PROPOSED) — mutually exclusive with the other two, leaving binds and the rendezvous algorithm unchanged — and the reference operator bind, abridged, as a demonstration. §8 §9

Where it sits

Read after: Volume 02 — Machine Model and the Architectural Register File Volume 04 — Tuple Reference Volume 05 — Activation Knots
Read next: Volume 07 — The Membrane and Output Controllers
Requirements: 2 sentences with MUST, SHOULD or MAY — the list
At work: 4 of its sections seen in a real run of the machine, each linked under its heading
Across the set: every volume's questions the machine in figures

Questions this volume answers

Through which channels does understanding enter a bind? §1
How often does an emit descriptor publish? §2
Which readiness tuples wake an operator bind? §3
Must the demands be ready at the same moment for the barrier to be met? §4
Can an operator bind project twice on the same key? §4
What happens when a gate fails — can the bind try again? §5
Who publishes an operator bind's result — the bind or the controller? §6
In an unfold, what does the model supply, and what is fixed in advance? §7

A bind descriptor is a bind: woken by an activation knot's readiness, it gathers named understandings from the space, judges them in that bound scope, runs a service, and publishes an integration. It never returns a value privately — publication is the composition mechanism. This volume specifies the two descriptor forms of the current machine (emit descriptor, operator bind), the rendezvous algorithm, gates, service intentions, and the two delegated emit declarations including the topology-sowing template.

§1. The bind as a form

Conceptually every bind is the same scoped expression:

bind {
  <name₀> ← ⟨activation: knot A⟩
  <name₁> ← ⟨demand:     knot D₁⟩
  …
} at barrier(all)
in if gates(name₀ … nameₙ)
   then emit    = service(name₀ … nameₙ)      — the integration, published
   else reject                                  — the verdict, published

Understanding enters a bind through exactly two channels: the activation (the one knot whose readiness wakes it) and the demands (named bindings to knots whose integrations it gathers). The barrier is the rendezvous at which the bound names become simultaneously available; gates are predicates over the bound scope; the service is the function evaluated over the scope; the current barrier policy is all.

§2. Emit descriptor (`action: emit`)

Seen at work Fragment 3 · #1 · the first fragment's doer

Status: CURRENT. The minimal bind: one activation, no demands, no gates; its service is the identity over the activation understanding.

Registration payload: {id, subscribesTo, actionConfig: {writes}} (Vol. 04 §2.2). Execution:

On activation {knotId, key, understanding} emit exactly one fact of the declared type on the same key: {factType: writes, data: {triggeredBy: [knotId], understanding}}.
The payload MUST be truthful — the activating knot's snapshot, never invented values.
Emit descriptors are not one-shot: every readiness of the subscribed knot produces a publication (pair with knot reset policy deliberately).

Limitation fixed by the current stage: emit-descriptor output carries triggeredBy but no bind-level uid; it is therefore not accepted where publication provenance is required (a rule the Cell extension states for results, Vol. 12 §5.3).

§3. Operator bind (`action: operator`)

Seen at work Fragment 1 · #1 · a doer is described

Status: CURRENT. The full bind: activation + demands + gates + service crossing the membrane. Configuration (carried in the registration record and echoed into every intention):

type OperatorBindConfig = {
  on?: string;             // activation knot id; absent = demands-only bind
  on_as?: string;          // scope name of the activation entry (default 'activation')
  demands: readonly { as: string; knot: string }[];
  gates?: readonly { scope: string; min_grade: number }[];
  service: {
    instruction: string;   // the operator instruction
    schema?: JsonSchema;   // embedded result contract (required for unfold)
    emit: { writes: string } | { unfold: UnfoldEmitTemplate };
  };
};

Interests: the bind registers under its activation knot and under every demand knot — it is woken by each of those readiness tuples. subscribesTo (the executor's nominal subscription) is on, else the first demand's knot, else the bind's own id.

§4. Rendezvous algorithm

Seen at work Fragment 1 · The doer opens its rendezvous

One rendezvous state per key lane (registers of Vol. 02 §4.5). On each activation {knotId, key, understanding}:

 1  S ← RDV[key]            (create: ACTIVATED = (on undeclared), SCOPE = ∅, PROJECTED = false)
 2  if knotId = on:            S.ACTIVATED ← true;  S.SCOPE[on_as ?? 'activation'] ← understanding
 3  if ∃ demand d: d.knot = knotId:                 S.SCOPE[d.as] ← understanding   (latch/refresh)
 4  if S.PROJECTED ∨ ¬S.ACTIVATED:                  return []
 5  if ∃ demand d: d.as ∉ S.SCOPE:                  return []          (barrier 'all' not met)
 6  S.PROJECTED ← true;  scope ← snapshot(S.SCOPE)
 7  for each gate g in declared order:
        grade ← scope[g.scope].grade
        if grade is not a number ∨ grade < g.min_grade:
            return [ bind.rejected {bindId, reason} ]                  (first failure wins)
 8  INTENT.CTR += 1;  uid ← "<bindId>#<INTENT.CTR>"
 9  return [ service.request {bindId, uid, instruction, scope, schema?, emit} ]

Lab fig. 06·1 One operator bind, one key lane: the activation knot's readiness marks the lane activated and fills its scope entry; each demand knot's readiness latches its named entry, and a later one refreshes it until projection. Once the lane is activated and every demand name is present — presence, not simultaneity — the scope is snapshotted, the gates run in declared order and the lane projects once: a service.request, or bind.rejected at the first failing gate; later readiness is absorbed silently. A reading aid by CoAgnes Lab; §4 governs.

Normative points:

Latching barrier. A later readiness of the same demand refreshes its scope entry until projection; the scope snapshot at step 6 is what gates and the service see. The barrier is met by presence of all demand names, not by simultaneity.
One-shot per key. PROJECTED latches on both outcomes (intention or rejection). The rendezvous never reopens in the current machine; revision patterns create fresh binds instead (Vol. 12 §6, blind spot §11.4 of the design proposal). Repeated readiness after projection is absorbed silently.
Gate semantics. A gate reads the top-level grade field of the named scope entry — the convention that knot understandings expose their sufficiency as grade (deterministic understandings without one simply fail a gate). Richer gate expressions are an extension rail (Vol. 11 §4.5).
Machine-completeness. The projected intention carries scope, instruction, schema, and emit declaration in full: the bind is complete at projection, and completion is the controller's commit. Nothing about the bind needs to be consulted afterwards.
A demands-only bind (on absent) is activated from creation and projects as soon as all demands are bound; an activation-only bind (demands: []) projects on activation immediately.

§5. Judgement and rejection

Gate failure publishes bind.rejected {bindId, reason} on the activation key (Vol. 04 §3.2), carrying the first failing gate's reason. Rejection is a published verdict — visible, bindable (a guard or journal may collect it) — and terminal for that rendezvous. There is no retry at this station.

§6. Delegated emit: `writes`

Seen at work Fragment 1 · #4 · the note is released

The simple declaration emit: { writes: T } instructs the discharging controller to publish the validated result as one fact of type T, key preserved, data: {bindId, uid, result} (Vol. 04 §5.3). Publication by proxy keeps the station rules intact: the bind judged and projected; the controller merely commits under the declared form.

§7. Delegated emit: `unfold` — sowing topology

Status: CURRENT. The constrained in-wave authoring form: a service result instantiates new topology from a declared template. The model (or other oracle) supplies only the items; the pipeline fixed the record shapes, ids, schemas, and closing form at authoring time.

Lab fig. 06·2 An unfold, instantiated controller-side after schema validation: the model (or other oracle) supplies only the items; the pipeline fixed the record shapes, ids, schemas and closing form at authoring time, in the declared template. The batch is emitted in exactly this order — a knot record per item, the closing bind once, a head fact per item — so that registration precedes the facts that reach it. Records stand on key null, head facts on the intention key, and every emission carries emittedBy, the sowing intention's uid. A reading aid by CoAgnes Lab; §7 governs.

type UnfoldEmitTemplate = {
  for_each: string;                       // answer field holding the items array
  knot: { id: string; strategy: 'semantic_evaluator'; config: Record<string, unknown> };
  head: { writes: string; data: Record<string, unknown> };
  close: {
    id: string;
    demands_from_items: { as: string; knot: string };  // both contain {index}
    gates?: readonly OperatorGate[];
    service: OperatorServiceConfig;                    // emit must be 'writes'
  };
};

Instantiation algorithm (controller-side, after schema validation):

 1  items ← result[for_each];  if not a non-empty array → service.failed
 2  contexts ← [{index: i+1, item: items[i], scope} for i in 0..|items|-1]
 3  emissions ← for each context: sys.knot.defined
        {payload: substitute(knot, ctx) + emittedBy: uid, key: null}
 4  emissions += one sys.descriptor.defined
        {id: close.id,
         operator: {demands: [substitute(demands_from_items, ctx) for each ctx],
                    gates?, service: close.service},
         emittedBy: uid, key: null}
 5  emissions += for each context: domain.fact
        {factType: head.writes, key: intention key,
         data: substitute(head.data, ctx) + emittedBy: uid}
 6  return emissions in exactly this order: knots, close, heads

Normative points:

Order is load-bearing: knot records first, the closing bind once, head facts last — registration always precedes the facts that reach it (Vol. 02 §5.1).
Placeholders. {index} (one-based), {item.path…}, {scope.path…}. A string that is exactly one placeholder keeps the resolved raw type; embedded placeholders stringify (non-strings as JSON). A placeholder resolving to nothing aborts instantiation (→ service.failed).
Static coherence is checked at compile time: every {item.*} path must exist in the declared items schema; every {scope.*} must name a bound scope entry; knot and demand templates must contain {index}; the closing service's emit must be a simple writes (no recursive unfold at this stage); an unfold requires the service schema (Vol. 09 §5).
Provenance. Every emission carries emittedBy = the sowing intention's uid. The topology ignores the stamp; trace derivations and the proposed Cell ownership rules rely on it (Vol. 12 §4).
Termination. The fan-out is bounded by the schema (maxItems where declared); extensions performing admission MUST bound worst-case fan-out statically rather than trusting one answer (Vol. 12 §6, check 13).

The canonical figure produced by an unfold — question cells + closing harvest bind + head facts seeding each cell — is treated as a construct in Vol. 10 §6.

§8. Third emit form (PROPOSED)

The Cell extension adds emit: { cell: CellEmitDeclaration } as a third, mutually exclusive variant: the validated result is treated as a CellBlueprint and wrapped, together with parent-owned Charter/policy/context, into a cell.seed (Vol. 12 §3). Binds and this volume's rendezvous algorithm are unchanged by it — the declaration passes through the intention like any other emit form, which is precisely why the extension can live on these rails.

§9. Demonstration: the reference operator bind (abridged)

class OperatorBind implements IDescriptorExecutor<AnyEmission> {
  readonly id: string; readonly subscribesTo: string;
  private readonly states = new Map<string | null, RendezvousState>();
  private intentionCounter = 0;

  execute(a: DescriptorActivation): readonly AnyEmission[] {
    const s = this.stateFor(a.key);
    if (this.config.on === a.knotId) {
      s.activated = true;
      s.scope.set(this.config.on_as ?? 'activation', a.understanding);
    }
    const d = this.config.demands.find(d => d.knot === a.knotId);
    if (d) s.scope.set(d.as, a.understanding);              // latch / refresh
    if (s.projected || !s.activated) return [];
    if (this.config.demands.some(d => !s.scope.has(d.as))) return [];
    s.projected = true;
    const scope = Object.fromEntries(s.scope);
    const rejection = this.judge(scope);                     // first failing gate
    if (rejection !== null)
      return [fact('bind.rejected', a.key, { bindId: this.id, reason: rejection })];
    const uid = `${this.id}#${++this.intentionCounter}`;
    return [fact('service.request', a.key,
      { bindId: this.id, uid, instruction: this.config.service.instruction,
        scope, ...(this.config.service.schema && { schema: this.config.service.schema }),
        emit: this.config.service.emit })];
  }
}

Reading aids · CoAgnes LabNot part of the specification; where they differ, the volume governs.

Requirements in this volume

Every sentence of the volume with MUST, SHOULD or MAY, as it stands, with the section it stands in. These key words mark its conformance requirements; the rest of its text is descriptive (Vol. 00 §4).

MUSTThe payload MUST be truthful — the activating knot's snapshot, never invented values.§2
MUSTTermination. The fan-out is bounded by the schema (maxItems where declared); extensions performing admission MUST bound worst-case fan-out statically rather than trusting one answer (Vol. 12 §6, check 13).§7