The network: sibling boundaries
This site catalogues; it does not generate, and it does not argue. Two sibling sites already own adjacent ground — the arguments an infographic illustrates, and the tooling that could render one at scale. This page states where each boundary sits.
The siblings
| Sibling | What this site would duplicate if careless | Where the boundary sits |
|---|---|---|
| sgit.ai | The vault delivery substrate, the shipped CLI | Cite, don't re-explain. This site is a plain static gallery, not a vault app — it does not need or use vault delivery |
| graphs.sgit.ai | The brief itself, and its own documents/ section, which already renders every brief as readable prose | This site never restates a brief's argument. It links to the brief and the rendered document, and stores only the picture made from either. The first catalogued entry is drawn from a graphs.sgit.ai brief; this site is downstream of it, not a replacement for it |
| newsroom.sgit.ai | Provenance and citation-chain arguments — "an article is a projection of a story" | Newsroom argues why provenance matters editorially; this site is one specific, narrow application of the same discipline to one artefact type (a rendered image), with a machine-checked contract (admin/build/validate.js check 8) rather than an essay about it. Newsroom's own brief pack (00__BRIEF.md §5) already anticipated a site like this one under the working name /infographics/ |
| pki.sgit.ai · nhi.sgit.ai · sg-sentinel.sgit.ai | Identity, trust and reputation graphs | No overlap. An entry here states who or what rendered an image (a generator field, plain text), not a signed identity claim about it |
The infographic-generation pipeline this site does not run
graphs.sgit.ai's own brief pack (briefs/04__visual-assets-and-infographics.md) documents a real, working pipeline: a hosted tool at dev.tools.sgraph.ai/infographic-gen, driven by Playwright, generating a PNG per call via an image model for roughly $0.07 each, across seven templates. infographics.sgit.ai does not call that pipeline, and does not assume any catalogued entry was made with it. Every entry's generator field states plainly how the image was actually made — for the one entry catalogued so far, that is "pasted into ChatGPT by hand," not the documented tool. Conflating "an infographic exists" with "the pipeline produced it" would misrepresent both the entry and the pipeline's own adoption, so this site keeps the two facts separate rather than letting the existence of the tool imply its use.
Open, published unresolved
| # | Question |
|---|---|
| Q1 | Should this site eventually crawl sibling briefs/ folders for candidate infographics, or stay hand-curated? Hand-curated is a possible-but-real trust decision, not a limitation to silently automate away — see comms |
| Q2 | If an infographic is later regenerated from an updated brief, does the old rendering stay catalogued (supersede-never-delete, the convention every sibling site uses) or get replaced? Not yet decided — there is exactly one entry, and it has not yet needed a second version |
| Q3 | Should library/data/catalogue.json eventually federate across every *.sgit.ai site's own local catalogue, or should this one repository stay the single store? The storage-model decision behind this site (see briefs/01) chose "store the files here," which argues for staying the single store, but that has not been tested against a second contributing site yet |
For an agent
This site's remit is storage and cataloguing of rendered infographic images, with a machine-checked link back to each one's source brief. For the argument an infographic illustrates, read the source site named in its source_site field — do not attribute that argument to this site. For the tooling that can render an infographic from a brief, read graphs.sgit.ai/v1/briefs/04__visual-assets-and-infographics.md — do not assume this site's own entries were made with it unless their generator field says so.