Based on your uploaded project inventory and its current gruvor architecture/state.

# gruvor: Useful Sidequests Before the Article Eats Your Brain

## Four Days Is Not Panic

Four days is a long time in journalism. It is not a long time if the plan is to rebuild the cathedral, train a model, create a perfect public data portal, and somehow also write the article. But four days is absolutely enough time to build sharp little tools that make the story clearer, give your brain a break, and maybe produce one or two usable graphics.


The gruvor project is already not a notebook. It is a research machine. It has permit data, company enrichment, people extraction, media indexing, manual drop-in handling, fact-pack verification, maps, dossiers, current views, and a local interface. That means the useful next tools are not about gathering everything. They are about seeing what is already there from different angles.

Timeline is the obvious first angle. But it is not the only one. The article is about dates, yes. It is also about uncertainty, jurisdiction, corporate identity, source strength, missing answers, local geography, and what can be proven without overreaching. Each of those can become a small tool. Some of them will help the article directly. Some will mostly give you an excuse to play with the machine for twenty minutes and come back to the draft with more oxygen in the brain. That is not procrastination if the tool sharpens the story.

The rule is simple: no giant detours. Every sidequest should either make the article safer, make a graphic possible, or reduce the mental drag of handling too many documents. If it does one of those, it is allowed. If it requires three days and a name ending in “studio,” shoot it behind the barn.

## The Evidence Board

The first tool beyond the timeline should be an evidence board. Not a fancy kanban. Not a project manager cosplaying as an investigation. A source-first board that answers one question: what do we actually have?


Imagine a local page where each source document appears as a card. Bolagsverket material. Bergsstaten PDFs. SGU application material. Annual reports. Allabolag drops. Australian filings. Web captures. Manual notes. Each card shows what it is, when it was added, what entities it mentions, what article gap it helps close, and whether it is safe to use.

This matters because an investigative article often gets messy near the end. You know something because you saw it, but later you cannot remember whether it came from a primary document, a scrape, a generated dossier, or a note from your own brain at two in the morning. The evidence board is there to prevent that.

The board should not let everything look equal. A primary authority document should feel different from an auto-generated dossier. A manual note should feel different from a verified fact-pack claim. A source with personal data should be visibly sensitive. A pending request should be marked as pending, not mixed in with proof.

This can be built with what you already have. The gruvor project already has media ingestion, manual drop-in intake, document indexing, dossiers, and article files. The board can be a derived view over those. A card is just a source record with a little metadata and links back to the local file or dossier path.

The useful filters are not many. Show me everything tied to Energy X92. Show me everything tied to a specific person. Show me everything tied to Bolagsverket. Show me everything that closes or touches gap G seven. Show me everything that is not yet connected to a claim. Show me the sources I have not looked at today.

For the article, this gives you a stronger final check. For your brain, it gives you the relief of seeing the pile as cards instead of fog.

## The Claim Checker View

The project already has a fact-pack verifier, which is excellent. But there is another visual tool hiding next to it: a claim checker view.


The idea is to turn article claims into visible objects. Not every sentence. Just the load-bearing claims. The company was late with this. The registered control information was stale. The sanction fee was this size. The application said this. The name was written this way. The company had this relationship. The authority said this. Bolagsverket has or has not commented yet.

Each claim gets a status. Confirmed. Confirmed but needs wording care. Awaiting comment. Needs re-check before print. Should not be used. Maybe true, but not worth the fight.

This is not about making the AI write the article. It is about preventing the article from inheriting the chaos of the investigation. You can have a claim page where every claim links to one or more sources, shows a short evidence note, and has a “use in article” flag. It becomes a bridge between the research stack and the actual draft.

This could be very simple. A markdown file with special markers could feed the view. Or the generator could read the existing fact-pack. The important part is that the view separates three things that often get blurred: the claim, the evidence, and the wording.

