️🕵️FGA 00: The Game Starts Here🐶

---

Part I — The Case

A Straightforward Little Game

The rain had been falling over the city for three days.

It ran down the windows of my office, gathered beneath the fire escape and turned the neon sign across the street into a red smear that looked suspiciously like a failed integration test.

On my desk lay a folder.

The label read:

FRAUD GRAPH ARENA

Inside, I found synthetic companies, duplicate identities, suspicious transactions, offshore structures, false invoices, shared addresses, misleading relationships and enough architecture documents to stun a medium-sized compliance department.

The usual crowd.

My name is Hercule.

Hercule Perrot.

Private investigator, Spanish Water Dog and reluctant specialist in software projects introduced with the sentence:

“It should be quite straightforward.”

They never are.

The client wanted a noir detective game in which the player follows evidence through records, documents, transactions and graphs, reveals hidden relationships, spends a limited investigation budget and eventually decides who did what.

There would be shell companies.

There would be false identities.

There would be graphs.

There would be jazz.

There would be dogs wearing coats and staring at evidence boards as though somebody had just normalised the wrong address field.

At first glance, it sounded like a small data application with better lighting.

That was the first clue that the case was going to be difficult.

The Game Behind the Graph

Fraud Graph Arena grew from an earlier data-forensics experiment involving Databricks, Zinggand GraphFrames.

That experiment asked a useful question:

Can entity resolution and graph analysis reveal relationships that are difficult to discover in isolated records?

The game asks a harder one:

Can a player investigate those relationships, understand what they mean and construct a defensible explanation of a fraud scheme?

The move from analysing data to making the player reason about data changes the entire project.

A data experiment can show that two customer records have similar names, addresses and telephone numbers.

A game must force the player to decide whether those records belong to the same dog, two members of the same household, a shared office, an identity thief or one unfortunate accountant whose phone number appears on every company-registration form in town.

A graph can show that one node has more connections than any other.

A game must allow for the possibility that the node is not the criminal mastermind but the bank, the payroll processor, the registered agent or the only employee who still answers emails.

A dashboard can display a suspicious transfer.

A game must ask whether that transfer is suspicious because of its amount, timing, direction, relationship to earlier events or simply because somebody drew it in red.

Fraud Graph Arena is therefore not a graph viewer with a trench coat.

It is an investigation game about reasoning under uncertainty.

A Relationship is not a Verdict

The central law of Fraud Graph Arena is simple:

A relationship is not a verdict.

A shared telephone number might indicate common control.

It might also indicate a family plan.

A shared address might identify a shell structure.

It might also identify an apartment building.

A circular payment pattern may indicate laundering.

It may also indicate refunds, internal transfers or the kind of accounting process that only makes sense to someone named Martin in Finance.

A highly connected actor might be the organiser.

They might also be a bank manager, legal adviser, victim or shared-service provider.

The game must preserve distinctions that suspicious-network diagrams are often eager to collapse.

A record is not necessarily an entity.

A candidate identity is not a confirmed identity.

An association is not control.

Control is not culpability.

Culpability is not the same as harm.

A victim can be connected to everyone.

A fraudster can appear only twice.

The graph is not a machine that converts connectivity into guilt.

It is evidence terrain.

The player must navigate it.

What the Player Actually does

The player enters the game as a Spanish Water Dog detective beginning or continuing a career.

Each case presents a fictional fraud inspired by documented mechanisms but built entirely from synthetic people, organisations, communications, documents and transactions.

The player receives an initial briefing and a limited body of revealed evidence. They inspect records, read documents, sort and filter information, move between list and graph views and begin forming theories.

Some actions are free. Thinking remains free for now, although several consulting firms are reportedly investigating alternative pricing arrangements.

Other actions consume investigation credits.

