Skip to content

Reading the graph

colour means reads as
green managed chant declared it and the estate confirms it
amber foreign it is there, chant did not put it there
blue pending declared, not yet observed as deployed
grey neutral nothing deployed for this component yet

A node behold could not read is unobserved, reported as a hole and never painted as absent. “I did not look” and “it is gone” are different claims, and conflating them is how a viewer talks someone into deleting something.

From widest to narrowest:

  1. Components. The deploy units and the waves they go out in.
  2. Logical. An architecture diagram in the shape the substrate actually has. AWS nests region → VPC → subnet; Azure nests under the resource group; GCP is project → location, with no network containment, because the emulated GCP surface has no VPC to draw.
  3. Composites. The higher-level constructs your source declares.
  4. Resources. Individual resources at their real provider names.
  5. Attributes. The properties on one resource.

On Kubernetes there is one tier further down, below anything you declared:

Runtime. The Pods, ReplicaSets and EndpointSlices the cluster created and maintains through ownerReferences. They are runtime children rather than drift: nothing declared them and nothing should. This tier is why a healthy-looking Deployment in front of a dead Service is visible rather than green.

The API server records, per field, which manager last wrote it. chant compiled the manifest, so it knows which fields it authored. Put together, the inspect pane can say these fields are chant’s, spec.replicas is the HPA’s, and someone edited the image by hand.

Foreign-owned is shown as a distinct state from drifted. A field the HPA legitimately owns is not a problem, and colouring it like drift would recreate the noise that per-field ownership exists to remove.

An estate that spans providers keeps its edges: a managed cluster declared in your cloud lexicon and the workload running on it render connected, in the live view and not only in the source graph.

Three cards carry provenance beside their status, so “is this what we meant to deploy” has an answer on the card rather than in a CI log.

  • A component that the release ledger recorded shows <sha> via <forge>, the commit and the id space of the run that deployed it. The inspect pane’s release section carries the run id, commit, digest, actor and approver. The run is a link only when the record itself carries an address (chant ≥ 0.54); a bare id from an older chant is stated as unlinked rather than guessed at.
  • A Helm chart whose observed release records its render identity (chant ≥ 0.54) gets a deployed from row in the render-diff section: the release was deployed from this project’s render byte for byte, from the same inputs, or from something else. A mismatch repaints the card the drift colour, since a release running someone else’s render is bad news whatever its status. A release no ledger record names reads as unrecorded rather than as a mismatch.
  • A chant entity carved out of Terraform carries carved: <address> and a carved → chant mark on the entity graph and the overlay: the carve manifest names the file it emitted, chant graph names the file that declared the entity, and the join is a byte comparison. The inspect pane’s carved from section gives the Terraform address, stage and estate.

On the ops lens, a step whose contract declares which of its arguments identify an estate entity (httpCheck and its url, chant ≥ 0.54) links to the card it touches: the card is drawn beside the track in an estate box with a dashed edge from the step, and the pane lists the value on both ends. The join is exact: a node id, or a declared attribute value equal to the step’s. A value nothing carries stays on the step as unresolved rather than guessed.