That distinction matters. The evidence might support “late filing and sanction fee.” It might not support “serious misconduct.” The evidence might support “registered verklig huvudman data appears outdated.” It might not support “they intentionally hid ownership.” The claim checker is where you keep yourself honest before the language gets sharper in the article.

The fun version of this tool is a “red pen mode.” It shows only claims with weak support, missing source links, stale dates, or unresolved gaps. That gives you a focused repair session instead of the classic late-stage journalist experience of staring at the whole draft with the energy of a damp sock.

## The Corporate Identity Resolver

The original document makes one problem very clear: the case crosses company names, jurisdictions, filings, and sometimes messy spelling. That is exactly where a small identity resolver helps.


This is not a full company intelligence platform. It is a page that says: here are the entities that may be the same, related, renamed, confused, or merely similar. Energy X92 AB. Neu Horizon Uranium. Earlier or later company names. Australian entities. Related parties. People in filings. Names that appear with slightly different spellings. Emails, addresses, organization numbers, OpenCorporates identifiers when available, and manual notes.

The key is to avoid false certainty. The resolver should not merge things just because they smell related. It should show proposed links with reasons. Same organization number. Same source document. Same name after rename. Same person appears in a filing. Same email. Same address. Mentioned together in a document. Manual note from Pär. Each reason has a source.

This tool is useful because identity mistakes are brutal in journalism. If two similarly named companies get blurred, the whole article weakens. If one person’s name is misspelled in source material, you need to know whether you are quoting the error, correcting it, or quietly avoiding it. If a foreign company has a local identifier and an international identifier, they should sit together without pretending every record is equally trustworthy.

Technically, this is a perfect little graph-adjacent tool. It can use the same entity and edge model as the relationship graph, but the interface is calmer. Instead of showing a spiderweb, it shows candidate matches and evidence rows. Very boring. Very useful. Very deadline-friendly.

The article benefit is obvious: cleaner naming. The sidequest benefit is better: you get to play detective in a small controlled room instead of wrestling the whole octopus.

## The Gap Radar

The project has named gaps. That is already good. But the next version should make gaps visible as a radar.


A gap is not just a todo. A gap has a kind, a deadline, a person responsible, an article risk, and a fallback wording. G four is not the same kind of gap as G seven. A BankID re-pull before print is different from an external comment expected from Bolagsverket. A paid ASIC re-pull is different from a mystery witness name. A non-blocking curiosity should not sit in the same emotional bucket as a claim that can break the article.

The gap radar should show four states. Blocking. Useful. Nice if possible. Parked. That is enough. Anything more becomes project management theater.

For each gap, the page should say what decision it affects. Not just “identify Andreas Persson.” More useful is “identify Andreas Persson because he appears as protocol witness; if unresolved, do not imply role beyond what the source says.” That turns the gap into a writing instruction.

The page should also include fallback lines. If Bolagsverket has not answered by deadline, what is the safe wording? If the VH re-pull is not done, what claim is removed or weakened? If the Australian EGM material is not pulled, what paragraph becomes background instead of evidence?

This tool directly protects the article. It also protects your mood. Open questions feel less poisonous when each has a fallback. A gap without a fallback is a small haunted room. A gap with a fallback is just work.

## The Source Strength Meter

A fun and useful experiment would be a source strength meter. Not a legal truth machine. More like a journalist’s visual conscience.


Each claim or event gets a source strength score based on boring criteria. Is it from a primary authority document? Is it from the company itself? Is it from a registry? Is it from an auto-generated summary? Is it from a scraped page? Is it from a manual note? Is it recent? Is it contradicted? Is it sensitive? Is it waiting for reply?

The score should not decide truth. It should flag attention. A claim backed by a primary document and a registry can be green. A claim backed only by a generated dossier is red. A claim backed by a company statement might be usable but should be treated as what the company says, not what is independently established.

This helps because graphics can accidentally launder weak evidence. Put a weak edge on a clean diagram and readers will feel it is solid. The source strength meter makes sure the visual layer carries the same caution as the reporting.

