The Observatory: the repository and its mesh, drawn for a wall

Observatory observatory behaviorally verified

What the Observatory may carry to a place where no mesh runs: the mesh scenes this process has live, pseudonymized for publication, and the recording the repository carries, which the published Observatory replays and labels as a replay.

• Observatory capture query
• Observatory events query
• Observatory replay query

Mesh mesh experimental

The mesh of this process: discovery — authenticated observations of other running Majordomus instances in one registry — and cooperation — authenticated links to trusted runtimes of the same repository, replicating sessions, claims, handovers and reviews through one journal every runtime folds into the same state. Discovery grants nothing; a link is admitted per peer, and nothing a peer sends executes anything here.

• Claim a scope across the mesh command
• Cooperation, at a glance query
• The mesh self-check query
• The cooperation journal query
• The host firewall, as the mesh needs it query
• Admit the mesh through the host firewall command
• Consume a handover from the mesh command
• Publish a handover to the mesh command
• This machine's node identity query
• Open a link (the handshake) command
• One sync round of a link command
• The discovered nodes query
• One runtime query
• Who cooperates, machine by machine query
• Register with this node's mesh command
• Release a claim command
• Answer a review request command
• Ask the mesh for a review command
• Withdraw a review request command
• Close a session on the mesh command
• Open or update a session on the mesh command
• The state every linked runtime converges on query
• The mesh, at a glance query
• Prove cooperation now command

The plan and its derivations plan behaviorally verified

The milestone and issue model of this repository, and everything derived from it that nobody authored: the status of each record, the dependency graphs above and below the milestone boundary, the topological execution waves, the roadmap order, the milestone being executed and the one issue to take next. Status is never stored — a record says what happened to it and the status follows from that and from the state of its dependencies — so no file can contradict the graph. This capability reads; writing a lifecycle marker into a record is `plan.transition`, which declares that it writes the repository.

• The issues, filtered by what the graph derived query
• The whole derived plan query
• The one issue to take now query
• One milestone or issue, with everything derived about it query
• The milestones in derived order query
• Where the plan stands query
• Move one issue through the lifecycle command
• What the model refuses query
• What may run at the same time query

Distribution distribution behaviorally verified

How this project is packaged, published and installed: the platforms a release builds, the artifact names the one naming function derives, the installer's canonical command, the releases that were published, and what this build itself is. Every answer comes from share/distribution.yaml and the release records; no surface here states a fact of its own.

• The artifact of a target query
• This build query
• The distribution model query
• Published releases query
• Whether the published installation works query

Release release implemented

What this project has shipped and what it would ship next, derived rather than maintained: the changelog composes the layer's release records, the decisions dated inside each release's window and the conventional commits in its range; the version report reads the one place the version is authored and the projection the shell tool prints, and says what the public contract requires it to become — or that it cannot be measured, and so decides nothing — with what the commits since the last release imply beside it as evidence.

• What the public contract did, and the smallest version it allows query
• The changelog query
• The version a landing allocates, and why query
• The version, and the one the contract requires next query

Health health behaviorally verified

Whether what this process serves is healthy, decided by the engines that already decide it: the index's diagnostics, the registry builder, the benchmark projection's coverage, the comparison `generate --check` makes and the lease reading `server.status` answers from. No check here has an opinion of its own.

• Liveness query
• Readiness query
• Health of this process query

Token economics economics behaviorally verified

What a coding session consumes with Majordomus installed and without it, from recorded runs: matched control and treatment sessions judged by the same hidden acceptance tests, the provider's usage as it reported it, and every number labelled with its measurement class (observed, counted, derived, estimated, counterfactual). One calculator; every surface is a projection of it, and the verdict states only what the methodology's publication rule allows.

• Refuse unsupported economics claims query
• Explain one economics metric query
• Recorded benchmark runs query
• Token economics summary query

Repository repository behaviorally verified

The repository this process serves: its layer, its git state, the state of the index built from it, and its scope: what a worker reads of it and what it never reads.

• Repository and index state query
• The repository scope query
• Judge a path against the scope query

Served deployments served behaviorally verified

Whether a deployment serves the commit it was meant to: the build identity a site serves, read from outside the way a visitor reads it, judged by commit containment and recorded so that a later reader can re-judge it. Only `served` passes; a site that could not be reached, an identity that could not be read, a build from an uncommitted tree and a served commit this clone does not hold are each an unanswered question, never a yes. Observing reaches the network and is a command of the trusted command line; reading the recorded standing is a read on every surface.

• Ask the forge what it recorded as deployed and released command
• Observe what a deployment serves command
• What each deployment was last seen serving query