The player may reveal candidate identity relationships produced by entity-resolution logic. They may reveal exact shared-field relationships based on addresses, accounts, devices or telephone numbers. They may use bounded natural-language retrieval to locate relevant records. They may also create manual hypotheses when they suspect a relationship that has not yet been established.

These relationship families must never be confused.

A source relationship is recorded in the evidence.

A candidate identity relationship suggests that two records may represent the same underlying entity.

An exact shared-field relationship says only that two records share a normalised value.

A manual hypothesis belongs to the player.

None automatically means guilt.

As the investigation develops, the player builds a case file. They identify principals, operational roles, victims, facilitators and uncertain actors. They reconstruct chronology and financial flow. They connect claims to evidence and decide which analytical relationships matter.

Eventually, they submit the case.

Submission is immutable.

The evaluator calculates a deterministic score and selects one ending. A correct but incomplete investigation may close the case while leaving the kennel in ruins. A wildly overbroad accusation may send the detective chasing every squirrel in the district. A disciplined investigation can earn the coveted clean-collar ending.

The humour is noir.

The evidence discipline is serious.

---

Part II — Version Zero

Why the First Version Contains no Game

The first temptation was to begin with something visible.

A title screen.

A path-selection screen.

A case catalogue.

An empty investigation board carrying a tasteful note that read:

Graph goes here.

It would have looked like progress.

That was the problem.

A screen is easy to mistake for a system.

A button is easy to mistake for a capability.

An empty investigation board can create the reassuring illusion that the difficult part has been solved, when all we have really done is reserve a large rectangle for future trouble.

Fraud Graph Arena is supposed to teach disciplined investigation.

It would have been awkward to build it through superficial engineering.

So Version Zero does not begin with the player interface.

It begins by securing the project itself.

Before Hercule searches a crime scene, he records its boundaries, photographs the evidence and makes sure nobody walks through the interesting stains while carrying coffee.

Version Zero does the same thing to the repository.

It establishes what the game is, which rules are authoritative, how the system will be divided, what each component may know and how future work will prove that it is complete.

The result is not playable.

It is buildable.

That distinction matters.

The Source of Truth

Fraud Graph Arena has a substantial specification set.

There is a complete functional specification, a complete technical architecture and design specification, a modular architecture pack, high-level interaction documents, module-level specifications, test specifications and an end-to-end construction plan.

The problem is not the volume.

The problem is authority.

Suppose one document describes a single application image.

Another says the evaluator must have a separate identity.

A third describes a public web process.

A fourth introduces a maintenance executor.

A fifth still contains inherited language from an older architecture.

Which sentence wins?

Without an explicit answer, implementation becomes a séance. Developers summon whichever paragraph best supports the code they already wanted to write.

Version Zero identifies the current authority.

The primary pair is:

Fraud_Graph_Arena_Complete_Functional_Specification_v10.0.md  
  
Fraud_Graph_Arena_Complete_Technical_Architecture_and_Design_Specification_v10.0.md

The functional document defines what the game promises to the player.

The technical document defines the architecture and constraints required to keep those promises.

The remaining documents decompose, clarify and schedule the work, but they cannot quietly overrule the current pair because somebody discovered an attractive sentence in version seven containing the word optional.

The project now knows which witness is under oath.

Why the Architecture is Modular

The simplest possible architecture would be one enormous object called GameEngine.

It would control navigation, load cases, reveal evidence, deduct credits, save progress, play music, authenticate users, calculate scores and perhaps make coffee when the dependency graph became tense.

The name would sound authoritative.

The code would not.

Large coordinating classes often begin as convenient meeting points and end as crime scenes containing seventeen thousand lines of code and a comment near the top reading:

# Do not change the order of these calls.

Fraud Graph Arena needs stronger separation because different parts of the game have different responsibilities and different levels of authority.

The radio must not spend credits.

The graph renderer must not decide which evidence exists.

The provider must not decide guilt.

The browser must not contain the answer key.

The evaluator must not rewrite the player’s submission.

