States what this service is, what it runs on, who it affects, and where the boundary of the management system sits.
27001 Clause 4.127001 Clause 4.227001 Clause 4.342001 Clause 4.142001 Clause 4.242001 Clause 4.3Review. Reviewed when a change record entry alters the technical scope — a new binding, a new durable class, a new route class — and otherwise at least once every 90 days, the same window as the service action log.
Wizard Gang Shark Tank is a browser game. A player swims a shark in one of four tanks, eats to grow, and appears on a leaderboard. It is free, it requires no account, and it is offered with no availability commitment.
It is a personal project, not a commercial product. There is no customer, no contract, no revenue and no service level agreement. That shapes every judgement in this policy set: controls are chosen to be honest and verifiable rather than to satisfy an obligation nobody has undertaken.
One Cloudflare Worker serves the game client and every route in the API reference. Two Durable Object classes hold state: one per tank for live play, and one shared instance for profiles, spend history, the service action log and the control receipt chain. One R2 bucket holds static assets.
In scope: the Worker, both Durable Object classes, the R2 bucket, the routes listed in the API reference, and the source repositories that produce them.
Out of scope: the operator's personal device, the browser the player uses, and the underlying Cloudflare platform. The platform is addressed as a supplier rather than as something this management system controls.
The service runs under a hard spend limit of five US dollars. When measured consumption reaches it, the service stops rather than bills. That is the dominant constraint on the design, and it is why capacity is published at the cost and capacity meters rather than treated as confidential.
There is one operator. Availability, response to reports, and every review named here are bounded by one person's time. Where a clause assumes an organisation with separable roles, that is recorded as a limitation rather than papered over.
The service is deliberately transparent: the change record, incident record, logs, availability measurements and this policy set are public. The design assumption is that publishing the evidence is cheaper and more credible than asserting it.
Players need the game to work, their display name not to be abused to impersonate someone, and the small amount of data held about them to be limited and disclosed. They need no account and give no personal details.
The infrastructure provider needs the service to stay inside its acceptable use terms and its paid limits.
Anyone reporting a security problem needs a route that accepts the report and a record that it was received. That intake is public and unauthenticated.
No regulator, customer or contractual counterparty has expressed a requirement, because none exists. If that changes, this section changes first.