You could use very plain labels. Strong. Medium. Weak. Pending. Do not use. That is better than fake precision. A score of eighty-two percent sounds scientific and is probably nonsense. A label that says “primary source, but needs current re-check” is actually useful.

This could live inside the evidence board, the timeline, and the graph. Events with strong evidence get a full solid marker. Pending items get a hollow marker. Weak or manual items get a warning mark. The point is not decoration. The point is stopping your eye from treating every box the same.

## The Document Heatmap

A document heatmap would be a delightful small tool. It asks: which documents are doing the most work in this story?


You already have many documents and article files. Some sources are probably load-bearing. Others are supporting material. Others are background. A document heatmap shows which source files are cited by the most claims, events, edges, or gaps. It also shows which documents have not been connected to anything yet.

This is useful in two directions. If one document supports ten key claims, that document deserves another careful read. If a document was manually collected but supports nothing, maybe it is background, maybe it is irrelevant, or maybe you have not mined it yet. Either way, the heatmap helps.

The visual could be almost stupidly simple. Bigger card means more linked claims. Darker card means higher article relevance. A warning stripe means sensitive or unverified. A little clock means old or stale. Click the card and you see all events, people, companies, and claims connected to that document.

This is the sort of tool that feels like a break because it is visual and exploratory, but it still moves the article forward. It might reveal that one PDF is the backbone of the piece. It might reveal that the exciting Australian material is actually background unless the ASIC pull lands. It might reveal that a zinger sentence about misspelled names has source support but no real article function. Which is fine. Not every good detail deserves a paragraph.

## The Quote and Wording Locker

Another useful tool is a quote locker. This is especially good when you are waiting for comments or working with official language.


The locker holds exact quotes, paraphrases, and safe wording. It separates them. Exact quote means the words are copied from a document or reply. Paraphrase means your rewrite of what the source says. Safe wording means the sentence form that can go into the article without overstating.

That distinction is huge. Official documents have strange wording. Companies have self-serving wording. Registry statuses have legal meaning that should not be made more dramatic than they are. A quote locker lets you collect the exact language and then craft article-safe versions next to it.

For example, if a source says a company was fined, that is one thing. If the registry says a sanction fee was imposed because an annual report was late, that is more precise. If you write “failed to report” when the legal mechanism is actually “late annual report,” that may be emotionally satisfying but less safe. The locker gives you a place to tame those sentences before they enter the draft.

This can be markdown-backed. It does not need a database. The interface can show source text, proposed article wording, risk note, and status. Accepted. Needs legal care. Awaiting comment. Cut. The goal is to reduce the number of times your brain has to re-argue the same sentence.

## The Local Consequence Lens

The article is local. The data stack is large. Those are not the same thing.


A local consequence lens asks: what matters specifically to Årebladet readers? Where is it? Which village, lake, mountain, road, grazing area, protected area, or municipal boundary does it touch? What can a resident understand without caring about corporate law in Australia?

This could be a map-adjacent view that translates permit geometry into reader geography. Not just coordinates or permit IDs. It could show nearest known places, affected kommun, overlap with known areas, distance to recognizable landmarks, and maybe a small text description generated from spatial joins.

This is where gruvkartor dot se thinking becomes useful even before the larger map project is finished. The final article may not need a complex map. It may need one simple local answer: this is where the application sits in relation to places readers know. The tool helps you find that answer quickly.

If the Lantmäteriet parcel access is still pending, do not block on it. Use what is already live: SGU permit geometry, protected areas, reindeer areas, municipal boundaries, hydrology if available later, and your own cartographic judgment. Four days is plenty of time to make a useful local map, not enough time to wait for every dream layer.

The sidequest version is fun: click a permit, get a “reader translation” panel. Technical name, company, status, area, nearby local names, overlaps, source links, and a one-paragraph plain-language summary. That summary should be reviewed by you, not blindly published. But it gives the article writer a starting point that is much closer to newspaper language than raw GIS output.