The save system must not restore spent credits.

These are not stylistic preferences.

They are game rules.

The architecture therefore uses a modular monolith: one coherent application made of clearly separated modules with explicit public contracts.

The word monolith means we are not beginning by scattering the game across dozens of network services.

The word modular means that living in the same repository does not give one component permission to rummage through another component’s private drawers.

The modules share a building.

They do not share toothbrushes.

One Application, Four Kinds of Authority

The deployed system is built from one signed application image, but that image may run under four distinct roles:

WEB  
MAINTENANCE  
EVALUATOR  
MIGRATE

The public web role serves the player.

The maintenance role advances durable workflows and reconciles external operations.

The evaluator role accesses protected case truth through a narrow private boundary.

The migration role changes the database during controlled releases.

The image may be the same.

The authority is not.

The web process cannot decide that, since it already has the player database open, it may as well take a quick look at the answer key.

The evaluator cannot expose protected truth because the interface team would like a more dramatic tooltip.

The migration role cannot remain permanently available in production because granting broad database privileges “just in case” is how a routine deployment becomes an archaeological dig.

No respectable detective leaves every key under the reception desk.

---

Part III — The City of Twenty Rooms

The architecture contains twenty logical components.

Twenty sounds excessive until the alternative is examined closely.

Without clear boundaries, navigation starts loading audio. Audio begins owning preferences. Preferences begin storing player state. Player state begins mutating the round. The round starts calculating credits. The credit service starts querying external providers. The provider returns a field called probably_guilty, and before anyone can stop it, the leaderboard has convicted an accountant in three jurisdictions.

The components exist to prevent this kind of architectural enthusiasm.

To understand them, imagine the system as a rain-darkened city divided into five districts.

District One — The Front Office

This is the visible part of the agency: the entrance, lighting, signs, evidence cabinets and radio murmuring beneath the rain.

The application shell and navigation

The application shell controls where the player is and which transitions are permitted.

That sounds simple until the game contains authentication, dashboards, career selection, catalogues, opening comics, investigations, submission review, verdicts, debriefs, leaderboards and recovery states.

Without a navigation component, every screen starts deciding where the player may go next. Soon the verdict page discovers it can reopen an active investigation, the login page accidentally resumes a case and the radio becomes the only object that understands the route history.

The shell provides the stable frame of the application.

It knows how to reach the investigation.

It does not decide which evidence is visible there.

That authority belongs elsewhere.

Presentation and accessibility

The presentation component controls how the game communicates visually and interactively.

Fraud Graph Arena is noir, but noir is not permission to place dark-grey text on slightly darker-grey paper and call the result atmospheric.

This component owns visual patterns, focus management, keyboard behaviour, screen-reader announcements, reduced motion, high contrast and accessible alternatives to graph interaction.

Presentation remains a projection of game state, not a source of game state.

A relationship may appear as a purple dotted edge.

The colour and line style explain its family.

They do not create it.

The component also ensures that every graph-critical task has a semantic list or equivalent path. A player should not receive a weaker investigation because they use a keyboard, screen reader, high zoom or reduced motion.

Accessibility settings cannot affect evidence, score, progression or rank.

The detective may turn off the animation.

The fraud does not become more innocent.

Localisation and messaging

The messaging component owns the application’s words.

Buttons, warnings, statuses and errors come from controlled catalogues rather than being scattered through implementation code.

This makes future translation possible, but its immediate purpose is consistency.

A pending command should not be called processing in one place, running in another and probably fine in an error dialog written at two in the morning.

The component also separates player-safe messages from internal diagnostics.

The player should receive a clear explanation and a correlation reference, not a guided tour of table names, stack traces and provider payloads.

Noir narration may be colourful.

Security errors should remain discreet.

Assets and resources

The resource component loads and verifies character art, case images, comics, icons, documents, transcripts and other packaged material.

Assets are registered through manifests containing identity, purpose, version and integrity information.

