The badge, as rendered
Every line in this interface is a claim by somebody about somebody. Beside each one: who can verify it, by what method, at what cost, when it was last checked, and what the answer was. The layout is negotiable. This is not.
Five result states
three of these are routinely collapsed into oneVerifiable by
the third value is the informative one| client | Anybody can check this with published material. |
|---|---|
| provider | Only the party that holds the fact can check it, on request. |
| nobody | No party can check this claim, by any method, at any price. |
Rendering rule — absolute
An edge whose verifiable by is nobody is never shown with a ✓. It gets the state it has earned:
○not checked
Why this and not a trust score
- No trust score. Any single number over these edges would average confirmed, unreachable and unverifiable into one figure — precisely the collapse the badge exists to prevent.
- No green tick at page level. Pages do not have standing; edges do. A page-level tick inherits the standing of its weakest edge and displays the standing of its strongest.
- "Nobody" is a value, not a gap. Rendering it as a blank produces an interface where everything looks equally solid.
The register index
Nodes, counts, and the one number that should be uncomfortable. Day one it reads badly. It is supposed to.
Agents
3Issuers
1Projects
2How much of this register is checkable
24 edgesA register that does not report its own unverifiable fraction drifts toward looking authoritative as it grows, because volume reads as substance. This number belongs on the front page.
Honest tension carried from the pack
The unverifiable fraction will read as a failing grade for months, and the temptation to move it off the front page will be strongest exactly when it is most informative.
The agent page
A reader answers, without leaving this screen: what this agent is, who says so, who checked and when, what it may do, what it was authorised to do, and which of those statements nobody can currently verify.
Identity
record · 6 statements-
signing keyECDSA P-256, self-signed
-
encryption keyRSA-OAEP 4096, self-signed
-
operated byoperator (sgit.ai)claimed○not checked
-
runs onclaude-code, remoteclaimed○not checkedSelf-reported by the agent. No vendor signs a statement naming a session's surface.
Mandates in force
1 accepted- on
- github.com/SGit-AI/SGit-AI__Website__PKI
- scope
- branches:
dev· paths:briefs/**,documents/** - issued by
- operator (sgit.ai) sha256:a461…23ac
✓ issuer chains to a declared root of this registry - valid
- 20 Aug 2026 → 01 Oct 2026 · expires in 42 days
- accepted
- by this agent, 20 Aug 09:18, statement 4
✓confirmed
Grants held
2 recorded-
append tokenlane 3 · single use · expires 22 Aug✓confirmedunder mandate — operator record, statement 7
-
repository write41 repositories⚠unreachableunder mandate — none40 repositories excess authority unaccepted · 6w
This grant covers 41 repositories. The mandate covers 1. The difference has no acceptor and has stood for 6 weeks.
Computed from the provider lookup above, which is currently ⚠ unreachable — last confirmed 19 Aug 14:02. The count is 19 hours stale.
What nobody can check
2 statementsoperated by operator (sgit.ai) — no party can verify this claim
runs on claude-code, remote — no party can verify this claim
Not a defect on this page. There is no mechanism, at any price, for establishing either. Both are shown because hiding them would make the rest of this page look more solid than it is.
History
6 statements · chain intactThree things this screen does that a conventional identity page does not
- It answers "who says so" per line, not per page. The issuer sits inside the mandate block with its own badge, because a mandate's standing is the issuer's standing.
- The excess-authority row is a first-class object. The grant is what the credential technically permits; the mandate is what the holder was authorised to do; the gap is exposure nobody accepted.
- The unverifiable section is not an error state. It is the most honest block on the page.
Least trustworthy mockup in the set, and the pack says so: a crowded agent page has never been rendered against a real population.
The verification transcript
Clicking any badge opens this. The rule: a badge never asserts more than its transcript shows.
- claim
- This mandate was issued by operator (sgit.ai)
- edge
- mandate sha256:a461…23ac / statement 7 → subject sha256:69d9…790c
Result
by you, in this browser- verifiable by
- client
- method
- signature check over canonical bytes
- cost
- free — no account, no key, no rate limit
- last checked
- 20 Aug 2026 09:20:14 UTC
- result
- ✓confirmed
Transcript
7 stepsFixture check
read before any signature — C3private_key_published: false · publication_intent: none
Where a signature verifies against a published private half, this panel says so — because that is the exact case where a verifier succeeds and concludes something false. A hash makes no promise; a signature anybody can forge makes a promise it cannot keep.
Re-run this yourself
the page is not the only way to the answerNot established by this check
· That the issuer was entitled to issue it — that is roots.json, step 6, and roots.json is a declaration by this registry's operator, not a proof.
· That the subject accepted it — separate edge, separate badge.
· That anything the subject did stayed inside it — no registry can say this.
The block to defend in review
A verification transcript that lists only what it proved reads as a stronger claim than it is. "Not established by this check" is where the page stops overselling itself.
The grant tree, and the label on each node
A count is the summary of a path. Blast radius is a path through a tree, not an item in a list — and the load-bearing column is not what is reachable but who enforces the thing standing in the way.
This is one problem rather than eleven. Every excess path below bottoms out at the same node — runs as your user account. A list of eleven rows each ending in the same sentence buries that, so it is said once, here, at the top.
-
Runs as your user accountnothing in the wayWhat stands in the way: nothing · evidence: tested · checked 20 Aug
-
Read and write your filessettingIn the way: the tool's own folder restriction — enforced by the tool, which runs inside this grant · tested · 20 Aug
-
Read credential filesnothing in the wayReached by anything running as this user · tested · 20 Aug
- Cloud accountnothing
- Code host — 41 repositories, contents:writenothing
- Package registriesnothing
-
-
Open outbound network connectionsboundaryIn the way: egress allowlist, enforced outside the grant — the process cannot edit it · tested by making requests · 20 Aug
-
Execute programs as youexpectationIn the way: a permission prompt that can be disabled by a flag in a file the agent can write — a tier-three expectation wearing tier-two clothing · tested · 20 Aug
-
The path that produces "40 repositories"
worst path, not the countTwo trees with the same count and different worst paths render differently. 40 repositories and the credential that reaches them is readable by anything running as this user are different findings.
The test that decides every label
no vendor claim requiredA control bounds a grant only when it is enforced by something the grant does not include.
| boundary | Enforced outside the grant — the OS, a separate account, a container, a network policy, a remote service. Real. Holds against a compromised agent. |
|---|---|
| setting | Enforced by the tool itself, running inside the grant. Bypassable by anything able to run code as that user — which the grant includes. |
| expectation | Enforced by nothing. Written in a prompt or a policy file. Worth none. It is a mandate, and the pack already says what a mandate is worth. |
Applying this honestly labels a great deal of what people currently rely on as a setting, and that will be argued with. The label comes from the test, never from vendor documentation.
Dates are per node
a tree dated as a whole is wrong in one place while looking currentEvery row above carries its own checked date and a published re-run method, because this is an assessment of somebody else's product under their name. A vendor changing one default invalidates one row.
The shortfall — the region with no implementation
mandate − grant. The holder was authorised to do something its credential cannot do. The agent fails and the failure looks like a bug. Detecting it needs the mandate enumerated against real capability names, and the capability vocabulary does not exist yet — so it is drawn as a region and left unimplementable, rather than quietly added as a field.
Open, and the project lead's call
Is the grant tree in this MVP at all? It needs enumeration tooling the pack does not have. Current answer from document 14: the registry holds trees produced elsewhere and produces none itself.
Issue a mandate, from the issuer's side
The mandate lives in the issuer's record, so the issuer's page is where it is authored. The composer's job is to make the grant/mandate gap visible before the mandate is signed, not six weeks later.
- subject
- site-agent (pki.sgit.ai) sha256:69d9…790c
- capability
repo.pull-request.create- resource
- github.com/SGit-AI/SGit-AI__Website__PKI
- constraints
- branches
dev
pathsbriefs/**,documents/**
max files20 - interval
- 20 Aug 2026 → 01 Oct 2026 · 6 weeks
What the subject's credential actually permits
provider lookup · 20 Aug 09:28| The credential this subject holds covers | 41 repositories, contents:write |
| This mandate covers | 1 repository, one capability |
| Excess authority | 40 repositories |
Recording this mandate does not narrow the credential. It records what you authorised, so the difference becomes measurable and someone can be asked to accept it.
What the subject will be asked to accept
generated view · capability set v3 · 20 AugProhibitions
Will not read your credentials.
Will not open your browser sessions.
Will not act as you anywhere else.
Will not reach other machines on your network.
A rendering of the stored allow-list's complement over a known capability set. The person reads and accepts the prohibitions; the system stores and checks the allow-list. The moment the capability set grows, this rendering is stale — which is why it carries a date, and why the acceptance record names the version shown.
This subject's checking behaviour
from your own lane · doc 11| Mandates this subject already holds from you | 1 |
| Check interval | never checked |
| Effective revocation latency | infinite |
A party that has never verified the mandate it already holds is a strange party to issue a second one to.
Before you sign
3 checksLoad-bearing, and it must survive review intact
Without constraints unenforced, a mandate composer reads as a policy engine — and the distance between "recorded" and "enforced" is the exact distance this pack keeps insisting on. There is also no write path for mandates outside the issuer's own record: offering one would make rule 1 a preference.
Policy — and what its green is made of
The verdict and the badge that decides what the verdict is worth appear together, never apart. Two policies, identical results, opposite meanings.
- name
- No session of mine runs anywhere but surface X
- query
- every session node
whose surface edge is absent
or whose surface edge names anything but X - must return
- no rows
- result
- 0 rows · 20 Aug 09:31
This policy is instrumentation, not enforcement
The edge it constrains — session runs on surface X — is verifiable by nobody. Every session reports its own surface from an environment variable, which is settable by whoever starts the process and carries no signature.
This policy returns no rows whether or not it is being complied with. It records an expectation and detects nothing.
○not checked
It would become enforcement if a vendor signed a statement naming the surface of a session, verifiable by a third party against a published key. No vendor currently offers this. Anybody who can show one changes this box.
- name
- Every mandate in force has been accepted by its subject
- result
- 1 row · 20 Aug 09:31
✗ violation
site-agent (nhi.sgit.ai) ← mandate operator/statement 9
issued 18 Aug · no acceptance statement in the subject's record
✓confirmed
This one is enforcement: the absence is checkable by anybody, from published records.
The whole point, in one line
"0 rows" and "detects nothing" on the same screen. A policy dashboard that reports green without reporting what its green is made of manufactures exactly the false assurance this corpus documents. And a violation row that carries its own badge is something somebody can act on — a violation row without one is a complaint.
Open in the pack: WF-6 — running a policy — has no acceptance test. Either phase 3 grows a fifth one, or the policy layer is honestly declared out of the MVP.
Enrolment, from the agent's side
The design constraint is unusual and the interface must not soften it: the acknowledgement is blind, and pending and declined look identical.
Generate a keypair ✓ done
You now control a private key. Nothing else knows it exists.
Sign your identity statement with the key being enrolled ✓ done
This proves possession. It proves nothing about trust.
Post it through the append lane ✓ sent
No account. No access token. The lane accepts writes and returns nothing about them.
This response means the lane received bytes. It does not mean your enrolment was accepted, queued, read, or declined. Those four outcomes are indistinguishable from here, by design — a lane that reported them would be an oracle for guessing them.
Watch the public registry ○ waiting
The read path is the outcome channel. There is no other.
| present | The project recognised your key. That is a decision somebody made, not a computation that completed. |
|---|---|
| absent | Pending, or declined. You cannot tell which, and no amount of polling will tell you. |
Why the interface must not help here
An enrolment screen that renders a 404 as "not yet" is lying by omission about a system where "never" renders identically. Blind acknowledgement is a security property, not a usability defect — any signal distinguishing pending from declined, including timing, is an oracle for probing enrolment policy.
Unresolved in the pack: the processor is also supposed to publish its decisions. For declined submissions those two requirements are in direct conflict. Today the blind acknowledgement wins by default — which is a decision nobody made.
The verifier's answer
One sentence a third party can act on — or a refusal that says where it stopped. Partial resolution is a legitimate output, not a failure.
- question
- May sha256:69d9…790c open a pull request on SGit-AI__Website__PKI?
Answer
Yes, until 01 Oct 2026, on the authority of operator (sgit.ai), which is a declared root of this registry.
Basis
5 edges · all client-verifiable · freeNot answered
Whether the agent is who its label says it is beyond key control.
Whether anything it does stays inside this mandate. This register records authority; it does not observe behaviour.
Answer
I followed the chain this far and stopped.
Meaning
A mandate exists. Its subject has not accepted it. Its issuer is not anchored here. This is not a failure of verification — it is what verification found. Two parties disagree about standing, and the disagreement is now visible.
Why the refusal is the design
Explicit distrust is a valid signal, and a partial resolution is a legitimate output. An interface that renders this as an error page turns the register's most useful answer into a bug report.
Who has never checked
Nobody can tell you who is using a mandate. What is capturable is verification, not use — so the valuable query is not who checked, but which parties hold a mandate you issued and have never once verified it.
issued-to minus has-checked
1 of 3 relying partiesParty C is derived from the register entry, not observed from the lane. That is the whole mechanism: the layer sees who checked, and the issuer computes who did not. Every row here is a relying party accepting a mandate on faith.
Effective revocation latency
measurable before anything is revokedIn this design there is no push. A revocation sits in the register until a relying party looks — so it propagates at exactly the rate at which parties check. That is usually stated as a weakness. It is also a measurement.
Half the parties relying on this mandate would notice a revocation within an hour; ninety-five percent within a day; and these ones would never notice at all.
It also yields one of the very few mandate clauses that is genuinely decidable — verify this mandate at least once every twenty-four hours — because the breach is visible in the issuer's own lane without any cooperation from the party.
Lane health
the drain needs monitoring more than the lane doesAn issuer who stops draining stops receiving evidence without being told. Draining is an obligation, not an option — and its silent failure is exactly the kind this pack keeps recording.
What a check event may not carry
the boundary the consent argument rests on| must not carry | What the checker was authorising — the issuer has no claim on the checker's business, and including it turns an asset log into a customer surveillance log. |
|---|---|
| The checker's own credentials or tokens. | |
| Anything the issuer could not already infer from holding the mandate. |
There is no central check log. The checker writes into the issuer's lane; no party learns who checked everybody's, because no such record exists anywhere. The aggregate is foreclosed — a real commercial cost, chosen rather than discovered.
What this is not
Not a usage graph. It records verification, and the parties that never verify are invisible to it — which is the error running in the worst possible direction, since that is the party whose relying process is weakest.
Where the badge's "last checked" comes from
Document 08 specifies a badge carrying when an edge was last checked. It has no data source in document 08. It has one here: the issuer's lane. This is not a separate system with its own dashboard — it is the interface's evidence, and the badge is its user interface.
Empty and failure states
The states a real register lives in.
This register is empty. Four rules are published and nothing has been written under them yet. Four rules with no records are four assertions.
⚠unreachable
The authority for this edge did not answer. This is not a denial and must not be read as one. Last confirmed 19 Aug 14:02 — 19 hours ago.
✓confirmed
ⓘ This check is 69 days old. The record may have been appended to since.
⚠ The index lists 4 agents; the records directory contains 3.
The index carries no authority — it is a regenerable convenience. The records are the registry. This page is showing you the records.
Rendering the disagreement rather than resolving it silently is the cheapest defence available against an unsigned convenience becoming load-bearing.
private_key_published: true · publication_intent: deliberate · stated 20 Aug 2026
This entry is a fixture. Its signatures verify and prove nothing. A keypair whose private half is published is not a weak identity — it is no identity, permanently. It is not reachable from the trust graph, it can never be promoted, and it cannot be retired by revocation, because anybody can sign the revocation and anybody can sign the append that reverses it.
Read before any signature on this record is evaluated.
The CLI mirror
Every screen here is a rendering of public bytes, so the same answers must be reachable without the interface. If the page is the only way to get the answer, the design has quietly acquired a dependency it says it does not have.
$ sgit registry show sha256:69d9…790c site-agent (pki.sgit.ai) sha256:69d9…790c identity ECDSA P-256 + RSA-OAEP 4096, self-signed ✓ client/sig mandates 1 in force, 1 accepted ✓ client/sig grants 2 recorded, 1 unreachable ⚠ provider/lookup excess 40 repositories, unaccepted, 6 weeks computed unverifiable 2 claims (operated_by, runs_on) nobody/no method history 6 statements, chain intact
$ sgit registry policy run no-local-compute 0 rows. warning: this policy is instrumentation, not enforcement. The constrained edge "session runs on surface X" is verifiable by nobody. This result is 0 rows whether or not the policy is being complied with.
$ sgit registry verify sha256:69d9…790c --capability repo.pull-request.create I followed the chain this far and stopped. identity ok mandate ok operator/00009 acceptance MISSING subject's record has no acceptance of operator/00009 issuer root MISSING sha256:1d40…88c7 not in roots.json exit 2
Two deliberate choices
- The warning prints on the success path, because a policy that is instrumentation is most misleading when it passes.
- The refusal exits non-zero with the same words the page uses. One vocabulary for humans and pipelines — two vocabularies is how a nuance gets dropped in whichever one is read second.