Requirements and specification
A tank holds a roster of thirty-two sharks. Eight of those seats are for human players; the remaining twenty-four are filled by computer-controlled sharks, and they are respawned to keep that number up so a player is never swimming in an empty arena. That is the whole requirement the system exists to meet.
The simulation runs at twenty ticks a second and the server is authoritative: the client draws what the server says, and no shark decision is taken in a browser. Each tank has a seed fixed for its lifetime, derived from the tank's own durable identifier.
Steering, in the order the rules are applied on each tick. If the shark is more than four fifths of the way from the centre to the arena wall, it heads back toward the centre and stops boosting — survival first. Otherwise it turns toward the nearest food inside its sight radius, twenty-two units normally and thirty-four while a feeding frenzy is running. Otherwise, during a frenzy, it heads for the chum in the middle. Otherwise, on every twentieth tick offset by a phase taken from its own identifier, it makes a random turn drawn from the tank's seeded generator. Separately, a shark within a short distance of high-value food charges for six ticks and then lunges, under a cooldown.
A feeding frenzy is a tank-wide event on a fixed cycle: every seventy-five seconds a chum drop lands in the centre and for the following twenty seconds every shark moves faster, dashes more often and sees further. It is driven by the tick counter, not by anything a player does.
Retirement. A computer-controlled shark that reaches a score of two hundred and forty is killed, bursting into food, and respawns after the normal one-second delay. This is a requirement rather than a side effect: without it a long-lived agent would accumulate an unreachable score and the leaderboard would stop meaning anything.
What the system is deliberately not given
Rockets are a player-only ability. This is enforced as an explicit rule in the action handler rather than left to be an accident of the steering function, so that a future change to steering cannot quietly arm twenty-four opponents.
A computer-controlled shark may take one bite per tick; a player may take two. The agents are therefore strictly less capable than the humans they play against, in both of the places where capability is bounded.
The steering rules are given no access to anything about a person. No display name, no profile, no best score, no history and no cookie identifier is in scope for them. This is the constraint that makes the fairness claim in the AI policy checkable rather than aspirational.
Design and development
Determinism is the design decision everything else rests on. The tank's random number generator is a mulberry32 step seeded by an FNV-1a hash of the seed string, and its state is carried inside the serialisable snapshot rather than held beside it. There is no wall-clock read and no unseeded randomness anywhere in the simulation. Two runs of the same seed with the same actions applied at the same ticks produce the same tank.
That choice has a consequence worth stating explicitly, because it is what makes the rest of this document verifiable: no shark decision is ever recorded. The tank log holds only the actions players sent. A reconstruction re-derives every agent from the seed. If anything outside the tank's own state had reached an agent's decision, replaying the seed and the player actions would not reproduce the tank.
Agent code follows the same recorded change process as every other component of the service: classified before it is built, carried by a change entry with an identifier, and released through the same gate. The change record is the development history, and every entry that altered agent behaviour states what it changed and why.
Responsible design and development criteria
Four criteria are applied to any change to this system, and each is a reason to refuse a change rather than a value to aspire to.
Replayability is not negotiable. A change that would make a tank unreconstructable from its seed and action stream is not shipped, whatever it improves, because replay is the only mechanism by which any claim in the AI policy can be checked instead of believed.
No personal data may enter the steering rules. A change that gives an agent access to a name, a profile or a history is out of scope for the AI policy as written and requires that policy to be rewritten first.
Agents may not be given a capability withheld from players. The direction is one-way: an agent may be less capable than a player, never more.
No learned model may be introduced silently. Introducing a model, training data, or a third-party inference call changes what this system is, and the AI policy and the affected register rows are rewritten in the same deployment that would introduce it.
Verification and validation
The acceptance criterion is exact and there is only one: a tank reconstructed at tick N from its seed and its ordered action stream must equal the tank the service reported at tick N. Not approximately — the reconstruction is derived by re-running the identical step function over the identical generator state.
The verification is performed by asking for it. The replay route rebuilds a named tank at a requested tick and returns the resulting state, so the check is a request rather than a stored test report, and anyone with the operator credential can run it now rather than reading a record of someone else having run it. That is a stronger artefact than a test log, because a test log can only tell you about the build it was written against.
The route refuses rather than guessing when it cannot honour the criterion. If the earliest retained action is no longer tick zero, the tank's complete history has aged out of its twenty-four hour window and the route answers with a gone status instead of returning a reconstruction it cannot vouch for. Above one hundred thousand ticks it refuses on cost grounds. Both refusals are the criterion working.
What is not done, stated plainly: there is no automated test suite in this repository and therefore no regression test asserting determinism on every build. Verification is performed on demand against a live tank, not continuously. That is a real weakness in the life cycle and it is recorded here rather than left for an assessor to discover.
Deployment
There is one deployment plan and the agents have no separate release. They are compiled into the same Worker as the rest of the service and ship as one atomic version: the engine, the routes, the pages and this document all move together or none of them do.
Before release the build must compile, the type check must pass clean, and the working tree must be free of whitespace damage. The production deploy refuses to run at all unless the account identifier is supplied from the untracked environment file, and refuses again unless both operations secrets are already configured — so a deployment cannot silently produce a service whose control panel has no credential.
After release the running version identifier is readable from the operator status route, which is how a deployed version is tied back to the change entry that produced it. Tank logs carry a generation marker; changing it resets the captures, so a behavioural change that would make older captures unreplayable does not leave a log that appears complete and is not.
Data quality
The inputs to this system are the tank's own simulation state — food positions, distance to the arena wall, the tick counter and whether a frenzy is running. There is no external dataset, so data quality here is not about completeness, labelling or bias in a corpus; it reduces entirely to whether the simulation is correct and reproducible.
The quality criteria are therefore the determinism criterion above, plus the bounds the simulation already enforces: food is capped so that corpse drops cannot accumulate without limit, spawn length is bounded, and the arena radius is fixed per tank. A state that violates those bounds is a simulation defect, and it would show up as a replay that does not reproduce.
Provenance is trivially answerable and worth answering anyway: every input is generated by this service, inside this tank, in the same request path. Nothing is acquired, purchased, scraped or received.
Use, and the limits on it
The permitted use is populating a tank with opponents. The system is confined to the simulation: it produces no text, no image, no score about a person, no recommendation and no output consumed by anything outside the tank it runs in.
Three limits are enforced in code rather than requested in prose: an agent cannot fire a rocket, an agent cannot out-eat a player per tick, and an agent cannot read anything about a player. A use beyond populating a tank — moderating, ranking, matchmaking, generating anything — is outside the AI policy and requires it to be rewritten before that use ships.
There is no separate operator procedure for the agents, because there is no lever to pull: they have no configuration, no runtime tuning surface and no controls in the operations panel. The only way agent behaviour changes is a deployment, which is recorded.
Reporting a concern about the agents
The security report intake is the channel for concerns about this system, and this section is the signposting that was previously missing. It is public, needs no account, accepts a report from anyone, and is throttled to one accepted report a minute.
A report about agent behaviour is handled the same way as any other: it is recorded as a retained event and written into the append-only receipt chain, and it does not by itself change service state. Where a concern is about how a shark behaves, the first response is a reconstruction — the tick in question is replayed and inspected — rather than an opinion about whether the described behaviour is possible.
A concern that the system is being described inaccurately is explicitly in scope for this channel. Misrepresentation is the one genuine risk the impact assessment identifies, and a reader who thinks this document overstates or understates what the sharks are is reporting exactly the thing most worth hearing.