State of the Frontier is not just another page on EF-Map. It started from a simple product idea: EF-Map already had useful EVE Frontier data spread across tools, but it did not have a single weekly story that players could open, discuss, and share.
The report is the data-journalism layer on top of the map and indexer. It takes existing EF-Map infrastructure, packages the week into a fixed fact pack, writes bounded prose from those facts, verifies the draft, renders a static page, and only ships after human review. That is the important part. It is a workflow, not a magic AI system.
The useful bit was already there
Most of the hard pieces existed before the first report. EF-Map already had the map database, the Sui-era indexer, the Killboard, Activity Tracker data, structure/status snapshots, Smart Gate events, and name resolution for systems, players, and tribes.
That matters because State of the Frontier did not require inventing a new data platform from scratch. The new work was packaging and workflow. The report asks a different question from the main app: not "what can I inspect right now?" but "what happened in the Frontier this week, and how can someone else read it quickly?"
The existing inputs
- Killboard records for recorded kills, systems, players, tribes, and week-over-week movement.
- Activity Tracker records for approved player-triggered on-chain events.
- Structure and status data for infrastructure counts and changes.
- Smart Gate create, link, unlink, and current-link context.
- EF-Map's map and intelligence context for system, region, player, and tribe links.
From dashboard data to field report
Dashboards are useful when you are already inside the app. Reports are useful when you want to tell someone what happened. That is the gap State of the Frontier fills.
A player may be perfectly happy using the in-game map most days. They may not need EF-Map open every session. But a weekly field report is still worth opening because it summarizes conflict, infrastructure, Smart Gate activity, and recorded player-triggered activity in a format that works in Discord, Reddit, or a tribe channel.
That makes the report a shareable artifact instead of another panel. It gives current players a common reference point, and it gives prospective players a visible sign that the universe has measurable activity.
The Saturday workflow
The intended workflow is weekly and repeatable. State of the Frontier uses fixed Saturday 00:00 UTC to Saturday 00:00 UTC windows, so the numbers are not a rolling "last seven days" snapshot that changes under your feet. If the report is published later, it still covers the latest completed Saturday-to-Saturday window.
Each run starts from the repo-agent workflow. Scripts gather the data, build the fact pack, compare the current week with the previous week, and produce a prompt or draft path. The draft is strict JSON, not hand-written HTML. The verifier checks that the draft only uses approved facts and caveats. The renderer owns the final HTML, metadata, links, archive page, feed, and sitemap entries.
After rendering, the site is built and deployed to a Cloudflare Pages preview for human smoke testing. The reviewer checks the latest route, dated archive route, entity links, report card, copy summary, metrics, and metadata. Only after that review does the accepted output move through the normal commit, merge, and production deployment path.
| Stage | What happens | Why it matters |
|---|---|---|
| Fact pack | Scripts gather fixed-window data and previous-week comparisons. | The numbers come from deterministic data collection, not prose generation. |
| Draft JSON | The prose layer uses placeholders and approved claim IDs. | The draft can be checked against exact facts before anything is rendered. |
| Verification | Unsupported numbers, entities, raw HTML, unsafe links, and broad claims are rejected. | The workflow catches weak or invented claims before publication. |
| Render and preview | The renderer creates static pages, then a preview deploy is smoke tested. | Human review stays in the loop before production. |
Why the LLM is not trusted with the numbers
The safest part of the workflow is also the least flashy: the LLM does not compute trusted facts. It does not query Postgres, invent deltas, choose which tribe topped a table, or decide whether a claim is supported. The scripts do the data work. The fact pack says what can be said.
The LLM-assisted layer writes prose from those allowed facts. Dynamic values are represented as placeholders. Each paragraph, list item, table, callout, or link block carries claim IDs that point back to the fact pack. If the draft uses a number or entity that is not allowed, the verifier blocks it.
That is what makes the process repeatable. AI-assisted writing is useful here because it can turn a set of metrics into readable public language. It is not useful as an authority on what happened in the game. EF-Map keeps that boundary explicit.
Why this matters for the community
EVE Frontier players do not all need the same tool at the same moment. A route planner, a killboard, an Intelligence search panel, and a weekly field report solve different problems.
The field report is especially useful because it travels well. It is a link someone can drop into Discord with a compact preview. It is a readable summary that does not require opening every EF-Map panel first. It gives players something to react to, correct, compare, or cite when talking about the week.
It also makes the universe feel less opaque. EF-Map cannot capture every action and does not claim official truth, but it can show what its indexed data recorded and keep that visible over time.
Reusing the report inside EF-Map
The report is not isolated from the rest of the site. The rendered page links systems, players, and tribes back into EF-Map Intelligence where the fact pack can resolve them. Section actions open useful EF-Map contexts, such as conflict or Activity Tracker views. A copy-summary button gives players a plain text version of the key facts.
Recent polish also made the report easier to share. The page can generate a 1200x630 report card, the top metrics count up as the page loads, and the in-app Frontier Report button can show a small new-issue dot. Those are small details, but they make the weekly report feel like part of the map rather than a disconnected static page.
Why this creates longer-term memory
One weekly report is a snapshot. A year of weekly reports becomes a public archive. Over time, State of the Frontier can show how recorded kills, infrastructure, Smart Gate activity, and player-triggered activity changed from week to week.
That archive is valuable because live dashboards usually answer the current question. A report history answers a different one: what did the Frontier look like then? The more issues EF-Map preserves, the more useful that memory becomes.
Lessons from building it
The first lesson is that data products often start by reusing data you already collect. EF-Map did not need a separate reporting database to prove the idea. It needed a careful path from existing indexed data to a reviewed public artifact.
The second lesson is that a report can be more accessible than a dashboard. A dashboard is for exploration. A report is for orientation and sharing. Both matter, but they reach people in different moods.
The third lesson is that deterministic fact packs make AI-assisted writing safer. The prose can be flexible while the facts stay bounded. Verification, preview deploys, and manual smoke testing still matter, and they are part of the workflow by design.
Conclusion
State of the Frontier is a workflow, not a one-off page. It turns EF-Map's existing EVE Frontier data into something the community can read, share, and revisit.
That is the kind of layer that makes EF-Map more than a map. The map shows where things are. The weekly report helps explain what happened.