Why publishing is a distinct act
Most of the work you do inside Krataxis happens on a living surface. A battlespace is continuously fed by ingestion, re-scored as new sources arrive, re-drawn as actors move and territory changes hands. That constant motion is exactly what you want while you are analysing — it keeps the picture honest and current. But it is the opposite of what you want the moment you decide to say something in public.
When an analyst publishes a finding — a brief to a newsroom, a situation map shared with stakeholders who have no Krataxis login, an interactive graphic embedded in an article — they are making a claim about a particular moment. "Here is what the evidence showed on the morning of the 23rd." That claim has to stay true. If the map a reader opens next week silently shows different events, different front lines, a different story, then the analyst has not published a finding at all; they have published a moving target, and their credibility moves with it.
Publishing, then, is not simply "sharing your screen with the outside world." It is the deliberate act of taking a slice of a living system and freezing it into an artifact — something fixed, addressable, and citable, that will read the same to everyone who opens it for as long as it stays live. The publishing platform exists to make that act safe, repeatable, and honest. This chapter introduces the ideas the rest of the section builds on; you can read it straight through before you ever touch the producer flow.
A note on terminology. Krataxis can publish two different kinds of artifact. Published reports are the textual, statistical products of the Analytics Engine, and they live at addresses beginning
/r/. Published maps — the subject of this section — are the interactive, spatial products of a battlespace, and they live at addresses beginning/p/. They share a philosophy and much of their machinery, but they are distinct tools. Everything below concerns published maps unless it says otherwise.
The snapshot principle
The single most important idea in this whole section is the one we have already begun to circle: a published map is a frozen snapshot, not a live window.
It helps to picture what is actually happening underneath. When you publish, the platform does not hand the public a connection to your battlespace. Instead it walks through the slice you have chosen — the specific events, the actors, the layers, the camera position, the captions you wrote — and copies each of those things, by value, into a self-contained payload. That payload is then sealed. From that instant on, the public artifact is rendered entirely from the sealed copy. Your battlespace can churn all it likes; new events can pour in, scores can shift, you can redraw the whole northern sector — and the published map will not so much as flicker, because it is no longer reading from the battlespace at all. It is reading from the photograph you took of the battlespace.
This is what we mean by the snapshot principle, and it has a few consequences worth internalising early:
A published map can never leak something you did not put in it. Because the freeze copies only the slice you selected, anything you left out simply does not exist in the public payload — there is no live query a curious reader could coax into returning more. This is the foundation of the platform's safety story, and we return to it below.
A published map is reproducible. Two people opening the same link see byte-for-byte the same thing, because there is only one sealed payload behind that link. This is what makes a published map citable — a journalist can point to it in a footnote and trust that it will corroborate them.
And a published map is, by design, slightly stale. That is not a defect; it is the entire point. The price of a fixed, trustworthy artifact is that it stops tracking reality the moment it is sealed. The platform's answer to staleness is not to quietly update the artifact — that would break the snapshot principle — but to let you republish, which we cover next.
Versioning: how a snapshot stays honest over time
If a snapshot is frozen, how do you ever correct or update it? The answer is versioning, and it is deliberately built so that updating a map never rewrites history.
When the underlying picture has moved on enough that your published map no longer reflects the situation, you do not edit the live artifact in place. You republish: the platform takes a fresh snapshot against today's data and seals it as a new version. The previous version is not destroyed. It is marked as superseded — it still exists, still renders from its own sealed payload, but it now knows that a newer version exists. A reader who arrives at an older version's link is shown a gentle banner telling them a more recent version is available, rather than being silently redirected or, worse, silently served different content under the same URL.
This chain of superseding versions is what lets a published map evolve without ever betraying the snapshot principle. Each version remains a faithful record of what the evidence showed when it was sealed. The history is additive: you can always answer the question "what did this map say in March?" because the March version is still there, still frozen, still labelled. The platform tracks which version is the current one — the latest — and surfaces that fact to readers, so that the freshest picture is always the easiest to find while the older record remains intact for anyone who needs it.
The discipline this enforces is worth stating plainly, because it is a matter of intellectual honesty rather than mere mechanics: if the data changed, you make a new version and leave a trace. You never reach back into a published claim and quietly alter it. Readers who relied on the old version can see that it has been superseded and can find out what changed; they are never misled into thinking the picture was always what it is now.
The public-token safety model
A published map is, by definition, something you are exposing to people who have no account, no session, and no membership in your tenant. That makes its safety model a first-class concern rather than an afterthought, and the platform's approach rests on two pillars: what identifies a public artifact, and what the artifact is allowed to contain.
The first pillar is the public token. Internally, every object in Krataxis is keyed by identifiers — integer row IDs and UUIDs — that carry information about your tenant, your schema, and the shape of your data. None of those identifiers ever appear on a public surface. Instead, when a map is published, the platform mints a single opaque, random token and uses only that token to address the artifact publicly. The public URL is /p/{token}; the public API speaks in tokens; the embed code carries a token. Because the token is random and meaningless, it reveals nothing about your account or your data, and it cannot be incremented, guessed, or reverse-engineered into a different map. If you ever need to take an artifact down, retiring its token makes the link go dark immediately and uniformly — a retracted map returns the same "not found" response as a token that never existed, so the very existence of a particular map is never disclosed.
The second pillar is the freeze itself, which we have already met under the snapshot principle. Because the public payload is an allow-listed copy — the platform deliberately enumerates the fields it is willing to expose and copies only those — the safety guarantee is not "we remembered to hide the sensitive fields" but the far stronger "the sensitive fields were never copied into the public artifact in the first place." There is no live connection to over-share through, and there is no hidden field tagging along inside the payload. What you selected is what exists publicly; nothing else does.
Taken together, these two pillars mean that the question "could this published map leak something it shouldn't?" has a structural answer rather than a hopeful one. The artifact contains only an allow-listed copy of an explicitly chosen slice, and it is addressed only by a meaningless token. Safety is a property of the design, not of remembering to be careful each time.
Visibility: public, unlisted, and the private default
Freezing a map and exposing it to the world are two separate decisions, and the platform keeps them separate on purpose. A freshly created map begins life private. A private map is yours alone; it has no public presence, and — importantly — the producer interface will not let you publish it at all until you have made a deliberate, explicit choice to do otherwise. This is a guard against the most common publishing accident, which is publishing something before you meant to. The system never defaults a map into public visibility; it makes you say so.
When you are ready, you choose between two non-private visibilities, and the difference between them is about discoverability, not access control:
A public map is openly visible. It is the right choice for a finished product you want people to find, cite, and share — a map that is meant to be part of the public record.
An unlisted map is reachable by anyone who has the link, but it does not advertise itself. It is the right choice for a draft you want to circulate to a few colleagues for review, or for a soft launch before a formal announcement — the artifact is live and shareable, but it keeps a low profile.
The mental model to carry is that visibility governs who can stumble onto the map, while the token governs who can reach it at all. An unlisted map is still protected by the unguessability of its token; what "unlisted" adds is that the map declines to surface itself in any public listing. Choosing visibility is therefore a question of intent — "do I want this found, or merely reachable?" — and the platform makes you answer it consciously every time.
The lifecycle, end to end
It helps to hold the whole arc in your head before diving into any one stage, because each tool in this section is really just one phase of a single lifecycle.
It begins with authoring, inside the live map workstation. You decide which events, actors, and layers belong in the public slice; you compose the camera and the reader-facing controls; you write the narrative captions that turn a map into a story; and you set the title, summary, and visibility. This is the producer flow, and it is the subject of the next chapter, Publishing a Map.
When you publish, the slice is frozen and sealed, a token is minted, and the artifact goes live at /p/{token}. From that point the work changes character: you are no longer authoring, you are managing. The same producer surface now lets you unpublish, republish into a new version, and reach for two distribution tools.
The first distribution tool is the public viewer itself — the anonymous, login-free experience a reader gets when they open your link, complete with scrollytelling and time-based reveal if you authored them. The second is embedding: dropping the map, live and interactive, straight into someone else's web page. Both are covered in The Public Viewer and Embedding.
Finally, once a map is out in the world, you will want to know whether anyone is reading it. The platform answers that question with a deliberately privacy-first analytics layer — a first-party daily view counter that records no personal data whatsoever, complemented by an optional cookieless audience-analytics integration for richer detail. That story, including why it is built the way it is, is told in Understanding Your Readership.
Read in order, the next three chapters take you from a living battlespace to a published, embedded, measured artifact. But each also stands on its own, so if you have already published a map and only want to embed it, skip ahead — the lifecycle is a loop you will travel many times, and you can join it wherever you need to.