This matters because assets can contain accidental spoilers.

A closure comic must not appear during the opening.

A filename must not reveal that an apparently innocent actor is the mastermind.

An exported image must not contain the answer in a forgotten design layer.

The component also defines fallbacks. Decorative rain may fail without blocking play. Essential evidence cannot simply disappear and leave the player wondering whether the empty rectangle is a clue.

The resource manager knows what exists and whether it is safe to display.

It does not decide whether the player has earned the right to see it.

Audio and radio

The audio component owns the persistent noir radio.

Its responsibility is deliberately narrow.

It plays approved local music, keeps playback stable across routes, remembers whether the player turned it off and prevents several browser tabs from broadcasting different jazz tracks at once.

It does not provide clues.

It does not affect timing.

It does not influence scoring.

It is not required for navigation.

The radio exists to create atmosphere, not to become an inaccessible hidden puzzle.

If the saxophone stops, the case remains open.

District Two — Identity and Continuity

This district knows who the player is, which career they are following, which case they entered and what survives when the browser behaves like an unreliable witness.

Client-state synchronisation

Browsers refresh, crash, go offline and retain stale tabs for hours before confidently submitting old information.

The synchronisation component manages the boundary between temporary browser state and authoritative server state.

It coordinates selections, filters, layouts and editable drafts while respecting that credits, revealed evidence, commands and submissions belong to the backend.

The browser may remember which panel Hercule left open.

It may not remember that he still has twelve credits when the ledger says he spent them.

Identity and account security

The identity component manages accounts, sessions and recovery.

The game uses application-owned usernames and passwords without requiring email addresses. Recovery uses player-held one-time codes and protected operator procedures.

Every career, round, save, submission and private case file belongs to an account.

Guessing an identifier must never reveal another player’s objects.

Identity is also separated from public leaderboard aliases. The world may know that Detective Barktholomew scored 927 points.

It does not need to know which account owns the trench coat.

Careers, catalogue and progression

The career component controls the anthology and the player’s route through it.

Fraud Graph Arena contains three ranked entry tiers — Puppy, Adult Dog and Senior Dog — plus Detective Academy.

A career has a fixed starting point and a controlled sequence of cases. Completing one case may unlock the next, but only through a defined progression transition.

The catalogue decides whether a case is open, closed or locked and explains why it may be unavailable.

The case package describes what happens inside a mystery.

The career system decides when the player may enter it.

Without that separation, every case would implement its own unlocking logic, the Senior path would eventually reopen Puppy cases and somebody would solve progression by sorting case identifiers alphabetically.

The anthology deserves better.

Round and game state

A round represents one investigation attempt.

It binds the player, case version, evidence profile, rules, economy, analytical publications, provider mode and scoring version.

Those bindings cannot change halfway through play.

If provider behaviour changes tomorrow, an existing ranked round does not inherit it silently.

If scoring improves next month, yesterday’s result does not wake up with a different total.

A case is content.

A round is an event.

The case The Great Biscuit Relief Fund may exist once as a published package.

Thousands of players may create thousands of separate rounds against it.

The case is the script.

The round is tonight’s performance.

Case content and rules

The case-content component loads the mysteries themselves.

Each case is a versioned package containing records, documents, starting evidence, analytical relationships, investigation profiles, costs, narrative material, scoring configuration, endings and protected truth.

This component allows the anthology to grow without cloning the application.

The Ponzi kennel, invoice-diversion case, procurement scandal and offshore mystery all contain different evidence.

They should not contain private copies of authentication, saving, credits or evaluation.

A new case adds content and rules through stable contracts.

It does not fork the game engine and begin a rival government.

District Three — The Investigation Floor

This is where the player sees evidence, asks questions, spends credits and decides whether a suspicious relationship is meaningful or merely standing under bad lighting.

Investigation visibility

Visibility decides what the player is permitted to see.

