pki.sgit.ai / admin / comms
Comms: tasks, requests & status
The working channel between the project lead and the site agent, kept in public on the site itself — which is an instance of the discipline this site argues for. Updated on every release. Current release: v0.1.9, 20 August 2026. Full history: versions.
Needed from the project lead
| # | Request | Why it blocks | Status |
|---|---|---|---|
| N1 | GitHub Pages and the custom domain. Done — pki.sgit.ai resolves and serves, DNS and the custom domain are in place, and the full pipeline (validate → tag → deploy) is verified end to end | No longer blocking | done |
| N2 | The corpus documents for the collection. Answered. A Librarian cross-reference review has identified all seven February–March documents by exact path, plus a 53-row manifest tiered for publication (13 publish-as-is, 29 with a framing note, 7 needing redaction, 4 do-not-publish). What remains is a decision on how much of it to bring across — see the new N7 | No longer blocking; build-order step 1 is unblocked | answered |
| N3 | The attestation decision. Does the registry accept third-party attestations? It is the site's central open question and it is a call for the project lead, not the site agent — a documented failure on one side, no social trust at all on the other | The private-registry build (step 4) can start without it; mandates (step 5) cannot be finished without it | open — published unresolved, deliberately |
| N6 | Adopt (or reshape, or refuse) the registry MVP pack. Now a full dev pack. The three v0.33.61 briefs arrived and their corrections are recorded in change control, which also carries the decisions register: four settled by those briefs (mandate location, grant redefinition, the fixture class, agent cards + workflow signing), four still yours — the size bounds, the first capability, acceptance semantics, and the corpus version on adoption. Update, v0.1.26: at the project lead's direction the first MVP is now built and live at /registry/ (T22) — the fixture class, the validator, the read path and the roles shipped; the pack's formal adoption and corpus version remain open, and the register's own README records which pack decisions it takes provisionally | Phase 0 has effectively started; the adoption call formalises it | waiting on human |
| N13 | Dev brief #3 — the badges, cards and visualisation blocks — has not been shared. The building blocks it defines are the next thing to build and the brief itself is not in this session; only the two v0.33.62 briefs were provided. Related material already on the estate that the brief will probably supersede or extend: the badge primitive (six fields, five result states, nobody as a first-class value) from the v0.33.61 register-UI brief, its rendering rules (C27–C30: colour re-collapses the five states, the wrap point matters, a column of ticks is a page-level tick), and the six screens in the Grant & Mandate pack. Without brief #3 the site agent would be guessing at which of those it replaces | Answered 26 Aug: brief #3 was written from the two v0.33.62 briefs (document 09) rather than supplied, and the blocks are built. What remains for you is GM-D32 — whether the risk product consumes this stylesheet or forks it | answered — brief #3 authored here |
| N19 | Four calls from memo 3. (1) Does structural delta appear in the operator's rating at all — shown but not charged, or excluded? Showing it is honest and may be discouraging; hiding it is neither. (2) Who measures platform granularity, and where is it published? The doctrine argues it is a public good belonging in the library here — which is also the moat, so it is a business call. (3) Where does the world-state feed come from? The mapping from an advisory to the grant nodes it widens exists nowhere for anybody, and is plausibly the most defensible asset in this pivot. (4) Shall measure.py get the commit-authorship node now (GM-D50)? Small change, makes our own twin honest about a capability it confers today, and demonstrates the discovery instrument is itself reviewable. | (4) is a small fix whenever you say; (1)–(3) shape the rating engine | waiting on human |
| N32 | Four decisions from the three MVPs, and one from the vault. (1) The name of the assessment site — the brief settles the shape (the question, not the concept) and rules four candidates out; the word and its availability are yours. (2) Whether step three holds: name three products on the page and say whether you saw a grant you did not know you had; if not, the profile set is not yet worth forking, and that is the finding to publish. (3) The tree's probabilities in guess/tree.json are one author's estimates from one day, answered by nobody; play it and correct a branch. (4) IE-D25 retires the levels' numbers in favour of evidence mode and adopts the rung-to-instrument mapping as a proposal by analogy — yours to confirm or reverse, with GM-D108. (5) IE-D24: the conformance vault's top-level conditions and exclusions are taken as the reference shape for policy/v1; document 03's schema changes on the next revision. | Nothing blocks; the pages run either way | waiting on human |
| N31 | Memo 13 leaves three decisions, and the limits you raised want a review date. (1) Level four: report or refuse? .github/workflows/policy-report.yml runs on every pushed ref and fails nothing; making it a required check that refuses turns it into the boundary the pack has never had, and the day it refuses something the hook should have, that is a catch and an incident (GM-D106). (2) The name. The object stays policy and the ladder is the levels of enforcement (GM-D108); the product name is yours — agent policies collides with IAM and OPA, agent insurance policies with the regulated word. (3) Which standard to align the levels with — SLSA's shape is closest and its vocabulary is supply-chain. (4) The raised limits (bands 200 KB, exclusion 1 MB, pools 4 MB, counts doubled) are the first re-fit from one day's loss data and you asked for a review: the room's draw-frequency card is the input, and a week is the natural period. | Nothing blocks; the destination check reports meanwhile | waiting on human |
| N30 | The pack published itself under its own policy, and three things are outside cover and wait for you. On the pack's ledger, 3 September: the documents commit drew 74,979 B; the tools commit drew 86,056 B; the briefs commit (254,360 B) and the pages commit (216,832 B) were requested draws, which I approved under the approver's hat as your 3 September instruction allows for the pilot — the record names both hats; and two commits were refused as exclusions: the wiring sources at 310,858 B (over the 300 KB cap by 3,658 B, because a one-line change to gen_packs.py or llms.txt costs the whole file) and the badge rewrite at ~4 MB, the last one. I did not accept either: outside cover is a person's call. Both are preserved — the wiring as a patch on the branch, the rewrite as one chrome.py run — and the escalation is 2026-09-03T02-09-05Z__c7278eae. Accepted, 3 September (“Yes please push these and I accept those exclusions”): both were accepted as uninsured on the pack's ledger, the release commit and the two pushes carry the override on the push-policy ledger, and the room shows the day. Four decisions remain: (1) the per-commit exclusion against this estate's files — gen_documents.py is 142 KB, versions.html 167 KB, so a one-line change is half a cap; raise the cap for derived and append-only files, split the generators per section, or meter diffs instead of blobs (the meter is honest; the numbers are memo 12's); (2) IE-D9, mandate as the narrow thing — taken provisionally, yours to reverse; (3) whether the approver's hat stays on for requested draws now that the workflow is shown, or every request waits for you; (4) the three vaults (build-order steps 2–4) — a fresh session with the pack and the access code in chat; that is the pack's own acceptance test. | Nothing blocks; four decisions remain | waiting on human |
| N29 | The first MVP is built, and its first finding is that this estate breaches its own policy on every release. insurance/push-policy replayed the last twelve releases on dev: twelve of twelve refused, at ten to forty-three times the 300 KB per-push maximum, because chrome.py stamps the version into ~180 pages on every release. Two non-release commits passed. Your call, and it is the one that decides whether the hook ever gets installed: (1) fix the release — stamp the version in one place the pages read at load time and ship only what changed — then install the hook; or (2) raise the numbers for a self-regenerating site and lose the finding. I have shipped the hook and not installed it, because installing it refuses this release too. Three smaller decisions from the memo: 250 KB or 300 KB for the per-push maximum (your message said one, the memo the other; the policy took the memo); pushes or commits as the counted unit (the checker counts pushes, where git meters bytes); and a main policy, which does not exist yet and should be stricter than dev's. | Nothing blocks; the ledger fills the moment the skill is used | waiting on human |
| N28 | Two of your partner's four artefacts are held, and publishing them is your call and theirs. The landing page and the design partner deck are live — both are outward-facing by design. The two RAMM-I documents are not, because they are internal strategy: they name an existing customer under an active SOW, name acquisition and partnership targets, state a negotiating position on a contract clause, and characterise named competitors in language written for a private audience. This site is public and serves every file in the repository whether or not anything links to it, and git history keeps a blob after a delete — so committing them publishes them, irreversibly. Both are staged and go in on one word from you. Their substance is already captured in the concordance, with the customer name, target lists and competitive characterisations omitted — so nothing doctrinally useful is being lost by holding them. Second, and more interesting: the RAMM-I deck is not superseded by the design partner deck — it is a different document for a different audience, and it carries most of the load-bearing content (competitive landscape, build stance, the RICE argument, the four-phase path, the flywheel, the risk register, and the honest summary). The design partner deck is the sales cut of it. Third: the Index is 0–100 and GM-D54 settled 1–5, explicitly refusing 1–100. That is the first thing the two bodies of work must actually agree on, and it is yours and your partner's jointly — I have sketched the shape of a reconciliation and deliberately not made one. | Nothing blocks; the held docs go in on your word | waiting on human |
| N27 | Memo 11 changes what the first MVP should be, and it is the only candidate that produces data. Brief v0.33.83 / doctrine 11. Three deliverables now compete: the world model (explains), the market survey (observes), and the resource pool (measures). My recommendation has changed. I have said the survey first for three releases, on the grounds that it was the only thing here that could be wrong in a way the world would correct. The pool is stronger, for one reason: it is the only one that would produce loss data, and the pivot's deepest gap is that it has argued about insurance for eleven memos with none. It is also the only one runnable against this estate's own consumption this week, needing no carrier, no customer, and no new meter — the honest first step is simply to measure what our own agents burn, before designing any policy over it. The survey is still needed and is unaffected; the two are complements. Four questions are yours: (1) is the pool the MVP? (2) what is the per-occurrence limit — the component the memo does not name, and the one that decides whether a pool degrades gracefully or fails all at once? (3) who holds the pool — the supplier, an execution broker, or nobody, which decides whether this is a product, a schema or a demonstration? (4) does a licence withdrawal stop the agent or refuse the next request, which is still memo 10's unsettled voids, suspends, or downgrades. | Nothing blocks a consumption measurement | waiting on human |
| N26 | The audit narrowed two of my own earlier proposals — do the five decisions stand? Brief v0.33.82 re-read all eleven readings against their transcripts and found six defects. Three are housekeeping and are now gated (GM-D81). Three are not, and two of them make this folder claim less than it did: GM-D82 narrows GM-D52 — the enforcement tier ranks reachability, not the incident-response team's impact reduction, because insurance splits a loss into how often and how bad and the tier is neither; GM-D84 corrects doctrine 02's claim that stage 1 is structurally immune to moral hazard, which doctrine 09 contradicts without noticing. GM-D83 restores a question memo 3 asked and doctrine 03 dropped — whether a model vendor would carry a policy against its own mistakes — and generalises it: any party claiming to reduce somebody else's exposure should carry cover against being wrong about it, which is the argument memo 6 later made about brokers only. GM-D85 delivers a connection brief v0.33.73 promised and never made: an endorsement is an append. One process question: the briefs still say memo N of 8, which was true the day each was written. I treated them as dated records and corrected only the doctrine, which is the living layer. Say if you would rather the briefs were superseded too. | Nothing blocks the work; these are yours to accept or reject | waiting on human |
| N25 | The series is complete and nothing is built — three deliverables are specified and waiting. (1) The world model: an explainer, 2D, walking one worked example, emptiness prominent. (2) The market survey: the only thing here that can be falsified. (3) The schema simulation memo 10 asks for — which, given GM-D79, is a set of documents and transitions rather than an API. My recommendation, unchanged and now sharper: the survey first. Eighty decisions and zero external facts is the honest state, and it is recorded at the top of insurance/llms.txt. Two smaller questions from memo 10: what finishes the truncated sentence about the 24-hour backup window — it is the most concrete cover condition in the series — and does a warranty breach void, suspend, or downgrade? Insurance has all three and they differ materially; your memo implies refusal of the action, which is closest to suspension. | Nothing blocks any of the three | waiting on human |
| N24 | Two deliverables now on the table, and they are complements. The world-model MVP (N23) and the market survey — and the survey supplies facts the world would otherwise have to invent, which is an argument for doing it first. Three calls on the survey: (1) how wide? Three carriers checked properly beats thirty skimmed, and a floor that says so beats a table with unmarked gaps. (2) Do we publish it? Market research with commercial value, and the kind of public good this estate says it prefers to publish — the same tension as N19 q2. (3) Ask carriers directly, or read only what they publish? The doctrine argues published-only, because a sales-call answer is unverifiable and makes the survey unrepeatable — a real cost in coverage, and your call. My recommendation: the survey first, narrow and published-only. It is the only thing here that can be falsified. | Neither blocks the other | waiting on human |
| N23 | The series is done and the MVP is specified — shall it be built? Doctrine 08 §7 has the whole thing: a 2D world with places — environment, operator, underwriter, relying party, and an empty lot marked insurer, stage 2 — walking one worked example from the delta through a rating to a refused request. Every step is a document this estate already publishes except two (the claim shape and the world-state feed), which appear as construction sites. Three calls come with it: (1) do the bands widen? — 1–5 is settled, even-vs-geometric steps is not; (2) which worked example does the world walk? — our own GitHub delta is real and published, a synthetic one would be prettier and prove less; (3) how prominent is the emptiness? — the rule says it shows, how loudly is a presentation choice with a commercial edge, and it is yours. My recommendation: build the 2D world with our own GitHub delta, emptiness prominent. It is one release. | Nothing blocks it; N20 is superseded by this | waiting on human |
| N22 | Three from memo 7. (1) Who is the first relying party you would build for? Internal services or a broker — and the choice decides whether the first handshake is a setting or a boundary, since the tier depends on the relying party being genuinely independent of the requester. (2) How is a policy provider paid, if not per check? Per-verification pricing is ruled out on incentive grounds; per seat, policy or period all work and shift the economics differently. (3) Does a policy roll-up summarise or preserve? An internal regime becoming one external signature is allowed by the fractal claim; whether the verifier can descend into it is a design choice with a real privacy consequence. One memo left. | None block the MVP, which is still N20 | waiting on human |
| N21 | Three from memo 6. (1) How is cost-to-close estimated, and by whom? It is not readable from a twin — it is a judgement about effort, which under the two-channel rule must be marked declared, with the weakness that carries. (2) Does a broker's own rating publish? Its rating is systemic, so a market where brokers reduce levels but their own levels stay private has an obvious asymmetry. (3) Is a SaaS broker's boundary crossing one node or several? Decisions leave the environment is one fact; what the broker can see, retain and be compelled to disclose is several. And still open: the MVP (N20). Memo 6 adds a natural second view to it — what would a broker buy you here — the same counterfactual machinery pointed at a product rather than a control. | None block the MVP | waiting on human |
| N20 | SUPERSEDED by N23: memo 8 specified the MVP and corrected its shape — an explainer rather than the calculator proposed here. Originally: the first MVP is unblocked — shall it be built? The scale is settled (1–5) and the control-to-premium counterfactual was already scale-free, so a placement rated 1–5 with its full derivation, plus a which control buys the most view, needs nothing that is not already published. Alongside it, three from memos 4–5: what defines each band (the scale is settled, the band definitions are not, and that is where the argument will usefully happen); which connector first (GM-D57's evidence-class labelling is cheap on the first and expensive to retrofit onto the fifth); and do the band definitions publish here or stay in the product — memo 4's monoculture argument and memo 5's honesty argument both say publish, the moat argument says otherwise, and it is the same tension as N19 q2. | Nothing blocks the MVP now; the band definitions can be drafted with it and argued after | waiting on human |
| N18 | Four calls from memo 2, and one is an org-design question no schema can settle. (1) Who is the underwriter in your target organisation — security, platform, risk, or an independent function? The rating is only as good as its separation from whoever wants to ship. (2) What is the threshold and who sets it? A gate needs a line — this level may not go to production — and whether it is per-service, per-asset-class or global is the difference between a usable gate and a blanket ban. (3) Should the gate be overridable, and by whom? Unoverridable makes it a boundary and also makes teams route around it; overridable makes it a setting. Either is fine as long as the tier is stated, but the choice is yours. (4) Shall we build the scale-free counterfactual now — which control buys the most for this placement? It needs neither the level scale (N17) nor any new machinery, only a renaming of what the workbench already computes. | (4) is one release whenever you say yes; (1)–(3) shape what gets built after | waiting on human |
| N17 | ANSWERED (1) by memo 5, 31 Aug: the scale is 1–5 — recorded as GM-D54, settled, on the reasoning that a coarse band is arguable where a decimal is not. The first MVP is unblocked; the remaining three are open. Originally: four calls from memo 1, and the first one blocks the first MVP. (1) What is the level scale? Bands 1–5, a continuous score, or letter grades? The memo says "level three, level five" without fixing a range, and every surface built on it inherits the choice. (2) Does a level rate the agent, the placement, or the pair? The doctrine argues placement — the same model is a different risk on a desktop and in a browser — but it is your call, and it decides what the object is. (3) Who runs the internal marketplace — platform, security, or the deploying business unit? That decides whether a level is a control or a chargeback. (4) Shall we measure a desktop agent? It is the cheapest experiment available and it tests your strongest ordering — today the estate cannot score the example you lead with, because both its twins are servers. | (1) blocks the first rating MVP; the rest can proceed in parallel | waiting on human |
| N16 | The insurance pivot — four calls, all yours. (1) Who is the insured — the operator, the deploying business, or the agent vendor? The mandate names issuer and subject; a policy needs a policyholder, and the answer decides who buys. (2) What is RiskMandate in the picture — rating engine, MGA, broker, or standards body for the schemas? The regulatory burden differs by an order of magnitude. (3) Does the maturity model publish here (a standard, like the four rules) or live in the product (a moat)? (4) May the workbench demonstrate the flow end-to-end on fixtures — policy document, simulated excess-authority event, parametric trigger, computed payout — needing only the two proposed schemas? Also worth knowing: the 30 Aug workbench memo was never filed under /briefs/; say the word and it gets the same treatment as this one. | GM-D35/36/37 stay proposed until answered; the workbench demo is one release once (4) is a yes | waiting on human |
| N15 | Two calls from the workbench build. (1) GM-D34 / decision 6: the live mandate says repo.contents.push, the vocabulary says repo.contents.write — rename one, or define comparison; the engine refuses to guess. (2) Adopt evidence-pack/v0 into the pack, or reshape it — it is the JSON the memo says is the product, and it is marked introduced, not adopted until you say otherwise. | Nothing blocks the app; both are recorded honestly in the meantime | waiting on human |
| N14 | Commission the writing round? The brief is complete and the book is unwritten. Two things are yours: the title (locked as A Key Means Nothing Alone in the brief — it is the network's own description of this site, and a different one is a one-line change), and when. The brief follows the sibling estate's rule of one book, one fresh session, so it is not something to start and interrupt. Worth knowing before you decide: the book's honesty chapter would be materially stronger after N11 (a real issuer key), because today every chain in the register is a fixture and the book has to say so on nearly every page. Updated v0.1.34: the brief is now draft-2, tightened once on the evidence of the sibling estate's three finished books. It should not be revised again before it is executed — a brief that keeps improving is a brief nobody is writing from | Nothing blocks it; the book would simply describe a weaker estate today than after one enrolment | waiting on human |
| N11 | A real issuer key, so a mandate has authority as well as enforcement. The first compiled mandate is signed by the registry's operator root — a fixture, whose private half is published. So anybody can forge it and the hook would enforce the forgery just as diligently: the enforcement is real and the authority is not, and the two halves are independent. Closing the second needs one enrolment via the path the registry already ships (registry_tool.py enrol), run on a machine where the private half has somewhere to live — which is also what gives this site its first real trust root | Every mandate demonstration rests on a fixture root until this is done | waiting on human |
| N12 | Raise the branch constraint from setting to boundary? The hook is inside the grant it bounds, so --no-verify defeats it. The same allow-list evaluated where the agent cannot reach it — a branch protection rule on dev, or a required CI check — would make it a genuine boundary. That is a change of location, not of policy, and it is a repository-settings decision rather than the site agent's | Decides whether the pack's own worked example is a real control or a demonstration of one | open |
| N9 | One drawing language, or two. The registry MVP pack now carries six Wardley maps drawn in mermaid's wardley-beta diagram type — text in the repo, reviewable in a diff. sgit.ai's own strategy maps are hand-drawn inline SVG, which predates the capability. A reader crossing between the two sites meets two visual languages for the same idea. Converting is mechanical for simple maps and lossy for annotated ones, and it is not the site agent's call to make on another site. Related: W2 — why a rented agent cannot prove where it ran is the two-populations thesis in one falsifiable picture, and arguably belongs on nhi.sgit.ai rather than inside a PKI pack | Cosmetic until someone reads both sites in one sitting; then it is not | open |
| N7 | How much more of the corpus to publish. Tier 0 is done — thirteen documents live under Origins, plus a redacted edition of the review. What remains is a decision on Tier 1 (29 documents, each needing a one-line framing note so a proposal is not read as shipped) and Tier 2 (7 needing redaction). The redaction gate still stands for those tiers: a customer name and live-code findings appear in the source material | Tier 1 is the next increment of build-order step 1 | open — Tier 0 shipped, Tier 1 awaiting the call |
| N8 | Adopt or reject the proposed fifth rule. The four rules are published commitments and have not been renumbered. The fifth — the registry publishes its signed head on a stated cadence — is on the rules page as a proposal. Adopting it makes the append-only claim falsifiable rather than promised; rejecting it leaves that claim as a promise. Related and also yours: which verification mode ships first, since issuance is better for the customer and lookup is better for recurring revenue, and a site arguing for honest disclosure should say which it chose and why | The rules are the site's load-bearing commitment; a fifth is not the site agent's to add | waiting on human |
| N5 | Confirm the execution-layer name. This site publishes it as execution broker rather than Service Twin, on the pack's own argument that a digital twin represents a thing while this acts on one. If the product line settles on a different name, this site should follow it rather than diverge | A naming split between the site and the product would be worse than either name | open — proceeding with "execution broker" unless redirected |
| N4 | Presentation material to recycle. The scoping brief notes 31 files referencing presentation material the project lead wanted reused — worth an infographics section if the posts are identified, as on nhi.sgit.ai | No infographics section until the material is identified | open |
| N10 | One question for the parent’s API reference, and it gates a whole layer. The observability design has checkers write check events into the issuer’s own append lane. The lane’s configure endpoint registers append anchors as hashes of accepted senders — and the reference does not say whether a lane with no anchors configured accepts any holder of a token, or refuses everything. If anchors are required, only checkers the issuer already registered can report, and the relying parties you most want to observe are exactly the ones you do not know about. This is a documentation gap on sgit.ai rather than a decision for this pack, and it has to be answered before the layer is committed | Decides the coverage of the observability layer; recorded as pack decision 18 | waiting on the parent project |
Task board
| # | Task | Owner | Status |
|---|---|---|---|
| T1 | CI pipeline: validate → auto-tag → deploy to Pages, adapted from the NHI site; validation extended to pull requests; canonical-host check added | site agent | done v0.1.0 |
| T2 | Theme carried over from sgit.ai / nhi.sgit.ai, with this site's additions (rules ladder, timeline, claim block, safe/fatal split columns) | site agent | done v0.1.0 |
| T3 | Shared chrome: nav and footer now come from one definition in admin/build/chrome.py and are rewritten in place across every page, so the version badge that CI enforces cannot drift. Pages stay hand-written HTML — only the chrome is generated | site agent | done v0.1.3 |
| T4 | Refactor the PKI section across from nhi.sgit.ai and promote it to a site: the failure, the rules, mandate (new page), build order (new page), documents, disclosure | site agent | done v0.1.1 |
| T9 | Release-pipeline fix: the tag job anchors on the newest release commit reachable from HEAD instead of on HEAD itself, so a pull request landing as a merge commit no longer stops the release. Found by the pipeline's own first run on dev | site agent | done v0.1.2 |
| T10 | Acted on the site review: bootstrap, enrolment, execution and shipped pages; the front-page three-layer model and reframe; mandate and rules extended; two principles published verbatim; nine documents captured with reader pages | site agent | done v0.1.3 |
| T11 | Third-party market research on the execution layer: published as its whitespace finding and acceptance test only, not as a captured document — its vendor scoring is a dated snapshot and it was written to a brief rather than as neutral research. Revisit if it is ever re-run independently | project lead + agent | decided v0.1.3 |
| T12 | Registry MVP pack: five draft briefs (leading, architecture, schemas, first-client workflows, build order) captured under briefs/ with reader pages; roadmap step 4 moved to planned | site agent | done v0.1.4 — awaiting N6 review |
| T13 | Three v0.33.61 briefs captured with reader pages: register/fixtures, grant vs mandate, site access report | site agent | done v0.1.5 |
| T14 | Packs section (gen_packs.py, treatment from nhi.sgit.ai): the registry MVP pack republished as a dev pack with diagrams, change control and the tabletop exercise as first-class documents | site agent | done v0.1.5 |
| T15 | Site access report acted on: the which-third sentence on the front page, page-level links into sgit.ai/docs (pki, vault-messaging, limitations), and the constructed-path convention promised in llms.txt. Remaining for the other two sites: nhi.sgit.ai should name the shipped commands (its own N-table), and the hub subdomain resolution check | site agent | done v0.1.5 — this site's share |
| T16 | Release-pipeline fix: the tag job read git log through a pipe into grep -m1, so git log died of SIGPIPE and pipefail failed the job — a race that only appeared once the history outgrew the pipe buffer, which v0.1.5 did. The history is now read once and matched through herestrings. Verified against the failing commit, 25 clean runs, and all four guard cases | site agent | done v0.1.6 |
| T17 | Corrections C1–C3 applied to shipped: the over-generalised algorithm claim (this site's own error, recorded not edited), the verified-versus-trusted provenance note, and the registry that was built in February and retired in June | site agent | done v0.1.7 |
| T18 | Origins section: the four-act arc, 13 Tier-0 primary sources published verbatim (each re-scanned for secrets and identifiers), the retired registry as prior art, and a redacted public edition of the review. Answers the review's gaps A and B | site agent | done v0.1.8 |
| T19 | Still available from the review and not yet done: reclassify open questions 1, 4, 5 and 6 from open to argued here, decision pending — the review rates it the highest credibility-per-hour item on its list | site agent | queued |
| T20 | Open questions reclassified (the review's highest credibility-per-hour item): four of six now read argued, decision pending with links, and the eight opened on 20 August are captured on the roadmap | site agent | done v0.1.9 |
| T28 | The book commissioned: a complete brief for A Key Means Nothing Alone, written after reading how graphs.sgit.ai commissioned its three books (brief 38, and the shape the first actually took). Fifteen chapters in five parts, twelve gated figures, a RiskMandate chapter written as a contract, and an acceptance test that fails the book if a reader finishes trusting the register. Superseded by T29 the same day — see draft-2. Needed from you (N14): confirm the title and whether the writing round happens now. | site agent | done v0.1.33 — brief only, book unwritten |
| T56 | The stale badge. The project lead saw the release row at v0.1.73 and the menu badge at v0.1.72 on an iPad: version.js is cached for ten minutes. nav.js now refetches it past the cache and refills the badge if it moved. | site agent | done v0.1.74 |
| T55 | The prompt pack. Build your own: a brief an agent is pointed at (guess/prompt.md), with the twelve rules, the reading list, the data URLs, the two-step exchange (plan, then build) and what will be checked; the page renders it and carries the link and a starter line to paste. | site agent | done v0.1.73 |
| T54 | Brief v0.33.65 and the memo on the game's shape, built. The mesh as files under probes/mesh/ with one ontology and gates; reach as a node; two question classes and a reliability per question; the gap collected throughout; the two-column play screen with the three-class inspector; demo mode; the mesh navigator; the report; the sources page with edit links, so a correction is an edit. | site agent | done v0.1.72 |
| T53 | The game named Which Agent Is It? on the project lead's proposal, with the three edits (try, no risk claim, the prediction step on the front door); menu, bench, reader page and llms.txt follow. | site agent | done v0.1.71 |
| T52 | The menu, the graph, and the game's two corrections. A Measure group in the nav; the grant as a graph for every profile; the verdict box made legible on phones; the container profile's rows retold from the container's point of view (host is the vendor's container, the keys are the session's own, the token is the platform's), with reach_names, a cannot-reach list and a control chip on every row; the harness measured as a third tool, whose code-host API tool bypasses the clone's hooks. | site agent | done v0.1.70 |
| T51 | The 4 September briefs' repository, site and game, built as three bench MVPs. Probes, not tables (primitives, a probe registry, a runner emitting findings/v1 in Scorecard's shape plus reversibility and tier, seven profiles with two measured, an incident that demotes), what you authorised and never asked for (the verdict-first self-assessment in the browser; the site cannot scan anybody and says so) and guess the agent (the deterministic tree with the prediction step; a prediction gap, never a surprise). The four briefs and the day index filed; reader pages; the bench entries with what each does not prove; IE-D24 (the conformance vault's conditions/exclusions belong on policy/v1) and IE-D25 (evidence mode is the axis; the instrument mapping as a proposal); the pack's llms.txt. | site agent | done v0.1.69 |
| T50 | Memo 13 processed and built the same day. Brief v0.33.85, doctrine 13, GM-D104–108; the pack amended (IE-D17–23, IE-C8) and climbing its own ladder: a level on every event, reconcile.py at level five (eleven commits, no catch), policy-report.yml at level four in report mode, the room's sixth card. The push-policy loop fixed by a queue. The limits raised for now on your word (policy r3). | site agent | done v0.1.68 |
| T49 | The version badge is read at load time. chrome.py writes assets/version.js once per release; nav.js fills the badge and the footer from it; validate.js gates that version.js agrees and that a page without a literal badge loads it. The one-time rewrite that removes the literal from ~230 pages is the last such commit, and it is refused by the pack's own pre-commit hook as an exclusion (~4 MB) until a human accepts it — see N30. | site agent | done v0.1.66 |
| T48 | The insurance ecosystem pack, from the two v0.33.62 briefs. Eleven documents plus change control, written after the nine-item inventory (no board application; the messaging vault is the append lane; thirty-three hook events and the platform fails open on timeout; all eighteen June briefs read; the anchors question still unstated), under the project lead's pilot relaxation. tools/policy.py, two hooks, two policies, a token meter, a room. Step 1 built and run with git's own output. The pack published itself under its own hook: drawn, requested, refused — the ledger has all of it. | site agent | done v0.1.66 |
| T47 | Memo 12 processed and the first MVP built. Brief v0.33.84, doctrine 12, and insurance/push-policy: a policy document, a checker, an append-only ledger, a sample hook and a Claude skill at .claude/skills/push-policy. The claim is the draw: paid in the resource, settled by the check. The pool is shared per repository. The skill is a setting and says so. GM-D97–103 proposed. Run against this estate before the doctrine was written: twelve of twelve releases refused. The hook is shipped, not installed. | site agent | done v0.1.65 |
| T46 | Captured the four partner artefacts into /partner/, with provenance and evidence class stated before anything else. Published the landing page (byte-exact, sandboxed frame) and the design partner deck (PDF plus text extraction); held the two RAMM-I documents pending your word, because this site publishes every file in the repo. Wrote provenance and a first-pass concordance. The headline finding: four of your partner's five primitives are the same objects as ours under different names, three guard-rails were derived independently and identically, and there is one real collision on the scale. The honest framing throughout: the survey has not been run — somebody else's survey has been received, and every market claim inside these artefacts is documented class, verified by nobody here. Three new gates, self-tested: a per-artefact sha256, a refusal to publish a held document, and chrome/validator exclusions so this estate never edits a document it does not own. | site agent | done v0.1.63 |
| T45 | Synced with dev (the insurance book at v0.1.61) and processed memo 11. Yes — I see the opportunity, and it is larger than the buffer. The pool is the first mechanism in this pivot that does what insurance does rather than what underwriting does, in a currency that needs no carrier; and a budget overage is the first loss event this estate can obtain, because the supplier already records it for billing. That dissolves GM-D78's collision and answers doctrine 07's who checks first in one move. GM-D86–96 proposed; GM-D78 resolved, GM-D81 amended. One correction to the memo (GM-D87): the pool does not define the grant — it bounds volume, never reach, and the cheapest catastrophic action is cheap. And the v0.33.82 gate earned itself: filing memo 11 fired it on doctrine 10 and on all eight footers, so it was rewritten to forbid a hand-typed series total rather than check one. | site agent | done v0.1.62 |
| T44 | All eleven insurance readings audited against their transcripts, at your request. Brief v0.33.82 — the first brief here with no voice memo above it, because it is me auditing me. The verdict is that I agree with the interpretation. The expensive things were got right: the two-stage split, the three referents one word was covering across memos 5 and 6, the Fibonacci repair, and the 2D-first sequencing labelled as a disagreement rather than an extension. All four corpus quotations verify verbatim at the dates claimed. Six defects found and fixed in place — three stale counts (now gated, and the gate caught real text on its first run), the tier identified with the wrong quantity, an over-claim of immunity, and a question dropped between brief and doctrine. GM-D81–85 proposed; GM-D52 narrowed. No transcript was touched and no settled decision reopened. | site agent | done v0.1.60 |
| T43 | Memo 10 processed — the series is closed at ten, and insurance/llms.txt ships as you asked. Brief v0.33.81 and doctrine 10: a warranty is a fact plus a maximum age failing three ways; a third clock; metering uses vs metering checks; and schemas rather than APIs. GM-D76–80 proposed. The llms.txt is generated from the manifest so it cannot drift, and leads with the four things an agent must carry — not insurance, not built, no evidence gathered, register is fixtures. Totals: 10 memos filed verbatim, 11 doctrine documents, 46 decisions from this pivot (GM-D35–80), one of them settled. | site agent | done v0.1.59 |
| T42 | Memo 9 processed. Brief v0.33.80 and doctrine 09: the positioning with its guard-rail, the survey specified as a dated re-runnable measurement, and the mapping that upgrades a rule — the declared-versus-measured gap is the shape of material non-disclosure, so the card-versus-twin gap decides voidability rather than merely a worse level. GM-D72–75 proposed. The series grew 8 → 10 and the counter gate caught it — corrected on the hub with the reason, not quietly. And the honest headline: seventy-one decisions, zero external evidence. The survey would be the first fact. | site agent | done v0.1.58 |
| T41 | Memo 8 of 8 processed — the series is complete. Brief v0.33.79 and doctrine 08. It corrects my own MVP proposal: the first one is an explainer, not a calculator, because an instrument answers a question somebody already knows how to ask while an explainer creates the person who can ask it. Also: stage 1 needs asset class not asset value; Fibonacci resolves against the settled scale as a band-definition proposal rather than a scale change; and the load-bearing requirement — the world must show its own emptiness, because a polished simulation is the most effective way yet devised to make a demonstration look like a product. GM-D67–71 proposed. All eight memos filed verbatim and read; nine doctrine documents; 41 decisions from this pivot alone. | site agent | done v0.1.57 |
| T40 | Memo 7 of 8 processed. Brief v0.33.78 and doctrine 07: policy/v0 is a mandate-shaped statement needing no new register machinery; a policy does not sign, its subject does; and the relying party is where this pivot can finally reach a boundary — resolving the limit memo 5 recorded. Two corpus lines re-read and quoted verbatim, one of which (trust is a path) your memo re-derives four days after the estate published it. GM-D62–66 proposed. Also fixed a counter that had just become false: the hub said 8 of 8 because it counted the pivot briefing as one of the eight. It now counts only the series and refuses duplicate memo numbers — self-tested. | site agent | done v0.1.56 |
| T39 | Memo 6 of 8 processed. Brief v0.33.77 and doctrine 06: the broker's own policy as what stops we reduce your level by X being apparent authority; the claimed reduction computed by the method rather than the vendor; and a correction — a broker changes the grant's topology rather than narrowing it, so the net may be positive and deployment topology is a rating variable. Elective delta gains a cost-to-close dimension, which holds the case your memo named that the taxonomy could not. GM-D58–61 proposed. 7 of 8 memos processed; one to go. | site agent | done v0.1.55 |
| T38 | Memos 4 and 5 of 8 processed — briefs v0.33.75 and v0.33.76, doctrine 04 and 05. Cyber insurance carried as the cautionary tale and the empirical case for the checkability rule; the enforcement tier identified as an impact-reduction measure — the thing security has never been able to price, which this estate has been computing since v0.1.28 without naming it; the not-in-line position and its consequence that this project can never itself be a boundary; and openness as the substitute for capital. GM-D51–57 recorded, with GM-D54 settled. | site agent | done v0.1.54 |
| T37 | Memo 3 of 8 processed. Brief v0.33.74 (rendered) and doctrine 03: the delta classified by who could have closed it, platform granularity as a library artefact, the world as a rating input with its own freshness, and direction-not-magnitude. GM-D45–50 proposed. Found while checking the memo against our own twin: measure.py has no node for commit authorship, which a push credential confers absent signed commits — recorded as GM-D50, not patched, because the interesting fact is that a conversation found what the tool did not. | site agent | done v0.1.53 |
| T36 | Memo 2 of 8 processed. Brief v0.33.73 (rendered) and doctrine 02: the roles as the integrity mechanism, the rating as a go-live gate rather than a report, and the pack's three-tier test applied to the insurance apparatus itself — a gate the deploying team can edit is a setting, so the engine declares its own tier. GM-D42–44 proposed; GM-D41 narrowed (reinsurance gives the hierarchy's shape, not the correlation). Correction to last release: I said the first MVP waits on your level scale. The control-to-premium counterfactual is scale-free and does not — see N18(4). | site agent | done v0.1.52 |
| T35 | The insurance folder created and memo 1 of 8 processed. /insurance/ is the body of work — memos, doctrine, MVPs — generated from a manifest whose gates fail in both directions and refuse a doctrine document with no does not prove. Memo 1 filed as brief v0.33.72 (rendered): money decoupled from rating, which removes the regulatory blocker memo 0 called fatal, and contradicts memo 0's own argument for the pivot — answered with GM-D39, every rating ships its derivation. Two doctrine documents written; GM-D38–41 proposed. No MVP yet, and the hub says why: the first one waits on your answer to the level scale. | site agent | done v0.1.51 |
| T34 | The insurance pivot filed as brief v0.33.71 (rendered · raw) — memo verbatim, then the mapping: insurance vocabulary onto the estate's primitives (policy schedule = mandate; exclusions = prohibitions; warranties = facts; insurable interest = the delta; underwriting evidence and proof of loss = the evidence pack; renewal = re-measurement, which answers GM-D16's cadence question), the insurer as the acceptor the excess-authority view's null has been waiting for, parametric as the first demonstrable shape, and a four-band maturity model read off existing tiers. GM-D35/36/37 proposed; nothing rebuilt on the pivot until adopted. | site agent | done v0.1.50 |
| T33 | The data viewer at /data/ — the markdown reader's treatment for JSON, as you asked. ?src= any document on the site; rendered and raw, where raw is the real bytes rather than a re-serialisation; and the signature verified in the browser against the signer's registry record, with not checked here kept distinct from does not verify. Checked against all 23 signed statements first — all verify. Linked from the workbench, the register and every record page, with the raw file always one click away and registry/llms.txt telling agents to keep fetching the .json. Two new build gates: viewer links must name a document that exists, and no page may load the same script twice — the second found 22 book pages loading the markdown reader twice, now fixed. | site agent | done v0.1.49 |
| T32 | Every register record has a rendered page (example), after you found the workbench's identity cards 404ing on a phone. They linked to a directory. Rather than repoint them at raw JSON, gen_records.py now builds an identity card per record: fixture-or-real class first, what the register answers about that subject, then every signed statement in append order with its type explained — a revocation rendering as a later card rather than a deletion. Key material linked, never printed. Also fixed: the source link inside saved evidence packs had been recording that same dead URL. | site agent | done v0.1.48 |
| T31 | The workbench built from the 30 Aug voice memo — a mini-app over the primitives: rail, cards, the GitHub-push scenario, a simulator, and an evidence pack per decision (evidence-pack/v0, GM-D33 proposed). The mandate signature verifies in-browser against the issuer's registry record; facts flip the enforcement tier live (N12 rehearsable); drafts and packs stay in localStorage. Found GM19: the live mandate's capability is outside the declared vocabulary under exact equality. Complements the card simulator and the experiments built in parallel: theirs replay and play this estate's history; the workbench decides a fresh action and keeps the evidence. The memo's last step is ready when you are: an agent at a real decision point emitting the same pack shape with mode: enforcement — the try-it-on-Claude-itself move needs nothing the page does not already define. | site agent | done v0.1.47 |
| T30 | The book brief rendered in the estate's own markdown reader at /book/brief.html, instead of being published as raw markdown only — the same apparatus the documents use: metadata, summary, key concepts, key ideas, then the file rendered in-page by assets/mdreader.js, with the raw markdown still the source of truth and reachable from three places on the page. Answers a question from the project lead: what is the link to the brief pages on the site? — and the honest answer had been that there was not a proper one. | site agent | done v0.1.35 |
| T29 | Book brief revised to draft-2 after all three sibling books finished. Three tightenings, each on evidence rather than taste: figures are time-travelled to the release tag their caption names (git worktree, one-shot port, browser killed in a finally) rather than photographed today — because the refused push happened at v0.1.28 and a reconstruction wearing a caption is a claim of authority nobody granted; a provenance rule marking every load-bearing claim stated (verbatim quote, re-read out of its source on every build) or drawn (the session's own reasoning, shown), because blending them is the same error the book diagnoses; and a chapter on where the estate contradicts itself and what it does not say, computed rather than recalled. Seventeen chapters plus a harness appendix. Draft-1 superseded, not deleted — it is at tag v0.1.33. | site agent | done v0.1.34 — brief only, book still unwritten |
| T27 | The bench — a first-class section for shipping MVPs and experiments, seeded with the six things already built. Each entry declares what it demonstrates and, mandatorily, what it does not prove; gen_bench.py refuses to build without that field or without gates, verified by emptying one. Adding one is a dict plus a folder with its own code. Named the bench rather than labs — the reasoning is on the page and it is a one-line rename if you prefer otherwise. Also: GM-D32 answered — RiskMandate consumes the block stylesheet rather than forking it. | site agent | done v0.1.32 |
| T26 | Brief #3 written and built. Document 09 derives the badge/card/block/visualisation specification from the two v0.33.62 briefs rather than waiting for a third; assets/gm-blocks.css and the gallery are the components, rendering the real library entries and signed mandate. Two new rules the build produced: a defeated control never renders as a boundary (GM-D29 at the interface layer), and a mandate carries two indicators — enforcement and authority — never one. GM18: the gallery caught two schema violations in the hand-assembled library entry on first render; the tool-generated entry had none. | site agent | done v0.1.31 |
| T25 | The deliveries recorded, and the registry pack's status corrected. Document 08 is the build record for v0.1.26–v0.1.29, naming a fetchable artefact for every claim and carrying a flat list of what is still only written down. Registry pack C33 supersedes its own unbuilt status (three places, all accurate when written); C34 records the readiness report and the three of six blocking questions the build answered. Found while doing it: the discipline recorded corrections and no deliveries, so the corpus understated what it had built — now decision GM-D30. | site agent | done v0.1.30 |
| T24 | Build-order step 1 of the Grant & Mandate pack, built and tested (document 07): a signed mandate compiled into a pre-push hook, and a push to a branch it does not permit refused by git with error: failed to push some refs. Tier reached: setting, not boundary, stated on the refusal banner itself. Plus tools/measure.py, the measurement method made runnable anywhere — it reports presence and reachability, never contents, and records refused probes as unknown rather than guessing. Needed from you: a real issuer key (N11) and a decision on whether to raise this to a boundary (N12). | site agent | done v0.1.28 |
| T23 | The Grant & Mandate dev pack — a first pass at the pack the two v0.33.62 briefs specify, seven documents plus change control and one measured library entry. The library/instance split stated as a data rule (registry holds the library, no personal data ever; risk product holds the instance, references not copies); reality-before-risk and the three-term comparison as constraints; Cedar and graphs.sgit.ai adopted rather than reinvented; the mandate document named as the one thing to build. The first library entry was generated by measuring this session's own environment, which refused to self-measure — recorded as a boundary control caught on the measuring agent. Corpus version and formal adoption remain the project lead's. | site agent | done v0.1.27 — awaiting review |
| T22 | The registry's first MVP shipped as a static register at /registry/ — eleven records (ten fixtures with published private halves, one real), four assumable roles with drop-in sgit keystores, mandates, a grant with the document-12 tree, acceptances and revocations. sgit-native by execution against sgit-ai v0.16.0 (bundle, fingerprint and raw r||s signature formats round-tripped both directions); record model is C7's commit graph, first implementation; six expected verification answers ship as data and the registry validator reproduces them in CI. The write path today is a git commit reviewed by a maintainer, stated as such. Preceded by the readiness report the briefing pack asks of a fresh session — six blocking questions, three closed here by execution (record model, the CLI reconciliation, processor transparency for the git path), three still N6's | project lead + outside session | done v0.1.26 |
| T21 | Four v0.33.61 briefs processed: history/append-only, notary, register UI, and the superseded grant brief. Pack change control C7–C10; proposed fifth rule published as a proposal | site agent | done v0.1.9 |
| T5 | Markdown twins for every page + llms-full.txt (the sgit.ai convention) — only the front page has one | site agent | queued |
| T6 | The collection (build-order step 1): curate the 729-file corpus by question, promoting the Feb–Mar architecture material | site agent | blocked on N2 |
| T7 | Redirect the nhi.sgit.ai PKI section here once this site is live on its domain — that section was always staging, and the NHI site queues the spin-out as its T19 | site agent | queued — after N1(c) |
| T8 | The private registry (build-order step 4) — the first thing built rather than published | project lead + agent | queued — the next build |
How to use this channel
- Human → agent: reply in the working session, or edit this page / open an issue in the repo. Anything added under "Needed from the project lead" with an answer gets actioned next session.
- Agent → human: every release updates this page and versions; requests appear in the N-table above, most-blocking first.
- Decisions log: the site ships the pipeline before the content, so every release goes through a gate that already works; the PKI section was refactored across from nhi.sgit.ai rather than rewritten, so the two sites stay diffable; source briefs are captured verbatim under
briefs/with a curated page alongside, so the raw document and the presentation coexist; and the open questions are published unresolved rather than settled quietly.