Operational planning, resources, communication and performance

The management system, and where it actually is

The management system is not a folder. It is this policy set, the conformance register, the change record, the incident record, the receipt chain and the logs — all of them routes on the running service, rendered from source that ships in the same artefact as the service itself.

That is the single design decision everything else follows from. A management system maintained separately from the thing it governs drifts from it, and the drift is invisible until an audit finds it. Here the two cannot drift between releases, because they are the same release.

Its processes and their interactions: risk assessment produces the treatment plan; the treatment plan produces changes; changes ship through the change process and land in the change record; operating them produces records; the records are what the register cites; and the register is re-checked whenever any of it moves. The loop closes at the management review.

Planning of changes

Changes to the management system are made in the same way as changes to the service, because they are the same kind of act: a change to tracked source, shipped by a deployment, recorded in the change record with a class and an identifier.

A change is planned by deciding three things before it ships: its purpose, which rows of the register it is expected to move, and how it will be verified afterwards. The verification is written into the change record entry as concrete evidence rather than as a claim of completion. Where a change would alter a control's status, the register moves in the same deployment, so there is no interval in which the published register describes a system that has already changed.

This version is a worked example: its purpose was to close partials, the rows it moved are listed in its change record entry, and its verification was the evidence-link walk and the restore drill, both of which are recorded and both of which found something.

Resources

Stated exactly, because understating resources is as misleading as overstating them. One person, part-time. One platform account under a five-dollar metered ceiling that the service enforces on itself. One domain. No budget beyond that ceiling, no staff, no external assessor engaged, and no tooling licence.

The AI system consumes no additional resource of consequence: the computer-controlled sharks are rules running inside the same Worker, with no model to host, no inference to buy and no third-party service to pay for.

The resources this system does not have determine several rows on the register directly, and the honest thing is to say so here rather than to leave the rows unexplained. There is no automated build, which is why dependency scanning does not exist. There is no second person, which is why internal audit and independent review cannot be discharged normally. Neither is a resourcing oversight; both are the stated consequence of a project of this size.

Communication

What is communicated: everything, by default, on a public route. The register, the policy set, the change record, the incident record, availability, spend, the logs and the API reference are all public and unauthenticated, and all are available as data as well as pages.

When: continuously rather than periodically, because the routes render live state. Incidents appear when they open, not when a report is compiled. The status page carries availability, the current spend position and, since this version, the state of the most recent copy and restore drill.

With whom, and how: players, through the game and the status page; anyone assessing this service, through the register and this policy set; security researchers, through the public intake at /docs/, which records a receipt and never changes service state; the platform provider, through its own support channels. There is no internal communication to define, and no confidential channel exists.

Who communicates: the Owner is the only role, and the only channel that accepts input from outside is the security report intake, which is rate-limited and cannot alter the service.

Operational planning and control

The processes needed to meet the requirements are the change process, the incident process, the risk process and the operating records in DOC-27, each with a defined trigger. They are controlled by being executed as code paths rather than as intentions: a control action cannot happen without writing a receipt, a route cannot be added under the operator prefix without being gated, and a deployment cannot ship without the gate that precedes it.

Outsourced processes: compute, durable storage, object storage and DNS, all from the platform provider, controlled as described in DOC-19 and marked supplier on the register.

Documented information confirming the processes were carried out as planned: the change record for changes, the receipt chain for control actions, the incident record for disruptions, DOC-27 for the recurring activities, and the state copies for the backup schedule.

Monitoring, measurement, analysis and evaluation of the AI system

This is answerable now in a way it was not before, because DOC-08 states AI objectives, and behaviour can only be measured against something.

What is measured, and by what method: that the computer-controlled sharks remain rule-driven and reconstructible, measured by the deterministic replay route — any statement about how a shark behaved at a given tick is checked against a reconstruction from the seed and the ordered action stream rather than taken on trust. That the roster size and capability limits are what the AI policy states, measured by reading them from the running configuration. That the AI system's description remains accurate, measured by the review recorded in DOC-27 against the source rather than against the previous description.

When, and by whom: on the triggers stated in the AI policy, and otherwise every ninety days, by the Owner. Results are evaluated at the management review in DOC-29.

The honest limit: these are verification measures, not outcome measures. There is no measurement of whether the sharks are fair, fun or well-tuned, because no objective of that kind has been set. Setting one and not measuring it would be worse than not setting it.

Continual improvement

Improvement here is neither a slogan nor a schedule. The mechanism is that the register carries its own shortfalls, in public, with a readiness figure that moves — and that a gap named on a public page is considerably harder to leave alone than one in a private plan.

The record of it is the change record, which is a continuous sequence of dated corrections and additions with the evidence for each. The direction is set by the register's open rows and the accepted residuals in the risk assessment, taken in order of what can honestly be closed rather than what would move the number most.

The evidence that this is real rather than asserted: the rows this version closed were closed by performing activities and building a backup, and the rows it did not close — dependency scanning, the erasure route, internal audit independence, the supplier certificates — are still named as open at the end of a pass whose stated purpose was to close things.