This is authoritative game state, not a user-interface filter.

Some information is player-safe.

Some is provider-safe.

Some is authoring metadata.

Some is protected evaluator truth.

The browser must never receive protected truth.

The public application must not query it.

The external provider must not see it.

The visibility component tracks which records, documents and relationships have been revealed in a round and why.

A relationship may exist in the case package without being visible yet. A document may require a prerequisite. An analytical action may reveal a new connection only after its command settles.

Hiding the answer with CSS would not count.

Hercule has seen that trick before.

Workspace projection

The workspace transforms revealed state into the list, graph, document inspector, selection model and provenance panels.

The list and graph are two views of the same investigation.

Switching between them reveals nothing new and costs nothing.

A node selected in the graph corresponds to the same record selected in the list. A relationship visible in one has an equivalent semantic representation in the other.

The workspace decides how evidence is arranged.

It does not decide which evidence exists.

That separation allows the graph technology to evolve without rewriting game rules.

If a node falls off-screen, it is not legally erased.

Actions and commands

The actions component owns every investigative operation.

It validates the player’s request, decides whether it is allowed, creates the authoritative quote and tracks execution to a final result.

A player may click once, lose the response and click again. The system must return the original command rather than charge twice.

A provider may accept work and then become unavailable. The system must distinguish between never submitted, definitely submitted and uncertain.

Every paid operation is therefore a durable command with identity, status and settlement rules.

The browser’s opinion about what happened is not authoritative.

Browsers make poor witnesses under cross-examination.

Economy and credits

The economy component manages fictional investigation credits.

They are not real currency and they are not a disguised provider bill.

Their purpose is to make the player investigate deliberately rather than request every possible relationship.

Every paid action begins with a quote describing cost, limits and the possibility of receiving no result.

Accepted debits are stored in an append-only ledger.

Balances are derived from events rather than rewritten as unexplained numbers.

The economy ensures that balances cannot become negative, commands cannot debit twice and refunds cannot reproduce.

A player with no credits may still inspect evidence, edit the case file and submit.

The detective may be broke.

The investigation is not automatically over.

District Four — The Resolution Wing

Here the player preserves work, turns evidence into an argument, submits it and receives a verdict.

Save and recovery

Saving preserves player-authored work without becoming a time machine.

A ranked checkpoint may restore drafts, notes, filters, bookmarks and workspace layout.

It must not restore an earlier credit balance.

It must not unreveal evidence.

It must not erase command history.

It must not reopen a submitted case.

Player-authored drafts are reversible.

Economic and evidentiary history is not.

For a complete reset, the system creates a new unranked practice round rather than rewriting the original investigation.

Hercule may reopen his notebook.

He may not return the evidence to the envelope and demand a refund.

Case file and submission

The case file is where the player converts investigation into argument.

It is not one enormous text box labelled:

What happened?

The player identifies principals, roles, victims, facilitators, mechanisms, identity conclusions, financial flows, uncertainty and alternative explanations.

Claims are connected to evidence.

This structure matters because collecting the correct records does not guarantee the correct conclusion.

A player may reveal the right network and still accuse innocent employees. They may identify the principal but misunderstand the mechanism. They may treat a candidate match as confirmed identity.

Submission freezes the complete argument.

The evaluator receives what the player actually submitted, not what the browser wishes had been submitted after seeing the score.

Evaluation, scoring and endings

The evaluator accesses protected case truth through a narrow private boundary.

The public application does not.

The browser certainly does not.

It compares the immutable submission with versioned truth and rules, calculates an integer score, applies penalties, checks mandatory gates and selects one ending.

The same canonical submission under the same bound rules must produce the same result.

A generative model cannot become the official judge.

A new evaluator cannot silently rewrite history.

The verdict must also avoid revealing too much. It should explain weaknesses without becoming an oracle for protected truth.

If the player accuses the wrong dog, the game may say the accusation lacks evidence.