## The Mini FollowTheMoney Export

The original project already has FollowTheMoney export in the command tree. That suggests a useful experiment: do a small case-specific export and inspect it with a graph mindset.


FollowTheMoney is good because it gives names to investigative objects: people, companies, ownership, documents, addresses, and relationships. But it can also be overkill if you try to model everything at once. The right article-week version is tiny. Export only the Energy X92 case neighborhood. Then inspect what the model thinks exists.

This is less about production and more about quality control. If the export makes obvious nonsense, your entity and edge model needs tightening. If the export cleanly shows companies, people, documents, and permits, you have a more portable representation of the case. Later, this could feed Aleph or another investigation tool. This week, it is mostly a structured sanity check and a toy worth playing with during a writing break.

The main warning is not to let FollowTheMoney become the boss. It is a schema, not an editor. If it helps you express relationships clearly, use it. If it forces awkward modeling during deadline week, park it. The article does not care whether your graph is philosophically pure. The article cares whether the facts are right.

## The Anomaly Finder

There is one more tool that sounds more magical than it should be: an anomaly finder. Keep it dumb.


Do not build an AI investigator that “finds suspicious patterns.” That way lies expensive nonsense. Build a rule-based weirdness page. Weird is not guilt. Weird is “look here.”

Possible flags are simple. Company has permits but missing or late financials. Verklig huvudman record may be stale. Owner name appears differently in different sources. Person appears in source material but lacks a confirmed identity. Company has foreign links but no resolved foreign registry record. Permit application mentions a person or entity not in the company table. Annual report data exists from one source but not another. A source document is tied to article relevance but has no extracted people or companies.

The value is not that every anomaly matters. The value is that the page gathers the oddities in one place. Some become paragraphs. Some become questions. Some become cut material. Some become future stories.

This is also a good ADHD-friendly tool because it gives you a controlled rabbit hole. You can open the anomaly finder, investigate one oddity, close it, and return to the draft with a small reward. The danger is letting it create twenty new gaps. To avoid that, every anomaly gets a decision: article relevant, background, future, ignore.

## The Draft Friction Finder

Here is a slightly different tool: a draft friction finder. It reads your draft and highlights where the article is asking the reader to swallow too much at once.


This is not about grammar. It is about cognitive load. The tool can flag sentences with too many entities. Paragraphs that mix timeline, ownership, geography, and legal process all at once. Claims without nearby source anchors. Names introduced before their relevance is clear. Acronyms used too early. Too many foreign company references in one stretch.

This can be AI-assisted without trusting the AI for facts. The model is not deciding what is true. It is acting as a bored but intelligent reader saying, “I got lost here,” “this name arrives too early,” “this paragraph may need a map,” or “this sentence contains three claims and should be split.”

That is especially useful for a mining and corporate story. You know too much. The reader knows almost nothing. The danger is not that the article lacks detail. The danger is that it introduces detail before the reader has a shelf to put it on.

The output should be comments, not rewrites. You do not need an AI to write the article. You need a friction detector to tell you where the reader might fall off the sled.

## The Graphic Candidate Picker

Before making graphics, build a graphic candidate picker. It sounds silly. It is not.


The tool looks at events, claims, maps, and relationships and asks: what could be visual here? A sequence becomes timeline candidate. A location becomes map candidate. A relationship cluster becomes diagram candidate. A repeated status becomes table candidate. A before-and-after becomes comparison candidate.

Each candidate gets a job. Explain local geography. Explain company sequence. Explain compliance thread. Explain who is who. Explain what is still unanswered. If a graphic does not have a job, it is decoration. Cut it.

For this article, I suspect the strongest candidates are a compliance timeline, a local permit map, and a small relationship diagram. But the picker might reveal something else. Maybe the strongest visual is actually a “what we know and what remains unanswered” box. Maybe it is a document trail. Maybe it is a map plus a single sentence. The tool gives you permission to choose based on story function, not on which visualization looks coolest.

