ControlFeedbackLoop.md

CAT Node's Control-Feedback Loop:

Control-Feedback Loop Specification:

The Control-Feedback Loop is how a CAT Node operationalizes its Architectural Quantum as a Minimal Federated Operating Model. The Ordering of Execution that is Invoiced into a Bill-Of-Materials loop is the Node's runtime realization of the Quantum Architecture Description in the README Function / Process / InfraFunction and Structure / Plant / InfraStructure are independently content-addressed halves of one deployable Data Product unit.

1. The "Architectural Quantum" is a Minimal Federated Operating Model that adheres to Domain-Driven Design principles
2. The "Node" consumes an "Order" containing an input "Invoice" of input data to be processed as well as the Architectural Quantum's functional domain components that process Invoiced data; The content of the Order CID to be processed by the Node's "Factory" consists of the following: (*)
   • A. the CID-ed input Invoice as is within data/input/data/*
   • B. the CID-ed Architectural Quantum's functional domain components:
     • a. "Function [FaaS]" consists of "Process [Composed Function]" and "InfraFunction [Actuator]" as its dependency
       • Function [FaaS] (as Code) is CID-ed for which the contents consist of CIDs for Process [Composed Function] and InfraFunction [Actuator]
       • Process [Composed Function] is the composed callable graph (FaaS-composer analogue): transport port callables — integration_cache always receives Function-owned TransportPort; ingress / egress receive TransportPort when num_partitions == 1 (default) and also Function-owned IoPort when CATS_IO_PARTITIONS>1 (Plant-backed partitioned CAR layout) — plus a Higher-Order Transfer Function / hotF (integrated_subproc — Plant-agnostic ComputePort.run_transfer; this demo’s Structure wires RayComputePort / RayIoPort under plant_cid). Process transport callables take input_dir_id (Order ABI §6j); Ray I/O jobs use input_id / layout_id. Process itself is the composition, not a hotF and not the notebook UI; peering mutate is Structure TF (ipfs_transport_peering / TransportContext.ensure_peered), not Process heal. Orders are authored via the REPLaC (REPL as Code) Workflow UI of Function [FaaS] (this demo: Marimo). Compose with named imports of the Process public surface only (never import *).
     • b. "Structure [PaaS]" is Function's infrastructure dependency and consists of "Plant [SaaS]" and Plant's "InfraStructure [IaaS]" infrastructure dependency
       • Structure [PaaS] (as Code) is CID-ed for which the contents consist of Plant [SaaS] and InfraStructure [IaaS] CIDs
3. The Node's "Factory" processes an Order to produce "Executor" of an Architectural Quantum by composing Function [FaaS], constructing Structure [PaaS], then instantiating Executors with Function [FaaS] & Structure [PaaS] as its dependencies / parameters
4. The Executor is a composition of Architectural Quantum execution that executes and Invoices the ephemeral execution of the Architectural Quantum.
   • A. the Executor executes the aforemention composition as a Function [FaaS] executing on Structure [PaaS]: transport port callables run locally with a narrowed TransportPort (and Plant IoPort when CATS_IO_PARTITIONS>1); InfraFunction [Actuator] dispatches the hotF onto Plant via PlantPort (Plant.plant_port() → RayPlantPort for this demo) with scratch via ObjectStore / JobHandle; in-job entrypoint wires ComputePort
   • B. the Executor Invoices the ephemeral execution of the Architectural Quantum by producing a content-addressed Invoice containing the original Order ref, the output Data (data_uri), interim stage refs (ingress_data_uri, integration_data_uri), and a (non-deterministic processing) Seed (Function/Process replay dictionary) — Seed is populated (seed_uri → {seed, rng_seed, num_partitions}, minted fresh per execution; #187); stage refs on the Invoice remain the interim feedback surface for data products (when CATS_IO_PARTITIONS>1, those ids may be partition-layout directory roots of part-*.car files — still one content id per stage)
5. The Node produces a CID-ed BOM — a JSON-LD + PROV-O envelope (build_execution_bom) containing an CID-ed Invoice (with structure_as_executed_cid nesting observed Plant / ObjectStore state), CID-ed Executor execution "logs", and node_did attribution, then signed with a Data Integrity proof (sign_execution_bom, eddsa-jcs-2022 / Node did:key keyfile; Flask HTTP bind stays on Node lifecycle, not the BOM) (*). Full Nest tree: BOM.md CAT Node HTTP BOM response.

Notes (*):

• 2. The Order is intended to be consumed from within a "BOM" hosted on a registry; i.e. - discovered via that BOM's Invoice order_uri / equality id rather than supplied out-of-band. A Node-local BOM registry (BomRegistry under {CATS_HOME}/.cats/registry/) indexes verified ExecutionBoms on Runtime.execute (fail closed). POST /cat/node/init accepts order_uri, or bom_uri / bom_ldp_uri / bom_solid_uri / unique content_id / data_uri to resolve the Order via the index (GET /ldp/registry/…). Legacy order_cid / bom_cid / data_cid → 400. Ambiguous data → 409 with candidate bom_ids. Mesh-global federation of the index remains deferred. Full contract: BomRegistry.md.
• 4B. Seed holds the Function/Process replay dictionary (seed identity hex, Process/NumPy-usable rng_seed int, observed num_partitions); Invoice carries Order + output data + seed_cid alongside the still-useful interim stage CIDs. num_partitions is recorded on Seed each run, not yet read from it — env CATS_IO_PARTITIONS (demo) remains the interim selector of n until the Executor resolves n from Seed / a prior BOM's lineage (Option B follow-on; see TODO.md)
• 5. BOM content ids (and locator / *_uri fields) are published into the Node-local registry on execute for future Order consumption / link* lineage (BomRegistry.md); Solid dual-write of registry records remains later. CAS locator maps (by-content/) and Phase 2b dual-field *_uri are landed.