Your topology map
only answers one question.
What is connected to what. Standing in front of it, that is rarely the question you have — you want to know whether a thing is allowed to run here, whether it is ready for work, where its data came from, and what breaks if it fails. Four different questions, and a connectivity graph draws the same picture for all of them.
The layout is the question.
Pick a dimension. The nodes do not change and neither do the edges — only what anchors the layout. Ten projections ship: eight built in, plus two the Kubernetes profile contributes at runtime, which the client has never heard of and does not need to.
What is connected to what.
Envelope scalars
Each link carries a small envelope of values the control plane already knows — policy compatibility, trust, confidence, readiness, provenance. A projection is a choice of which one anchors the layout.
Several channels at once
Each scalar also drives its own visual channel: hue, dash, opacity, width, halo, tick. A link can be simultaneously well-governed and poorly-provenanced, and you can see both without switching views.
Profiles, not a fixed list
The Kubernetes profile adds ownership and pod readiness at runtime. The registry is populated when the field is served rather than being a fixed enum in a type, so a new profile does not mean a new client.
It goes and looks.
A question is answered by issuing real read commands against the live cluster — pods, events, logs, nodes, namespaces — and reporting what came back. Not by inferring from whatever happened to be in the prompt.
Asked
“List the pods in the agent-scope namespace and tell me which ones are not ready.”
Answered
The following pods in the “agent-scope” namespace are not ready: agent-scope-backend-54bf9b96b4-ncbbb, agent-scope-backend-54bf9b96b4-xsxp8, agent-scope-backend-5d6c97f6b5-gdwz5, agent-scope-frontend-8d59c87db-4qvpd, agent-scope-frontend-8d59c87db-7bckh, agent-scope-frontend-bbc97dfcc-bxjrj.
It can act — and it can be refused.
Scaling, restarting and annotating pass an admission gate before they reach the cluster. Same request shape, same session; the only difference below is a label on the resource, so the decision is made on data rather than in code.
Refusal is structural
The proof-of-admission token is constructible only inside the gate, so a mutation cannot reach the cluster API without one. Refusal is a property of the type system rather than a prompt asking nicely.
Deny by default
A request matching no rule is refused rather than permitted, and within a policy set the first matching rule wins. A verb added later without a policy stays refused until someone writes one.
The reason outlives the request
A decision artifact is emitted for allows and denials alike, carrying the rule, the reason and a trace id — so “why was this refused?” has an answer after the fact, not only in the moment.
Said plainly.
A status page is only useful if it is willing to say no. These rows are the honest state of the system, not a roadmap written in the present tense.
The declarative half exists — AgentSpec.policy_ref already
points at a Policy resource — it is simply not the thing the
gate reads yet. Loading it is the next step, and the seam it will load
through is already the only place policy is assembled.