Updated September 2026
Orbyt Command Record v1
Status: experimental, version 1, implemented at Orbyt Labs.
The version is the version field in the schema.
A command record separates a request from evidence that it took effect. It records the target, the operator, the requested change, the transition evidence and what the command cannot undo. A request to stop an agent is not evidence that it stopped.
Command record states
requested- The request records the intended change and what it cannot undo.
committed- The executor recorded evidence of a commit or an acknowledged API call.
effective- A separate reader found evidence that the requested change took effect.
observed- The evaluator found evidence of the command's later expected result.
rejected- The command was refused or evidence contradicted its claim.
expired- The request expired before it was committed.
superseded- A later committed pause or resume reversed the earlier command on the same target or at global scope.
Evidence and attribution
The effective state needs evidence from a source separate from the executor's response. An acknowledgement alone does not show the change took effect. The evaluator reads the supplied observation. Source: Executor design, sections 6 and 9.
The executor sets the command_id dispatch input from the record id. The workflow carries it in run-name, linking the run to the command. The reader also checks GitHub's triggering_actor against the executor identity. A command id alone does not prove who dispatched a run. Source: Executor design, section 13, item 2.4a.
For a commit made by a dispatched workflow, the Org-Run-Id trailer links the commit to the run. A workflow token with write access can write that trailer. Source: Executor design, section 14, F15.
superseded_by belongs to the reader's observation, not the stored record. The reader supplies a later landed command on the same target or the global scope. The evaluator checks that its kind undoes the earlier command and that its commitment came later.
Schema and fixtures
The schema describes the record shape and transition paths. Its x-semantic-rules field names additional timestamp and value comparisons. Record validation does not establish an external effect.
The schema fixes executor.app to orbyt-collective-executor, the identity the current validator accepts. It does not expose an installation setting for that identity.
Each fixture is an envelope with license, expected and record fields. Validate the record object. The examples use synthetic evidence. In each pair, setting outcome to null changes VALID to INVALID because a terminal record requires an outcome string.
Test it
Run the fixtures through your implementation. Report a VALID record rejected or an INVALID record accepted to hello@orbytlabs.ai. Include the fixture URL, implementation version, result and reproduction steps. These fixtures test record validation. They do not test independent reads.