wai.delivery.fleet: an organisation's nodes enrolled by their keys, their records verified, and a report it signs (wai-fleet, the fleet's operations, corpus and second verifier) #518

Merged

dcharlot merged 6 commits from wai/fleet into main 2026-10-27 19:44:30 -04:00

Conversation 0 Commits 6 Files changed 33 +13490 -19

dcharlot commented 2026-10-27 16:18:33 -04:00

Owner

Copy link

The open fleet engine waiOS operates: an organisation enrols its nodes by their signing keys, each node contributes the records it already signs, the fleet verifies them, and the organisation signs a report that traces every line to its records and never counts unmetered energy as zero. Everything here is open (Apache-2.0); no accounts, quotas, billing or console.

What is in it

• wai/extensions/fleet.md registers the record wai.delivery.fleet. It is named fleet.md, not after its report, because it defines the fleet itself: the organisation key, the enrolment, and what a node contributes. Sections:

  1. Scope.
  2. Terms.
  3. The enrolment, WFE1: the node's key, its role (1 relay, 2 compositor, 3 ingest gateway, which are live-metering's codes; 4 room service, 5 ledger, 6 audit collector), a label and a span, signed by the organisation. Also what each role contributes.
  4. The records and their carriage:
     • a relay's session summaries, joule-moq-relay/session-summary/2, read in the exact line form the relay writes and verified by its own signature;
     • per-hop records, WMH1, with their ledgers;
     • room descriptors, which place a hop record's room clock in time and are bound to the room id by their digest;
     • the instant of each record, its period, its enrolment, and one thing counted once.
  5. The figures: node lines, room lines and totals; energy per scope (sessions, hops) and per class, with max_ppm; four coverages; citations.
  6. The report, WFR1: its layout, signature and rules.
  7. The bundle (*.wai-fleet.json) and its verification steps.
  8. How the fleet composes with the receipt ledger.
  9. The reference service and its operations.
  10. Reasons.
  11. Conformance.
  12. Security and privacy, including that a bundle carries the client addresses the relay records.

• wai-rs module fleet (feature fleet): the enrolment, records, figures, report, bundle verification and Held (what a service holds). Also wai_fleet_vectors, tests/fleet.rs, and strict_json enabled for the fleet.

• wai/wai-fleet (binary wai-fleet):

  • the HTTP API of §9 under /v1/fleet/..., over a directory with two append-only logs (synced before the answer; a torn last line is cut off on start) and reports written whole;
  • everything is verified again on start;
  • wai-fleet collect URL SOURCE reads a node's summary file (a path, or an http/https address) into a running service;
  • smoke.sh checks the service over HTTP.

• Operations in wai, on the agent rules (the JSON envelope when stdout is not a terminal, the exit table, --dry-run on writes, --confirm before a service changes or a file is replaced):

  id	command line
  enrolment.create	wai enrolment create
  enrolment.list	wai enrolment list
  report.create	wai report create
  report.export	wai report export (the bundle is verified locally before it is written)

  wai verify checks *.wai-fleet.json bundles. quickstart now carries fleet.

• Corpus live-conformance/fleet/ (63 vectors) and fleet_verify.py.

• CI:

  • wai-conformance.yml: the extension in paths, fleet in the feature lists, tests/fleet.rs, tests/cli_fleet.rs, and a step running the module's tests and fleet_verify.py;
  • new wai-fleet.yml: the service's tests, clippy -D warnings and the smoke run on Linux; the release build and the smoke run on macOS.

• Also: the registry (wai.delivery.fleet; wire identifiers WFE1, WFR1, wai-fleet-bundle, .wai-fleet.json) and its export, a SPEC §5 paragraph, and a CHANGELOG entry.

Design decisions

• Energy (§5.4). Each summary states one figure in scope sessions and each hop record one in scope hops. A row is per scope and class, never summed across either.

  • unmetered counts the unmetered markers, which are in no row.
  • Coverage is whole, partial, unmetered or none. A partial scope's rows MUST NOT be presented as the energy.
  • A report whose unmetered count is below its records' is refused unmetered_summed. This covers a figure that is dropped and one restated as a metered figure of zero joules.
  • A summary may state only the marker, ModelBased or Estimator, because the summary has no members to carry an OnChipCounter or CalibratedInstrument class's evidence.

• Two accounts of bytes, never added. A node line states its summaries' bytes (client sessions and hop links kept apart) and its hop records' bytes separately. Room lines come from hop records. Totals sum the node lines.

