KRATAXIS Docs
Search the documentation… ⌘K Back to site ↗
Knowledge Base / Publishing & Sharing / Publishing a Map — The Producer Flow

Publishing a Map — The Producer Flow

A guided account of authoring a public map: opening the producer, choosing what to include, composing the camera and reader controls, writing the narrative, setting visibility, previewing the frozen result, and managing the map after it goes live.

Last updated 2026-06-23

From a living map to an authored artifact

The previous chapter argued that publishing is the deliberate act of freezing a slice of a living battlespace into a fixed, public artifact. This chapter is about doing it. The tool that carries out the act is called the producer flow, and the thing it produces is a published map.

Before walking through it, it is worth being clear about what kind of work authoring actually is, because it shapes how the interface is laid out. Authoring a published map is not a single button-press; it is a small editorial process. You are deciding what your audience should see and, just as importantly, what they should not see. You are choosing the vantage point from which they will first look at the scene. You are deciding whether to let them scrub through time or hold them at a fixed moment. And you are writing the words that turn a collection of map features into a story with a beginning, a middle, and a point. The producer flow is organised around exactly these decisions, in roughly the order you would naturally make them.

Opening the producer

The producer flow lives where the analytical work lives: inside the map workstation, attached to a battlespace. This is deliberate — you author a public map from a battlespace, by curating its contents, so the tool meets you there rather than in some separate publishing console.

In the workstation's left-hand tool rail you will find a Publish Map control. It appears only when a battlespace is active, because a published map is always a slice of some battlespace and there is nothing to publish without one. Activating it slides open the producer drawer. If the control is absent, the cause is almost always that no battlespace is currently selected; choose one and it will appear.

The drawer opens on a list of every map you have already authored from this battlespace, in any state — drafts you never finished, maps that are live right now, maps you have since taken down. We will come back to that list, because managing existing maps is half of what the producer is for. But the first time through, the list is empty and the only thing that matters is the button labelled New published map, which begins a fresh authoring session and drops you into the heart of the flow.

The shape of the authoring flow

Authoring proceeds through four stages, and they are presented as a sequence because each builds on the one before. You choose what is in the map, then how it is framed, then what it says, and finally how it is described and exposed. You are not locked into a rigid wizard — you can move between the stages freely as you refine — but the order reflects the natural dependency between the decisions, and it is the order we will follow.

Throughout, everything you do is accumulating in a single working draft. The draft is saved on the server as soon as you begin, which is why creating a new map is the first thing that happens; from then on your edits attach to a real draft record that already has an identity. Nothing about the draft is public. It is a private workbench that becomes a public artifact only at the very end, and only when you say so.

Stage one — choosing what the map contains

The first and most consequential decision is selection: which of the battlespace's contents belong in the public slice. This is where the snapshot principle earns its keep. Whatever you include here will be copied, by value, into the sealed public payload; whatever you leave out will simply not exist for your readers. Selection is therefore both an editorial choice — what is relevant to the story — and a safety choice — what is cleared to leave the building.

You are selecting across the three kinds of thing a battlespace map is made of. Events are the discrete, located observations — the strikes, sightings, incidents — that form the factual spine of the map. Actors are the parties to the situation and the territory associated with them. Layers are the thematic overlays and annotations that give the map context. You toggle each item in or out of the slice. A good selection is usually a tight one: a public map that tries to show everything shows nothing clearly, and every item you include is one more thing you are vouching for in public. Think of this stage as deciding what goes inside the frame, knowing that the frame is sealed the moment you publish.

Stage two — composing the camera and the reader's controls

Having decided what is in the map, you now decide how a reader first meets it, and what they are allowed to do with it once they are there. This stage covers two related things: the camera and the reader-facing tools.

The camera is the vantage point. A published map opens at a specific position — a centre, a zoom, an orientation — and that opening view does an enormous amount of editorial work, because it is the first thing every reader sees. You can compose it by hand, or, when you are authoring from inside the live workstation, you can simply position the real map the way you want it and capture the current viewport directly into the draft. Capturing from the live map is usually the fastest route to a considered opening shot: arrange the scene exactly as you would want a reader to find it, then take the camera as-is.

The tools govern how much agency the reader has. Here you decide questions like whether the map can be panned freely or should be held within bounds so a reader cannot wander off the part of the world that matters, and whether time is something the reader can move through. This last point — the timeline — deserves a moment, because it is one of the more expressive choices available to you. A spatial intelligence picture is very often a story over time, and the platform can present that time in different ways. It can reveal events cumulatively, so the map fills in as the reader advances and the accumulation itself tells the story. It can show a moving window, so only events near the current moment are visible and the reader watches activity sweep across the map. Or it can hold everything static, with no time control at all, when the moment is singular and time is not the point. Choosing the reveal behaviour is choosing how your reader experiences the chronology, and it pairs naturally with the narrative captions you are about to write.