It should not answer:

Incorrect. The mastermind is behind the bakery at 14:30.

That would shorten the investigation.

It would also ruin the game.

Results and leaderboards

The results component publishes approved outcome information.

Leaderboard participation is optional and uses a public alias separate from the login identity.

Rankings are segmented by compatible case, rules, scoring and provider conditions. Players should not compete in the same table if their investigations used materially different evidence systems.

Reading speed, provider latency, accessibility settings and input method do not affect ranking.

A player may withdraw a public entry without deleting the private result.

The newspaper may print the score.

It does not receive the entire police file.

District Five — The Back Office

Behind the visible investigation, external providers, publication controls and durable workflows keep the city alive without gaining authority they do not deserve.

Retrieval provider gateway

The provider gateway hides external retrieval systems behind one stable game contract.

The implementation may use deterministic materialised retrieval, Databricks SQL or a qualified Genie-assisted process.

Those systems differ.

The player-facing investigation rule should not.

The gateway controls allowed data, bounded questions, result schemas, row limits, timeouts and failure handling.

It exists because providers change.

Prices change.

Limits change.

Maturity labels change.

APIs change.

Unexpected fields appear with the confidence of a man arriving late to a meeting and immediately proposing a reorganisation.

More importantly, the provider cannot become the authoritative selector of ranked evidence.

In competitive play, the final record set must remain reproducible from the case publication and deterministic rules.

A live provider may help interpret the question.

It does not decide which player sees which clue according to the mood of the model that afternoon.

The informant may suggest where to look.

The evidence room decides what is actually there.

Publication, workflow and runtime control

The final component governs case publication, durable background work and runtime roles.

Case packages, evaluator bundles and assets are validated before activation. New versions become active through controlled pointers instead of overwriting old files.

Long-running operations such as provider reconciliation, evaluation, export and deletion are persisted as workflows.

They do not depend on one browser request staying alive.

This component also enforces the separation between web, maintenance, evaluator and migration roles.

If the maintenance process becomes unhealthy, new paid work may need to pause.

If the evaluator cannot access its protected key, submissions remain pending rather than being scored by the web server as a convenience.

If a case package fails integrity checks, new rounds do not start against it.

The night shift keeps the city running while the detective is away.

It also ensures that nobody replaces the evidence before morning.

---

Part IV — How We Will Build It

Why Twenty Components are Easier than One

Twenty components do not mean twenty services, twenty deployment bills or twenty teams arguing over API gateways.

They mean twenty explicit responsibilities.

The economy can be tested without rendering the graph.

The evaluator can be tested without playing music.

The case loader can be tested without authenticating through a browser.

The radio can be tested without acquiring protected truth, which is a sentence I did not expect to write when the investigation began.

Each module must be independently testable through its public contract.

Then collaborating pairs are tested together.

Related modules are tested as capability groups.

Finally, the complete solution is qualified end to end.

This matters because two components may both be correct while disagreeing about the meaning of the same field.

The case file may call something victim.

The evaluator may expect harmed_party.

Both can be perfectly implemented.

Together, they produce a very confident zero.

Integration tests are where polite components reveal what they have been saying about each other behind closed doors.

Building in controlled iterations

The game will grow through controlled iterations.

Version Zero creates the constitution.

The next iteration creates the modular workspace, package boundaries, public contracts, test kits and runtime roots.

At that point, the twenty rooms will exist, but most will contain little more than interfaces, tools and the architectural equivalent of dust sheets.

Later iterations establish the shared contracts, presentation system, assets, audio, identity, client synchronisation and authenticated shell.

Only after those foundations are stable does the first signed case package enter the building.

The first playable route arrives later still.

This may appear slower than drawing a title screen immediately.

It is faster than rebuilding that title screen after discovering that navigation owns authentication, the catalogue owns progression and the graph renderer has somehow become responsible for deducting credits.