• Silent is not unmetered. An enrolled node with no records in the period is listed in the report's enrolments and marked silent. It gets no line, so no line is ever unsourced (line_unsourced).

• Placement. Every record falls in exactly one of consecutive periods.

  • A summary is placed when it closed.
  • A hop record is placed at the last microsecond of its span, on the clock of the descriptor whose digest is its room.

• Composition with the ledger (§8). A hop record keeps receipt-ledger §5.2's kind 2 and identity. It is carried with its ledger in exactly the hops member of a ledger room source, and GET /v1/fleet/rooms/{room}/hops serves it in that form. The fleet prices nothing.

• Operation ids follow N3. The closed verb list that #506's catalogue tests enforce rules out fleet.enrol, fleet.nodes and fleet.report, so the provisional names became:

  brief	here
  fleet.enrol	enrolment.create
  fleet.nodes	enrolment.list
  fleet.report	report.create
  fleet.export	report.export

  They join the catalogue once #506 lands.

Checks (all builds and tests on the Framework box through rb)

check	result
cargo test --features fleet --lib fleet::	4 passed
cargo test --features fleet --test fleet, and with the CI's full $WAI_FEATURES	6 passed
wai_fleet_vectors verify ../live-conformance/fleet	regenerates byte for byte; every vector gets its outcome
cargo test --features $WAI_FEATURES --lib codecs::registry; --lib codecs::registry with no feature	15 passed; 14 passed
cargo test --features $WAI_FEATURES --test receipt_ledger --test live_metering	4 passed each
cargo test --features quickstart --bin wai --test floor --test cli_dx --test cli_fleet	20, 3, 2, 3 passed
cli_fleet looped	15/15 runs
cargo clippy --all-targets on fleet, quickstart, and the wai bin with no features, mcp and http	no note in the files touched
cargo check --features fleet --tests	ok
wai-fleet: cargo test --locked	5 passed; looped 15/15
wai-fleet: cargo clippy --all-targets -- -D warnings	clean
bash smoke.sh against a running instance	every check held
python3 -I live-conformance/fleet_verify.py live-conformance/fleet	63/63 vectors; §10 and reused codes all raised; §10 names every raised reason; 186 mutated copies fail; 28 weakened checks caught
avatar_face, browser_sink, sink_energy, synthesis_mark, synthesis, upscale, receipt_ledger and live_metering _verify.py (they read SPEC/registry text)	exit 0
registry export --check	up to date
cargo metadata --locked --offline for wai-rs, wai-fleet and wai-ledger	ok
check-tests-in-ci, check-workflow-concurrency, check-spec-refs, check-wai-section-refs, vanity, public-text, comparative-prose, check-orphan-sources, public names (files and commit messages)	clean
YAML parse of every workflow	ok; the merge of origin/main touched no workflow

Falsifications

Each was committed first, then mutated in the rb snapshot (anchors checked), run, and restored with git checkout. Each failed on its assertions, not on a build error.

• wai-rs, tests/fleet.rs fails each time:
  • the unmetered comparison dropped;
  • the role check dropped;
  • summed_across always false;
  • a summary's OnChipCounter read without evidence;
  • §10 without report_mismatch.
• fleet_verify.py, exit 1 each time:
  • the unmetered check dropped;
  • outcomes compared by verdict only.
  • §10 without report_mismatch was not caught at first. The verifier now also requires §10 to name every reason the corpus raises, and the falsification now fails as it should.
• wai-fleet:
  • the torn-line cut-off removed: a_record_cut_short… fails;
  • the corpus summaries generated with two members swapped: the_corpus_summaries_are_the_relays_own_form fails.
• cli_fleet:
  • confirmed() always true: all three tests fail;
  • report.export's local verification removed: the altered-bundle test fails.

The read-only production trial

• Setup. A local wai-fleet ran on the Framework box with a fresh trial organisation key, deleted afterwards. It enrolled:
  • the home relay ccf347d3… and the ash-1 edge relay 26e28bd6…, by their public ids, with wai enrolment create --target;
  • the live room service, by the authority key in its published descriptor.
• What production publishes without credentials:
  • GET /room-api/health;
  • GET /room-api/room, the live room's signed descriptor (room 18afdf24…, authority b413084c…). The fleet verified the authority's signature and held it.