Stage three — writing the narrative

A map without words is a reference object; a map with words is an argument. The third stage is where you write the captions — the narrative beats that carry a reader through the map and tell them what they are looking at and why it matters.

This is the stage that turns a published map from a frozen dataset into a piece of communication, and it is worth taking seriously. Each caption is a step in the story. Together they can form a guided sequence — the foundation of what readers experience as scrollytelling, where advancing through the narrative moves the map and reveals the picture beat by beat. You compose the captions in order, you can reorder them as the story finds its shape, and you can revise their text freely. The discipline here is the same one that governs all good writing: say what the evidence supports, in the order that makes it land, and no more. The platform treats your caption text as plain prose and presents it to readers exactly as written, so the clarity of the published narrative is entirely in your hands.

Stage four — title, summary, and the decision to go public

The final stage is metadata, and it carries the two pieces of text that represent your map before anyone opens it — the title and the summary — together with the single most consequential setting in the whole flow: visibility.

The title and summary are not incidental. They are what appears when your link is shared, when it surfaces in a preview card on a social platform or in a chat, when a reader is deciding whether to click. A precise, honest title and a summary that says what the map actually shows will do more for your map's reach and credibility than any amount of polish elsewhere. Write them for the person who has not yet opened the map.

Visibility is where the chapter on concepts becomes concrete. As you will recall, a new map is private by default, and the producer deliberately refuses to let you publish a private map. Until you make an explicit choice — Public for an openly discoverable artifact, Unlisted for one that is reachable by link but does not advertise itself — the Publish action stays disabled, and the interface tells you exactly why. This is not an obstacle to route around; it is the platform making sure that going public is always a conscious act and never an accident. When you select Public or Unlisted, the Publish action comes alive.

Previewing before you commit

Because publishing freezes an artifact and exposes it to the world, you will usually want to see precisely what you are about to seal before you seal it. The producer offers a preview for exactly this.

The preview is faithful in a specific and important way: rather than showing you an approximation, it runs the very same freeze process your publish would run — assembling the would-be public payload — and renders it through the very same viewer your readers will use, but without persisting anything or minting a token. What you see in the preview is, as closely as the platform can make it, what the public will see. It is the right moment to catch the things that are easy to miss while authoring: an event you meant to exclude, a camera that opens on the wrong place, a caption with a typo, a timeline behaving differently from how you imagined. Treat the preview as your last editorial read-through. Nothing about it is public, and you can toggle it on and off as you keep refining.

Publishing

When the preview reads the way you want and visibility is set, you publish. At that instant the platform performs the freeze in earnest: it copies your selected slice into a sealed payload, mints the opaque public token, and brings the artifact live at /p/{token}. The map you were authoring is now a public object, and the producer returns you to the list view, where your new map appears with its live status.

This is the hinge of the whole lifecycle. A second ago you had a private draft; now you have a citable, shareable artifact with a stable address. Everything from here is management and distribution.

Living with a published map

The list view you first skipped past is where the second half of the producer's job happens: looking after maps that already exist. Each map in the list wears a status that tells you its current state at a glance — a draft you have not yet published, a map that is published and live, or one you have unpublished and taken out of public view. Alongside the status sit the actions appropriate to that map's situation.

Edit reopens a map back into the authoring flow, loading its current selection so you can revise it. Editing does not disturb what is already live; it prepares changes that take effect only when you publish again.

Unpublish takes a live map out of public circulation. Its link goes dark immediately, returning the same uniform "not found" response that any unknown token would — so unpublishing not only hides the content but declines to confirm that the map ever existed. The map itself is not destroyed; it still lives in your list, and you can bring it back later. Unpublishing is the right move when a map needs to be corrected, retracted, or simply pulled while you reconsider it.

Republish is the mechanism behind the versioning we discussed earlier. It takes a fresh snapshot against today's data, seals it as a new version, and marks the previous version as superseded. Readers on the old link are told a newer version exists; readers on the canonical link get the current picture. Republishing is how a long-lived map stays honest as the situation it depicts moves on — you never edit a published claim in place, you supersede it and leave the trail intact.

Two further actions appear once a map is live, and each opens onto its own chapter. Embed produces the snippet that drops your map, interactive, into another website; the next chapter, The Public Viewer and Embedding, explains both the reader's experience and how embedding works. Stats opens a per-map readership panel; Understanding Your Readership explains what it measures and the privacy principles that shape it.

With that, the producer flow is complete in outline: you have seen how a living battlespace becomes an authored draft, how the draft is framed and narrated, how it is previewed and published into a frozen public artifact, and how that artifact is then managed across its life. The remaining chapters follow the map out into the world.

← Publishing & Sharing Open Krataxis ↗