This is also a good break task. It is visual, editorial, and contained. You can spend twenty minutes generating candidates and come back to the draft with a clearer sense of what the article does not need to explain in prose.

## The Safe Tool Stack

The safe stack is boring, which is why it is good.


For timelines, use vis-timeline. For relationship exploration, use Cytoscape dot J S. For larger graph rendering later, consider Sigma dot J S with Graphology. For deterministic print diagrams, use Graphviz. For maps, keep using MapLibre internally and QGIS for polished print output when needed. For exports, use Playwright screenshots first, then SVG only where print quality demands it.

For text and source views, stay inside FastAPI, Jinja, and HTMX. No new frontend build system. No React unless a future version truly needs it. This is article week. The best tool is the one Claude can add without dragging a caravan of dependencies behind it.

For data, keep the derived visualization layer separate from the source parquet tables. Generate JSON or small derived tables under a case folder. The source of truth remains the existing data spine. The visual layer is a lens, not a replacement.

For AI, use it where it is strong and low-risk. Let it summarize source cards for internal use. Let it suggest draft friction points. Let it propose graphic candidates. Let it cluster documents by topic. Do not let it invent relationships. Do not let it decide legal meaning. Do not let it turn weak evidence into confident prose.

## The Best Break Projects

If the purpose is partly to get energy back, choose sidequests with different textures.

The evidence board is good when your brain is tired of prose but can still sort objects. The relationship graph is good when you need the reward of seeing structure. The local consequence lens is good when you need to reconnect the corporate material to Årebladet readers. The claim checker is good when anxiety is high and you need the piece to feel safer. The anomaly finder is good when you want a controlled rabbit hole. The draft friction finder is good when you are too close to the text.


Do not choose the sidequest based only on what is most useful. Choose it based on what kind of tired you are. If you are word-tired, do a visual task. If you are source-tired, do a map task. If you are uncertainty-tired, do a gap radar task. If you are bored, make the graph. If you are anxious, make the claim checker.

That is not soft advice. That is production advice. The point is to keep the whole system moving without pretending that staring harder at the draft is always the best use of the next hour.

## The Order I Would Try

If I were choosing the next experiments, I would do them in this order.

First, build the evidence board. It gives immediate clarity and uses data the project already has. Second, build the gap radar, because the article has known open gaps and deadline decisions. Third, build the claim checker, because it protects the draft. Fourth, build the relationship graph, because it is useful and fun but should not lead the reporting. Fifth, build the local consequence lens, because it may produce the strongest public graphic. Sixth, build the draft friction finder, because that becomes more useful once the draft has weight.

But the order can change based on energy. If the writing is stuck, the graph may be the right break even if it is not the most urgent tool. If the article feels legally sharp, the claim checker jumps to the front. If the story feels too abstract, the map lens jumps to the front. Four days is enough time to make two or three small things, not ten perfect things.


The winning move is to keep every tool small, generated, and source-linked. If a tool cannot be built as a small lens over existing material, it is too big for this week.

## The Real Goal

The real goal is not to visualize the project. The real goal is to keep the article honest while giving your brain different ways to touch the same material.

A timeline helps with sequence. An evidence board helps with proof. A claim checker helps with wording. A gap radar helps with deadline choices. A relationship graph helps with structure. A map helps with local meaning. A source strength meter helps with caution. An anomaly finder helps with leads and zingers. A draft friction finder helps the reader survive.

None of these tools needs to be grand. In fact, they should not be grand. They should be small enough to build, use, and throw away if they do not help. The gruvor stack is already the grown-up thing. These are lenses you clip onto it.


And that is the right energy for article week. Not panic. Not polish theater. Not a perfect dashboard. Just enough little machines to make the story visible from different angles, then back to the draft with fewer ghosts in the room.