• The summaries are not published. Both relays write them to a local log (summary.out_path), and the public front routes nothing to it. No production relay signs per-hop records either: hop_record is a library call that nothing in production makes.
• Result. The report for today verifies with wai verify and with fleet_verify.py:
  • 0 records;
  • all three nodes enrolled and silent;
  • fleet energy none.
• Recorded vectors instead. The corpus week, run through the service in smoke.sh and in the tests, gives:
  • home: 3 sessions, 1 link; sessions unmetered (4); hops partial (OnChipCounter 18.4 J, ±20 000 ppm, plus the recorded relay hop as the marker);
  • edge: 2 sessions, 1 link; its link bytes in equal home's link bytes out;
  • compositor: ModelBased 35 J;
  • ingest: Estimator 2 J;
  • lesson room: three rows, whole;
  • relay room: unmetered;
  • fleet hops: partial; fleet sessions: unmetered (7).

Not done

• Accounts, members, SSO/SCIM, quotas, billing, multi-tenancy, a UI and any deploy.
• Registration in the operation catalogue and an OpenAPI document for wai-fleet: these wait for #506.
• Polling of sources inside the service: run collect from a timer.
• Contributions beyond summaries and hop records (ingest session/1, WMR1, invoices, audit reports).
• Changing or ending an enrolment: one enrolment per node in this revision.
• live-metering §3.7's size bound: the fleet does not know a room's media tracks, so the service bounds the request body instead.
• https targets for the wai operations (the service is reached over http://; collect speaks https).

Questions for the owner

1. The operation ids follow N3. "report" and "enrolment" become nouns of the catalogue: does N10 allow "report" here?
2. The summary format has no WAI text of its own. The fleet's §4.2 pins its line form and signature. Should live-metering §8 or an extension own it?
3. Production feeding needs the relays to publish their summary files, or a collector on each relay host pushing to the fleet. Something also has to sign per-hop records periodically. Both are deployment decisions.
4. Record kinds 10 and 11 extend receipt-ledger §5.2's numbering.
5. The service holds the organisation key. Should a separate report-signing key be listed by the organisation?
6. Should confirmation be --confirm (as on main) or --yes (as on #506)?
7. A bundle reveals clients' addresses. What is the waiOS export policy?

🤖 Generated with Claude Code

The open fleet engine waiOS operates: an organisation enrols its nodes by their signing keys, each node contributes the records it already signs, the fleet verifies them, and the organisation signs a report that traces every line to its records and never counts unmetered energy as zero. Everything here is open (Apache-2.0); no accounts, quotas, billing or console. ## What is in it - **`wai/extensions/fleet.md`** registers the record `wai.delivery.fleet`. It is named `fleet.md`, not after its report, because it defines the fleet itself: the organisation key, the enrolment, and what a node contributes. Sections: 1. Scope. 2. Terms. 3. The enrolment, `WFE1`: the node's key, its role (1 relay, 2 compositor, 3 ingest gateway, which are live-metering's codes; 4 room service, 5 ledger, 6 audit collector), a label and a span, signed by the organisation. Also what each role contributes. 4. The records and their carriage: - a relay's session summaries, `joule-moq-relay/session-summary/2`, read in the exact line form the relay writes and verified by its own signature; - per-hop records, `WMH1`, with their ledgers; - room descriptors, which place a hop record's room clock in time and are bound to the room id by their digest; - the instant of each record, its period, its enrolment, and one thing counted once. 5. The figures: node lines, room lines and totals; energy per scope (`sessions`, `hops`) and per class, with `max_ppm`; four coverages; citations. 6. The report, `WFR1`: its layout, signature and rules. 7. The bundle (`*.wai-fleet.json`) and its verification steps. 8. How the fleet composes with the receipt ledger. 9. The reference service and its operations. 10. Reasons. 11. Conformance. 12. Security and privacy, including that a bundle carries the client addresses the relay records. - **`wai-rs` module `fleet`** (feature `fleet`): the enrolment, records, figures, report, bundle verification and `Held` (what a service holds). Also `wai_fleet_vectors`, `tests/fleet.rs`, and `strict_json` enabled for the fleet. - **`wai/wai-fleet`** (binary `wai-fleet`): - the HTTP API of §9 under `/v1/fleet/...`, over a directory with two append-only logs (synced before the answer; a torn last line is cut off on start) and reports written whole; - everything is verified again on start; - `wai-fleet collect URL SOURCE` reads a node's summary file (a path, or an `http`/`https` address) into a running service; - `smoke.sh` checks the service over HTTP. - **Operations** in `wai`, on the agent rules (the JSON envelope when stdout is not a terminal, the exit table, `--dry-run` on writes, `--confirm` before a service changes or a file is replaced): | id | command line | |---|---| | `enrolment.create` | `wai enrolment create` | | `enrolment.list` | `wai enrolment list` | | `report.create` | `wai report create` | | `report.export` | `wai report export` (the bundle is verified locally before it is written) | `wai verify` checks `*.wai-fleet.json` bundles. `quickstart` now carries `fleet`. - **Corpus** `live-conformance/fleet/` (63 vectors) and **`fleet_verify.py`**. - **CI:** - `wai-conformance.yml`: the extension in `paths`, `fleet` in the feature lists, `tests/fleet.rs`, `tests/cli_fleet.rs`, and a step running the module's tests and `fleet_verify.py`; - new `wai-fleet.yml`: the service's tests, clippy `-D warnings` and the smoke run on Linux; the release build and the smoke run on macOS. - **Also:** the registry (`wai.delivery.fleet`; wire identifiers `WFE1`, `WFR1`, `wai-fleet-bundle`, `.wai-fleet.json`) and its export, a SPEC §5 paragraph, and a CHANGELOG entry. ## Design decisions - **Energy (§5.4).** Each summary states one figure in scope `sessions` and each hop record one in scope `hops`. A row is per scope and class, never summed across either. - `unmetered` counts the unmetered markers, which are in no row. - Coverage is `whole`, `partial`, `unmetered` or `none`. A partial scope's rows MUST NOT be presented as the energy. - A report whose `unmetered` count is below its records' is refused `unmetered_summed`. This covers a figure that is dropped and one restated as a metered figure of zero joules. - A summary may state only the marker, `ModelBased` or `Estimator`, because the summary has no members to carry an `OnChipCounter` or `CalibratedInstrument` class's evidence. - **Two accounts of bytes, never added.** A node line states its summaries' bytes (client sessions and hop links kept apart) and its hop records' bytes separately. Room lines come from hop records. Totals sum the node lines. - **Silent is not unmetered.** An enrolled node with no records in the period is listed in the report's enrolments and marked silent. It gets no line, so no line is ever unsourced (`line_unsourced`). - **Placement.** Every record falls in exactly one of consecutive periods. - A summary is placed when it closed. - A hop record is placed at the last microsecond of its span, on the clock of the descriptor whose digest is its room. - **Composition with the ledger (§8).** A hop record keeps receipt-ledger §5.2's kind 2 and identity. It is carried with its ledger in exactly the `hops` member of a ledger `room` source, and `GET /v1/fleet/rooms/{room}/hops` serves it in that form. The fleet prices nothing. - **Operation ids follow N3.** The closed verb list that #506's catalogue tests enforce rules out `fleet.enrol`, `fleet.nodes` and `fleet.report`, so the provisional names became: | brief | here | |---|---| | `fleet.enrol` | `enrolment.create` | | `fleet.nodes` | `enrolment.list` | | `fleet.report` | `report.create` | | `fleet.export` | `report.export` | They join the catalogue once #506 lands. ## Checks (all builds and tests on the Framework box through `rb`) | check | result | |---|---| | `cargo test --features fleet --lib fleet::` | 4 passed | | `cargo test --features fleet --test fleet`, and with the CI's full `$WAI_FEATURES` | 6 passed | | `wai_fleet_vectors verify ../live-conformance/fleet` | regenerates byte for byte; every vector gets its outcome | | `cargo test --features $WAI_FEATURES --lib codecs::registry`; `--lib codecs::registry` with no feature | 15 passed; 14 passed | | `cargo test --features $WAI_FEATURES --test receipt_ledger --test live_metering` | 4 passed each | | `cargo test --features quickstart --bin wai --test floor --test cli_dx --test cli_fleet` | 20, 3, 2, 3 passed | | `cli_fleet` looped | 15/15 runs | | `cargo clippy --all-targets` on `fleet`, `quickstart`, and the `wai` bin with no features, `mcp` and `http` | no note in the files touched | | `cargo check --features fleet --tests` | ok | | `wai-fleet`: `cargo test --locked` | 5 passed; looped 15/15 | | `wai-fleet`: `cargo clippy --all-targets -- -D warnings` | clean | | `bash smoke.sh` against a running instance | every check held | | `python3 -I live-conformance/fleet_verify.py live-conformance/fleet` | 63/63 vectors; §10 and reused codes all raised; §10 names every raised reason; 186 mutated copies fail; 28 weakened checks caught | | `avatar_face`, `browser_sink`, `sink_energy`, `synthesis_mark`, `synthesis`, `upscale`, `receipt_ledger` and `live_metering` `_verify.py` (they read SPEC/registry text) | exit 0 | | `registry export --check` | up to date | | `cargo metadata --locked --offline` for wai-rs, wai-fleet and wai-ledger | ok | | `check-tests-in-ci`, `check-workflow-concurrency`, `check-spec-refs`, `check-wai-section-refs`, vanity, public-text, comparative-prose, `check-orphan-sources`, public names (files and commit messages) | clean | | YAML parse of every workflow | ok; the merge of origin/main touched no workflow | ## Falsifications Each was committed first, then mutated in the rb snapshot (anchors checked), run, and restored with `git checkout`. Each failed on its assertions, not on a build error. - **wai-rs, `tests/fleet.rs` fails each time:** - the unmetered comparison dropped; - the role check dropped; - `summed_across` always false; - a summary's `OnChipCounter` read without evidence; - §10 without `report_mismatch`. - **`fleet_verify.py`, exit 1 each time:** - the unmetered check dropped; - outcomes compared by verdict only. - §10 without `report_mismatch` was **not caught at first**. The verifier now also requires §10 to name every reason the corpus raises, and the falsification now fails as it should. - **`wai-fleet`:** - the torn-line cut-off removed: `a_record_cut_short…` fails; - the corpus summaries generated with two members swapped: `the_corpus_summaries_are_the_relays_own_form` fails. - **`cli_fleet`:** - `confirmed()` always true: all three tests fail; - `report.export`'s local verification removed: the altered-bundle test fails. ## The read-only production trial - **Setup.** A local `wai-fleet` ran on the Framework box with a fresh trial organisation key, deleted afterwards. It enrolled: - the home relay `ccf347d3…` and the ash-1 edge relay `26e28bd6…`, by their public ids, with `wai enrolment create --target`; - the live room service, by the authority key in its published descriptor. - **What production publishes without credentials:** - `GET /room-api/health`; - `GET /room-api/room`, the live room's signed descriptor (room `18afdf24…`, authority `b413084c…`). The fleet verified the authority's signature and held it. - **The summaries are not published.** Both relays write them to a local log (`summary.out_path`), and the public front routes nothing to it. No production relay signs per-hop records either: `hop_record` is a library call that nothing in production makes. - **Result.** The report for today verifies with `wai verify` and with `fleet_verify.py`: - 0 records; - all three nodes enrolled and silent; - fleet energy `none`. - **Recorded vectors instead.** The corpus week, run through the service in `smoke.sh` and in the tests, gives: - home: 3 sessions, 1 link; sessions unmetered (4); hops `partial` (OnChipCounter 18.4 J, ±20 000 ppm, plus the recorded relay hop as the marker); - edge: 2 sessions, 1 link; its link bytes in equal home's link bytes out; - compositor: ModelBased 35 J; - ingest: Estimator 2 J; - lesson room: three rows, `whole`; - relay room: `unmetered`; - fleet hops: `partial`; fleet sessions: `unmetered` (7). ## Not done - Accounts, members, SSO/SCIM, quotas, billing, multi-tenancy, a UI and any deploy. - Registration in the operation catalogue and an OpenAPI document for `wai-fleet`: these wait for #506. - Polling of sources inside the service: run `collect` from a timer. - Contributions beyond summaries and hop records (ingest `session/1`, `WMR1`, invoices, audit reports). - Changing or ending an enrolment: one enrolment per node in this revision. - live-metering §3.7's size bound: the fleet does not know a room's media tracks, so the service bounds the request body instead. - `https` targets for the `wai` operations (the service is reached over `http://`; `collect` speaks `https`). ## Questions for the owner 1. The operation ids follow N3. "report" and "enrolment" become nouns of the catalogue: does N10 allow "report" here? 2. The summary format has no WAI text of its own. The fleet's §4.2 pins its line form and signature. Should live-metering §8 or an extension own it? 3. Production feeding needs the relays to publish their summary files, or a collector on each relay host pushing to the fleet. Something also has to sign per-hop records periodically. Both are deployment decisions. 4. Record kinds 10 and 11 extend receipt-ledger §5.2's numbering. 5. The service holds the organisation key. Should a separate report-signing key be listed by the organisation? 6. Should confirmation be `--confirm` (as on main) or `--yes` (as on #506)? 7. A bundle reveals clients' addresses. What is the waiOS export policy? 🤖 Generated with [Claude Code](https://claude.com/claude-code)

dcharlot added 6 commits 2026-10-27 16:18:33 -04:00

wai.delivery.fleet: an organisation's nodes enrolled by their keys, their records verified, and a report signed for a period ... be42dd3b1f

extensions/fleet.md: the enrolment (WFE1), the records a node contributes as it
signs them (a relay's session summaries, per-hop records with their ledgers, the
room descriptors that place them), placement in time and one thing once, the
fleet report (WFR1) with node and room lines, energy per scope and class with
unmetered figures counted as unmetered, citations, the bundle and its
verification, and the reasons.

wai-rs: the fleet module (feature fleet), its corpus generator
(wai_fleet_vectors), tests/fleet.rs; live-conformance/fleet/ (63 vectors) and
fleet_verify.py, the second implementation.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

wai-fleet: a fleet as a service, enrolments and records kept append-only, reports signed and kept with their bundles ... d82b136176

The HTTP API of extensions/fleet.md §9 over a directory it owns (two
append-only logs, reports written whole, a lock, everything verified again on
start), and wai-fleet collect, which gives each line of a node's summary file,
a path or an http(s) address, to a running service. Its tests sign the
corpus's report byte for byte, recover the directory, cut off a line a crash
cut short, read every corpus summary back through the reference relay's own
types, and collect records the relay's own code signed from a file over HTTP;
smoke.sh checks the API over HTTP and the bundle with fleet_verify.py.

wai-rs: Held checks a record or an enrolment before it is kept, so the
service keeps one only once it is on disk.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

wai: the fleet's operations, enrolment.create, enrolment.list, report.create and report.export, and wai verify of a fleet bundle ... b0f25e48a1

wai enrolment create signs a node's enrolment with the organisation key and
writes it, or gives it to a fleet service with --target; wai enrolment list;
wai report create has a fleet service sign the report of a period; wai report
export verifies a report's bundle here before writing it. Each prints the
toolchain's JSON envelope when standard output is not a terminal, exits by the
toolchain's table, takes --dry-run when it writes, and waits for --confirm
before it changes a service or replaces a file. wai verify checks
*.wai-fleet.json bundles beside receipt indexes. The quickstart build carries
the fleet feature.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

wai.delivery.fleet in the registry, SPEC §5 and the changelog; the fleet's steps in CI ... 44378c92df

The record and its wire identifiers (WFE1, WFR1, the bundle's kind and file
suffix) in the registry and its export; SPEC §5's paragraph; the changelog's
entry. wai-conformance.yml: the extension in its paths, the feature in its
lists, tests/fleet.rs and tests/cli_fleet.rs, and a step that runs the module's
tests and fleet_verify.py. wai-fleet.yml: the service's tests, clippy and its
smoke checks over HTTP.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

fleet_verify.py: §10 names every reason the corpus raises ... 872502e8eb

A falsification (§10's report_mismatch row deleted) was caught by
tests/fleet.rs and not by the second implementation, which required every
listed reason to appear in the corpus but not every raised reason to be listed.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

Merge origin/main into wai/fleet ... 086fa24515

Co-Authored-By: Claude Opus 5.5 <[email protected]>

dcharlot merged commit 51ca51a4bf into main 2026-10-27 19:44:30 -04:00

dcharlot referenced this pull request from a commit 2026-10-27 19:44:31 -04:00

Merge pull request 'wai.delivery.fleet: an organisation's nodes enrolled by their keys, their records verified, and a report it signs (wai-fleet, the fleet's operations, corpus and second verifier)' (#518) from wai/fleet into main

dcharlot referenced this pull request from a commit 2026-10-28 05:49:51 -04:00

Merge origin/main into wai/ops-catalogue: #507, #518 and #521 as they landed

dcharlot referenced this pull request 2026-10-28 05:49:56 -04:00

wai: one operation catalogue (noun.verb) for every door, wai ops, the agent rules on every command, and the wai-* service binaries #506

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

Transaction-Science/open-standards!518

No description provided.