What this service has, who owns it, what each asset holds, how information is classified, and how that classification is enforced rather than labelled.
27001 Annex A.5.927001 Annex A.5.1227001 Annex A.5.1327001 Annex A.5.16Review. Reissued by any deployment that binds, removes or reclassifies an asset. Reviewed in full at least once every 90 days alongside the access review recorded in DOC-27.
The asset list is short enough to be exhaustive rather than representative, and that is the point of writing it down. Everything in scope is bound in one configuration file that the deployment reads; an asset that is not in that file is not reachable by the running service. The inventory below is that file, read out with owners and classifications attached.
Every asset has the same owner, because there is one person. DOC-03 records what that means and what it costs.
A-01, the Worker. One deployed script serving the game client and every route in the API reference, on one custom domain. Holds no state of its own. Classification: public — its source produces every public page, and the pages are the evidence.
A-02, the per-tank durable class. One instance per tank, holding live play state and a three-day deterministic log of seed and ordered actions. Contains display names, which are public by design. Classification: public.
A-03, the shared durable instance. One instance holding the control receipt chain, the ninety-day service action log, player profiles, spend history, the incident record and the maintenance state. This is the highest-value asset in the service, and the only one whose loss would destroy evidence rather than interrupt service. Classification: mixed — the receipt chain, incident record and action log are public; the profile rows and the unredacted operational record are operator-only.
A-04, the object storage bucket. Static game assets, and since this version the daily copies of A-03's state under a digest, thirty dated copies retained. Classification: operator-only for the state copies, public for the assets. The copies carry every profile row, so they inherit the strictest classification of anything inside them.
A-05, the domain and its DNS. Held in the provider account. Classification: public.
A-06, the source repositories — this service, and the game engine as a pinned submodule. Classification: public. Access to write to them is controlled by a hosting account outside the boundary, which is why the source-access row on the register is partial and not met.
A-07, the operator credential. One long-lived secret held as a platform secret, never in tracked configuration. Classification: secret. It is the only secret in the service and it is not held anywhere this service can show you.
A-08, this documentation and the register. Classification: public.
Three tiers, and the small number is deliberate. Public — served to anyone, unauthenticated, and intended to be. Operator-only — served only against the operations credential: the unredacted operational record, the profile rows, the state export and the deterministic replay. Secret — the operations credential itself, held as a platform secret and never served at all, by any route, to anyone.
There is no confidential-but-not-secret tier, because there is no third party to share anything with and inventing one would be labelling rather than classifying.
A label on a document is a request. This scheme is enforced by a single list in the Worker of every route that is credentialed or performs a control mutation, and that one list is consulted by every gate. A new operator route cannot be added without also being gated, because being gated is a property of the path rather than of having remembered.
That is why the operator routes added in this version — the state export, the copy trigger and the restore drill — were authenticated from the moment they existed, without anything being done to authenticate them. It is also the reason the classification is worth stating: the two-tier split was already true of the running service and enforced in code, and what was missing was expressing it as a scheme rather than leaving it as a behaviour.
Where classification and public output meet, the rule is applied at the boundary rather than at the source: the public status document is built by removing the operator-only fields from the same record the operator view reads, so a new field is public only if it is added to the public shape deliberately.
Assets are labelled where a label can be acted on, and not otherwise. Every route in the API reference states whether it is public or requires the operations credential, and the register's evidence links carry the same distinction in machine-readable form — which is how the link checker can assert that operator routes answer 401 and public routes answer 200.
Physical labelling, media marking and document classification banners have no application: there are no premises, no removable media, and every document in this set is public.
There is exactly one identity in the service: the operator, authenticated by one credential. There are no player accounts, no passwords and no registration. A player is given an opaque browser-held identifier that names a profile row and nothing else; it authenticates nobody, authorises nothing, and appears in no public output.
Adding any credential store would put the service outside the security policy as written and require that policy to be rewritten first. That is stated in DOC-02 and repeated here because it is the constraint that keeps this section short.