Who and what may reach each part of this service, what is entrusted to the one supplier it has, and the rules covering the machine it is deployed from.
27001 A.5.1527001 A.5.1927001 A.5.2027001 A.5.2227001 A.5.2327001 A.6.727001 A.7.727001 A.7.927001 A.8.1Review. Reviewed when the number of people with access changes, when a second supplier is introduced, when the runtime pin is moved, and otherwise at least once every 90 days.
There are exactly two levels of access and no roles in between. Public: every evidence route, the API reference, the game itself and the report intake, all reachable with no credential by anyone, because a register nobody can read proves nothing to anybody. Operator: the control panel, the unredacted operational record, the full action log, the per-tank action stream and the replay route, all behind one credential.
The boundary is enforced from a single list. Every route that is credentialed or performs a control mutation appears in one place used by every gate, so a new control route cannot be added without also being gated — the failure mode where a new endpoint is protected by having been remembered is designed out rather than watched for.
Access is provable rather than asserted: the control panel answers unauthorised without a credential, and it does so on the public internet where anyone can check. The register's own link walk depends on that: operator rows must answer unauthorised, and a row that answered anything else would be a finding.
Nothing reaches the durable state except through the Worker. There is no direct client connection to storage, no console into it, and no query interface. Read access to what is inside is therefore exactly what the routes expose and nothing more.
Player identity is not an access level. The visitor identifier is a random value minted by the server, held in a cookie marked http-only, same-site strict and secure, and it authorises nothing: it names which profile a request is about. Holding someone else's identifier would let a person change that profile's display name, which is why the identifier is never published in any output and never accepted from a client in any form other than that cookie.
There is one supplier and the dependency on it is total: compute, durable storage, object storage, the domain and its TLS termination all come from the same infrastructure provider. This is recorded as an assessed risk with the residual accepted, rather than described as a partnership.
What is entrusted: all of it. Every byte this service holds — the receipt chain, the action log, the profiles, the spend history and the static assets — sits in the provider's storage, and the operations credential is held as a platform secret, which means the supplier holds the credential that guards the service against the supplier's other customers. There is no part of this system where the provider is not, in principle, able to see what it is running.
That is stated plainly rather than mitigated, because the mitigations available at this scale are not real. Client-side encryption of durable state would break the receipt chain's own verification. A second provider is not affordable under a five dollar ceiling. What is done instead is to hold nothing that would matter: no password, no payment detail, no email address, no account, and no personal data beyond a chosen display name and a pseudonymous identifier.
The requirements this service has of its provider are: that processing runs in physically secured facilities under an audited regime; that the platform's own storage is redundant; that TLS is terminated correctly and current; that platform secrets are not readable by other tenants; and that changes to the runtime do not silently alter behaviour.
How they are met, and how far that can be verified. The first four are addressed by the provider's published certifications, which is what the supplier-marked rows on the conformance register record. Those rows carry a standing condition and it is not yet discharged: a supplier marking means nothing until a copy of the certificate is actually held. The register says so on every one of those rows and this document does not paper over it.
The fifth is met by pinning: the runtime compatibility date is fixed in version-controlled configuration, so a platform change does not reach this service until the pin is deliberately moved. That is the one supplier control this service enforces itself rather than inherits.
These requirements are not negotiated. This is a free personal project with no contract and no commercial relationship, and the provider's standard terms are accepted as offered. Recording that as an accepted position is honest; recording it as an agreement reached would not be, and the supplier agreement row on the register stays short of met for that reason.
What is monitored continuously, and published: consumption per bound service against the free allowance and the hard limit, availability measured from project start, and the incident record where a provider-side outage would appear as unscheduled downtime. Provider-side failure is visible in this service's own evidence rather than taken from a status page.
What is reviewed on a cycle: the runtime pin, at each ninety-day review, together with the provider's published changes since the last one. Moving the pin is a change entry like any other, classified before it is built.
What has not happened yet, stated rather than implied: no such review cycle has yet completed, because this is the deployment that defines it. The supplier review row on the register is partial for that reason, and it becomes met on the first review that produces a record.
An exit strategy is required by the cloud services control and the honest one here is short. The game engine, the routes and the pages are portable TypeScript with no provider-specific dependency; they would move. The static assets in object storage are ordinary files and would copy. The domain would re-point.
The durable state is held in a provider-specific storage class with a provider-specific consistency model, so it does not move as it stands. Migrating it means exporting it, and as of this version that export exists: one self-describing document covering the object's keys and both tables beneath them, digested over its contents, written daily and proven to restore. It is plain JSON in a format documented in DOC-21, so reloading it elsewhere is ordinary work rather than a capability that would have to be invented under pressure.
That connection is the point of writing this section down, and it is worth stating what changed. This section previously recorded that no export existed, which made the exit strategy a plan to abandon the receipt chain, the action log, the profiles and the spend history at exactly the moment someone would most want to read them. One piece of engineering closed both that and the backup risk, which is why they were always the same item. What remains provider-specific is the runtime and the storage class, not the evidence.
All work is remote and there are no premises. One machine is used to develop and deploy, and it is the only endpoint in existence. The scope statement places it outside the boundary of this management system, but it holds the ability to change the service, so rules are stated rather than the matter being left at an exclusion.
The rules. The machine is not shared, and no other person uses the account that holds the deployment tools. The screen is locked when it is left. Credentials are never written into tracked files: the account identifier lives in an untracked environment file, the operations secrets are platform secrets and exist on the machine only for local development in a separate untracked file, and both filenames are excluded from version control so that committing them is an error rather than an oversight. Work is not done on a machine other than this one, and deployment is not performed over a network the operator does not control.
What can be evidenced, and what cannot. This document can be checked against the repository for the parts that live there — the ignore rules, the absence of the account identifier from the tracked configuration, the deploy script's refusal to run without credentials supplied from outside it. The rest is the operator's attestation about a machine, and no route this service serves could demonstrate it. The endpoint rows on the conformance register are therefore recorded as partial: the rules exist, and their observance is attested rather than proved.
The compensating position is that endpoint compromise is detectable rather than preventable. Every production change appears in the public change record with an identifier, every control action writes a receipt into the anchored chain, and the operations credential is a platform secret rather than a file the machine holds in a usable form for production. An attacker with the machine could do damage; they could not do it quietly.
There is no desk to clear, no paper, no printer, no removable media and no office. The clear desk half of the control has nothing to attach to and is recorded as inapplicable rather than answered with a rule nobody would follow.
The clear screen half does apply, and the rule is the ordinary one: the screen is locked when the machine is left, and the control panel is not left open on an unattended display. The control panel holds no credential in its own markup and re-authorisation is a browser credential prompt, so an open tab is an exposure of what is displayed rather than of the credential itself — which is worth knowing but is not a reason to leave it open.