Each iteration must leave the project in a coherent state.

Not every state is playable.

Some prove architecture.

Some prove data contracts.

Some prove security.

Some prove one complete player journey.

The important rule is that each iteration adds a real, qualified capability rather than an attractive fragment surrounded by assumptions.

What Version Zero Proves

Version Zero proves that Fraud Graph Arena is not being built as a collection of disconnected ideas.

The product vision, game rules, architecture, module boundaries and delivery sequence now describe the same system.

The player-facing application will not become the authority for hidden truth.

Analytical relationships will not become automatic verdicts.

External providers will not define ranked evidence unpredictably.

Saving will not restore spent credits.

Accessibility will not become a competitive disadvantage.

New cases will not require cloning the game engine.

A release will not be considered complete merely because the main path happened to work once on one machine.

Version Zero also proves that the project’s own rules can be tested.

The repository verifies that its governing artifacts exist, that its responsibilities are traceable, that protected information has not leaked and that its qualification evidence is internally consistent.

The first qualification even uncovered a cross-platform text-handling defect.

That detail matters not because source-control trivia is exciting.

It is not.

It matters because the project caught a false assumption before gameplay depended on it.

The security tape around the crime scene worked.

What Version Zero does not Prove

There is no playable case yet.

There is no login screen, catalogue, graph workspace or radio playing in the corner.

Hercule cannot accuse anyone.

He cannot even open the office door.

That absence is deliberate.

Version Zero does not pretend that designs are implementations.

The functional specification describes the game.

The architecture explains how it will be built.

The construction plan defines the sequence.

Version Zero proves that those three things agree.

It does not award itself points for features that exist only on paper.

A detective who has drawn a map of the city has not solved the crime.

But at least he knows where the streets are.

---

Part V — The First Case

The Project Investigates itself

The first case in Fraud Graph Arena was not The Maddogg Investment Kennel.

It was the project itself.

The suspects included vague scope, duplicated responsibilities, stale specifications, giant components, provider dependence, hidden coupling and the persistent belief that a graph application is complete once the nodes begin moving.

The evidence suggested a familiar scheme.

If left unattended, the project would quickly produce a beautiful interface attached to an unstable centre, with game rules scattered through screens and architectural decisions made in whichever file happened to be open.

Version Zero interrupted the operation.

It identified the authorities.

It separated responsibilities.

It marked the protected areas.

It defined how each future capability would be tested.

It wrote down what done means before anybody had the opportunity to redefine it after a failed test.

The case remains open.

But the investigation is properly constituted.

The Game Starts here

Fraud Graph Arena is a game about disciplined reasoning under uncertainty.

It asks the player to explore data without treating every anomaly as guilt, to use analytical tools without surrendering judgement to them and to distinguish an impressive graph from a defensible case.

The architecture follows the same philosophy.

No component receives unlimited authority merely because it is powerful.

The graph does not own truth.

The provider does not own evidence.

The browser does not own state.

The evaluator does not own the player’s submission.

The radio does not own anything except the radio, and even that remains under review after midnight.

Version Zero gives every part of the future game a clear purpose and a clear boundary.

Twenty components.

One game.

No mystery about who is responsible for what.

The rain had stopped by morning.

On the desk, the folder was still thick, the architecture was still ambitious and the first playable case remained several iterations away.

But the crime scene was secure.

Hercule Perrot closed the notebook.

The next job was to build the rooms.

---

Next in the series

FGA 01 — Twenty Rooms and No Furniture

The next iteration creates the modular workspace.

The twenty components receive their first package boundaries, public contracts and independent test kits. The four runtime roots are established. Architectural tests prevent one module from importing another module’s private implementation or reaching directly into its data.

There will still be no fraudster to catch.

But there will finally be a building in which one can hide.

---

Hercule’s first case: twenty suspicious components, one missing game, and absolutely no evidence that the radio is innocent.