Source: management_api_contract.md
Generated automatically from the published contract sources.
Source path: management_api_contract.md.
Contract text
The Management API — Resource Contract
Purpose
This file is the resource contract for the one management API the management API PRD describes: the resources the plane exposes, the actions over them, how the contract is versioned, and how a credential binds to it. It settles the first point of that PRD's open questions together with MCP-02's authentication binding. It is the layer the MCP surface derives from: the tools of mcp_surface.md are these actions, surfaced (MCP-03). A test in the platform's suite holds the two enumerations to each other — an automated check of API-L0-01's requirement that each client expose only capabilities of the management API.
The launch enumeration has one home: schemas/management_api.json beside this document — the resources, and action by action the resource it operates on, its authority tier, and which clients may call it. This document states the rules the enumeration obeys and repeats none of its rows.
What this document does not cover: the per-action payload schemas, which land with each action's implementation (raised below; the route rule, methods, and error shape are MAPI-10's); the served three-form derivation of API-L0-09, served_context.md's; and the pending action's own mechanics, which stay API-L0-07's.
Requirements are numbered MAPI-nn.
The contract
MAPI-01 (decided): The management API is one versioned HTTP contract of resources and actions: every capability is a read of a resource or an action upon one, and every resource and action is enumerated in schemas/management_api.json. A capability enters the plane by entering that enumeration. There is no unenumerated endpoint for a surface to lean on, which is what keeps every surface a client (API-L0-01).
MAPI-02 (decided): The contract carries its version — 1 at launch — stated in every exchange. Within a version, evolution is additive: new resources, new actions, new optional fields. Removing or renaming anything, or changing an action's tier, is a new contract version, never a quiet edit — the callers are AI tools acting on served descriptions of this contract, and a description that drifts under a caller is a capability that lies.
Removing a request member within a version is a change a caller observes, since a call that names a member its action does not declare is refused (MAPI-22). So a removal is admitted only as a use of the shape clause below while that clause runs, and is a new contract version after. One removal was made before that rule stood, when a caller that sent the member observed no difference in the call's answer. It took the optional request_id member, which no implementation ever read, from twelve reversible request schemas in schemas/action_payloads.json, named in MAPI-04. The HTTP route holds a call's member names to the request schema and validates no member's value.
Until the platform holds one hundred builder accounts that each hold a live application, and no later than the end of the beta, a member's shape may change within version 1 in the interest of a cleaner contract. A synthetic account (ACB-L0-79) is not a builder account for this count. The shape may change without the owner's approval of each change, under the owner's standing ruling that no approval is owed while the platform holds fewer than one hundred such accounts. While the clause runs, an action whose rename the owner approved may be renamed within version 1, where over the actions route its old name answers unknown_action naming the successor, the tool surface following MCP-08's revision move.
The session records the account count at the change and records the change in this document — by the statement that owns the member, or by this statement where none does. The served schema's version member moves at the change's landing, so that a caller regenerates its view. The change is admitted because until then every caller of the contract is the platform's own or a tester's, changed with the member, and no served description drifts under a caller it was made for.
Every content change to a served schema file moves that file's version member. The served schema files are the files the index schemas/served_context.json names, itself among them, that carry a top-level version member, a date and a counter. A description's wording and an enumeration widened to values the service already answers are included, because the served descriptions are the contract an AI caller acts on, and one version string naming two contents is the drift this statement forbids.
No session writes the member: on a session branch the registrar refuses a revision that changes it. The served integrate writes the next value at the landing into each such file whose bytes differ from the trunk's. The next value is the trunk's value with its counter plus one, or the landing day's UTC date with the counter 1 where that day is later than the trunk value's date (kit:REG-15; kit:REG-88). So the rule is mechanical, no session judges which changes move it, and two branches that revise one file land as consecutive values. schemas/library_catalog.json, the catalog's shape and not its rows, carries no version member, lands byte for byte, and rides CTX-01's suite.
Because the value is written at the landing, a control-plane release never carries an unlanded change to a file that declares the member. The control plane's release script (PLD-L0-65) fetches the remote trunk and refuses a release whose HEAD holds such a file in bytes the remote trunk's first-parent history does not hold at that path, or whose working copy of such a file differs from HEAD's. The branch is integrated first, and the release then runs from the landed trunk commit.
The rule holds on every estate the register names (PLD-L0-85). A development-role estate is released to from the landed trunk as production is, so a promote of its build to production (PLD-L0-65) carries forms the trunk holds.
The fetch must succeed, except in a rollback. There, where the fetch fails, the script reads the remote-tracking ref the clone holds, admits the rollback only where every such file stands at that ref's tip or in its first-parent history, and says that the fetch failed and the held ref vouched. The exception stands because a ref the run could not refresh holds a past value of the remote trunk, which can only under-report what landed, and a rollback is the act an incident needs.
A widened response enumeration is a member's shape change under the clause above, recorded as one of its uses. This clause's first use: the environments member of list_applications's response in schemas/action_payloads.json, an array of environment names becoming an array of objects, each an environment's name, state, serving version, and hostname, when the platform held one builder account.
This clause's second use: the state member of each environment in list_applications's response in schemas/action_payloads.json, an enumeration of three values — deploying, deployed, never_deployed — becoming one of five with halted and deleting added. The platform then held one builder account. It is recorded here because no statement of this contract owns the member.
This clause's third use: the source member of read_logs's request in schemas/action_payloads.json, whose value all (three console logs merged by time) and whose omission (the app and platform sources) became the application's stream whole, every source the logging store holds. The platform then held one builder account. It is recorded here because no statement of this contract owns the member.
This clause's fourth use: submit_manifest's response members credential and platform_credential in schemas/action_payloads.json, answered on the wire surface alone and withheld on the MCP surface, the member credentials added to state which form the answer took. The same use made rotate_secret's request member value optional for the two platform-minted re-mints. The platform then held two builder accounts. It is recorded here because SEC-L0-07 and DBS-L0-02 own the members and neither is a statement of this document.
This clause's fifth use: the cutover of the platform's wire vocabulary to the product's public names (CQ-44). That vocabulary is the headers the serving router sets and the control plane reads, the settings the deploy injects, the OAuth scope, the credential prefixes and the browser cookies, and the product profile value. It is a change that stops every application built before the release until its owner rebuilds it and refuses every credential issued before the release, admitted by API-L0-16 as amended. The platform then held two builder accounts that each held a live application (three live applications in all, two on the operator's account and one on the second account). It is recorded here because the change reaches every member and no one statement of this contract owns it.
This clause's sixth use: the documentation reads split into an index and a whole text. read_documentation's request gains the optional member part, index (the default) or full. list_context's catalog gains one docs:<tree>:full entry per tree beside docs:<tree>, whose text becomes the tree's index, and every catalog entry may carry part. The MCP resource docs://<tree>/llms.txt answers the index where it answered the whole text, and docs://<tree>/llms-full.txt is added. The platform then held two builder accounts that each held a live application (three live applications in all, two on the operator's account and one on the second account, read through list_accounts and read_platform_usage under the operator's minted token). It is recorded here because CTX-07 owns the reads and is not a statement of this document.
This clause's seventh use: the standing member of each entry in list_library's response in schemas/action_payloads.json, an enumeration of three values — current, newer, withdrawn — becoming one of four with not_held added for a served entry the caller's installed list does not name. The platform then held two builder accounts that each held a live application (four live applications in all, three on the operator's account and one on the second account, read through list_accounts and read_platform_usage under the operator's minted token). It is recorded here because LC-06 owns the member and is not a statement of this document.
This clause's eighth use: the outcome member of each row in list_versions's response and of the deploy member in read_status's response in schemas/action_payloads.json. Its shape on a row failed at the health gate, served by the control plane's released build d8cc3b62, becomes the one gate member PLD-L0-59 states, carried whole by both reads. The shape it replaces is the four members last_status, startup_output, startup_output_truncated, and startup_output_pending, startup_output answered on read_status alone and the other three on both reads. The platform then held two builder accounts that each held a live application (four live applications in all, three on the operator's account and one on the second account, read through list_accounts and read_platform_usage under the operator's minted token). It is recorded here because PLD-L0-59 owns the member and is not a statement of this document.
This clause's ninth use, the wire error shape's members, is recorded by MAPI-10, the statement that owns the shape, as is every later use that changes a refusal's members, the fourteenth and the thirty-second among them.
This clause's tenth use: the index schemas/served_context.json and the skill rows schemas/skills.json each take a string version member on the served forms' spelling, a date and a counter, in place of their own markers, the number context_version and the number skills_revision. The served context bundle's member context_version becomes the string version with the index's, the two titles drop their revision numbers, and the smoke test reads the index's version (VER-02), so that the registrar's version rule and the landing's write reach both forms. The platform then held two builder accounts that each held a live application (five live applications in all, four on the operator's account and one on the second account, read through list_accounts and read_platform_usage under the operator's session). It is recorded here because CTX-01 owns the index and API-L0-10 the skill rows and neither is a statement of this document.
This clause's eleventh use: the detection_source member of the incident row record_incident answers in schemas/action_payloads.json, the row shape read_platform_status's open_incidents, incidents, and last_incident_closed members carry by description. Its enumeration of three values — automatic, operator, backfill — becomes one of four with condition added, the plane's conditions pass alone writing it (PLD-L0-83). The platform then held two builder accounts that each held a live application (six live applications in all, five on the operator's account and one on the second account, read through list_accounts and read_platform_usage under the operator's session). It is recorded here because PLD-L0-77 owns the member and is not a statement of this document.
This clause's twelfth use: the section member of each sections_unavailable row in read_platform_status's response in schemas/action_payloads.json, an enumeration of ten section names becoming one of eleven with conditions added after watches. The section itself is an added member of the response, and the response's summary_text bound moves from sixteen lines to seventeen, the added line naming the watched conditions open and failing (PLD-L0-83). The platform then held two builder accounts that each held a live application (six live applications in all, five on the operator's account and one on the second account, read through list_accounts and read_platform_usage under the operator's session). It is recorded here because PLD-L0-76 owns the document and is not a statement of this document.
This clause's thirteenth use: the kind member of each row in list_versions's response and of the deploy member in read_status's response in schemas/action_payloads.json, an enumeration of two values — deploy, promote — becoming one of three with redeploy added. redeploy is the platform's re-creation of an environment's serving compute under its current settings (PLD-L0-84). The descriptions that enumerate the kinds in schemas/action_payloads.json, schemas/management_api.json, and schemas/mcp_surface.json move with it. The platform then held one builder account that held five live applications (read through list_accounts and read_platform_usage under the operator's session). It is recorded here because PLD-L0-63 owns the member and is not a statement of this document.
This clause's fifteenth use: the state member of read_status's response and of each member of its environments in schemas/action_payloads.json, answered never_deployed or the compute's own word. It gains deploying where an environment holds no serving version and a deploy or promote row is in flight, so an environment's state and its deploy record agree. The descriptions in schemas/action_payloads.json, schemas/management_api.json, and schemas/mcp_surface.json move with it beside an added environment member naming the environment the top-level members describe. The platform then held one builder account that held five live applications (read through list_accounts and read_platform_usage under the operator's session). It is recorded here because no statement owns the member.
This clause's sixteenth use: the state member of read_status's response, at the top level and on each member of its environments, in schemas/action_payloads.json. It answered never_deployed, deploying, or the compute provider's own word, and becomes one of the six words PLD-L0-40 states, the provider's word moving to the added member compute_state. The same use widens the state member of each environment in list_applications's response, an enumeration of five values, to one of six with failed added. The descriptions in schemas/action_payloads.json, schemas/management_api.json, and schemas/mcp_surface.json move with it. The platform then held one builder account that held six live applications (read through list_accounts and read_platform_usage under the operator's session). It is recorded here because PLD-L0-40 owns the words and is not a statement of this document.
This clause's seventeenth use: the heartbeat_at member of the deploy member of each environment in read_status's response in schemas/action_payloads.json, renamed worker_heartbeat_at, so that no caller reads the deploy worker's liveness as the application's. The versions table's column, the stale sweep that reads it, and read_platform_status keep the name heartbeat_at. The descriptions in schemas/action_payloads.json, schemas/management_api.json, and schemas/mcp_surface.json move with it. The platform then held one builder account that held six live applications (read through list_accounts and read_platform_usage under the operator's session). It is recorded here because PLD-L0-63 owns the member and is not a statement of this document.
This clause's eighteenth use: the step member of the outcome of each row in list_versions' response in schemas/action_payloads.json, the outcome read_status answers whole on its deploy member, an enumeration of fourteen values becoming one of fifteen with issue_space added. The value is the step a promote runs while it provisions the production issue-tracking space, which a failed or stopped promote's row already carried. The platform then held one builder account that held six live applications (read through list_accounts and read_platform_usage under the operator's session). It is recorded here because PLD-L0-63 owns the member and is not a statement of this document.
This clause's nineteenth use: the issue_tracking member of submit_manifest's response in schemas/action_payloads.json, each environment's entry losing its origin and settings members and keeping the space's identifier and its outcome. No setting of the issue service is injected any more: an application reaches its space through the egress gateway's issue-tracking upstream, which presents the space's token (EGW-L0-06). The platform then held one builder account that held six live applications, the synthetic estate's one account aside (read from the production control database's rows). It is recorded here because ITS-L0-01 owns the member and is not a statement of this document.
This clause's twentieth use: deploy's request and response in schemas/action_payloads.json. The request's artifact becomes optional beside the added members upload and local_path. A call naming neither artifact nor upload answers 200 with the state awaiting_upload and the added members upload and next. So the response's state widens from one value to two, and its version and hostname are answered with the state deploying alone. The descriptions in schemas/action_payloads.json, schemas/management_api.json, and schemas/mcp_surface.json move with it. The platform then held one builder account that held seven live applications, read through list_accounts and read_platform_usage under the operator's session. It is recorded here because PLD-L0-86 owns the members and is not a statement of this document.
This clause's twenty-first use: the outcome member of each row in list_versions' response in schemas/action_payloads.json, the outcome read_status answers whole on its deploy member. It was null on a deployed row and becomes an object carrying result, which every ended row carries: succeeded, failed, interrupted, or superseded. The same use widens the state member of the answers of deploy, promote, roll_back, and restart_application with deployed and failed, answered where the call's wait saw its row end. The descriptions in schemas/action_payloads.json, schemas/management_api.json, and schemas/mcp_surface.json move with it. The platform then held one builder account that held seven live applications, the synthetic estate's one account aside, read through list_accounts and read_platform_usage under the operator's session. It is recorded here because PLD-L0-63 and PLD-L0-84 own the members and neither is a statement of this document.
This clause's twenty-second use, the narrowed range of wait_seconds on read_status and read_schedules, is recorded by MAPI-04, the statement that owns the member.
This clause's twenty-third use: the next_due member of each row of submit_manifest's schedules in schemas/action_payloads.json. It carried each row's next due time in both environments, and becomes null for a row whose environment holds no deploy or promote made at or after the row's declaration, as read_schedules answers it (SCH-L0-07). The same use adds the member starts_with beside it. The descriptions in schemas/action_payloads.json and schemas/mcp_surface.json move with it. The platform then held one builder account that held seven live applications, read through list_accounts and read_platform_usage under the operator's session. It is recorded here because SCH-L0-07 owns the member and is not a statement of this document.
This clause's twenty-fourth use: the detail member of read_logs' response in schemas/action_payloads.json. It was present on an empty answer alone, and is now present too on an answer whose window ends within its source's lag of the read, saying that the newest records may not have arrived yet. The descriptions in schemas/action_payloads.json, schemas/management_api.json, and schemas/mcp_surface.json move with it. The platform then held one builder account that held seven live applications, read through list_accounts and read_platform_usage under the operator's session. It is recorded here because the served form alone states when the member is present.
This clause's twenty-fifth use: the state member of each application in list_applications' response and in export_account's export in schemas/action_payloads.json, an enumeration of two values, deployed and never_deployed, becoming one of three with failed added. An application reads failed where its production environment reads failed and nothing serves, as after a failed first promote. The descriptions in schemas/action_payloads.json and schemas/mcp_surface.json move with it. The platform then held one builder account that held six live applications, read through list_accounts and read_platform_usage under the release coordinator's granted reads. It is recorded here because WEB-L0-17 owns the member and is not a statement of this document.
This clause's twenty-sixth use: the top-level hostname member of read_status's application in schemas/action_payloads.json. It was null before a deployment was recorded, and becomes the hostname of the environment the top-level members describe, as the environments member answers it, whether or not a deployment is recorded. The description in schemas/action_payloads.json moves with it, its clause that the hostname is null before a deployment retired. The platform then held one builder account that held six live applications, read through list_accounts and read_platform_usage under the release coordinator's granted reads. It is recorded here because no statement owns the member.
This clause's twenty-seventh use: the contains, level, and field members of read_logs' request in schemas/action_payloads.json. A container read ignored them and answered the console's lines unfiltered. It now refuses invalid_request where one would narrow a store read, as a non-empty contains, one of the four levels, or a named field does, and a store read filters by them as before. The descriptions in schemas/action_payloads.json, schemas/management_api.json, and schemas/mcp_surface.json move with it. The platform then held one builder account that held six live applications, read through list_accounts and read_platform_usage under the release coordinator's granted reads. It is recorded here because system:LGS-L0-15 owns the members and is not a statement of this document. That statement names them a stream read's filters and stands as written, its additive evolution under MAPI-02 admitting this use of the shape clause.
This clause's twenty-eighth use: the next member of deploy's answer to its preparing call in schemas/action_payloads.json. It named the second deploy call, and becomes the read_status call for development, with the preparing call's own wait_seconds, 45 where it gave none. The descriptions in schemas/action_payloads.json, schemas/management_api.json, and schemas/mcp_surface.json move with it. The platform then held one builder account that held six live applications, read through list_accounts and read_platform_usage under the release coordinator's granted reads. It is recorded here because PLD-L0-86 owns the member and is not a statement of this document.
This clause's twenty-ninth use: the request member environment of deploy in schemas/action_payloads.json, which narrows from a slug pattern to an enum of development and production. Over MCP a value outside the two now draws the argument's validation error before the handler, where the handler answered unknown_environment. The HTTP route validates no member's value and still answers unknown_environment. No value that succeeded before is refused, since every name but development was refused already. The platform then held one builder account that held six live applications, read through list_accounts and read_platform_usage under the release coordinator's grant of 14:48 UTC. It is recorded here because PLD-L0-40, which owns the refusal, is not a statement of this document.
This clause's thirtieth use: the previous_versions member of each entry in list_library's response in schemas/action_payloads.json, removed, so a full inventory answer no longer grows with every publish. The stored catalog keeps each entry's versioned history, and read_library_entry answers it. The same use has publish_library's commit phase refuse a commit other than the served one unless its added request member served_commit names the served commit. The descriptions in schemas/action_payloads.json and schemas/mcp_surface.json move with it. The descriptions moved when the platform held one builder account, which held six live applications. It is recorded here because LC-06 and LC-04 own the members and neither is a statement of this document.
This clause's thirty-first use: the issue_tracking member of submit_manifest's response in schemas/action_payloads.json, an object of one entry per environment becoming a list of one entry per space the application's calls reach, each with space, scope, environments, outcome, and level. The descriptions in schemas/action_payloads.json move with it. The platform then held one builder account that held six live applications, read through list_accounts and list_applications under the operator's session at the change. It is recorded here because ITS-L0-01 owns the member and is not a statement of this document.
This clause's thirty-third use: deploy's request and its answer to the preparing call in schemas/action_payloads.json. The answer's upload loses address and commands and gains command, the one line that runs the turnzero-cloud command (PLD-L0-94). The request gains zip_sha256, which every preparing call must name, a call without it, or with a value of another form, refused zip_sha256_required on every surface. The request's local_path gains a pattern refusing the characters a shell would change inside the line's double quotes, its absence naming the folder the line runs in, not app.zip. Over MCP a local_path outside the pattern draws the argument's validation error before the handler. The descriptions in schemas/action_payloads.json, schemas/management_api.json, schemas/mcp_surface.json, and schemas/wire_errors.json move with it. The descriptions moved when the platform held one builder account, which held six live applications. It is recorded here because PLD-L0-86 owns the members and is not a statement of this document.
This clause's thirty-fourth use, the value member of store_secret's and rotate_secret's requests marked x-wire-only and leaving both tool shapes, is recorded by MAPI-08, the statement that owns the argument derivation.
This clause's thirty-fifth use: deploy's request member environment in schemas/action_payloads.json, required becoming optional. A call that names none deploys to the application's deploy target, production on an application with one environment and development on one with two (PLD-L0-96). The same use has the environment of the next call in deploy's answer to its preparing call name that target, where it named development alone. The descriptions in schemas/action_payloads.json, schemas/management_api.json, schemas/mcp_surface.json, and schemas/wire_errors.json move with it. The platform then held one builder account that held six live applications, read through list_accounts and read_platform_usage under the operator's session at the change. It is recorded here because PLD-L0-96 owns the members and is not a statement of this document.
This clause's thirty-sixth use: the starts_with member of each row of submit_manifest's schedules in schemas/action_payloads.json, an enumeration of four values and null becoming five values and null, with the next deploy to production added. That value names the act a production schedule awaits on an application with one environment, where a deploy reaches production (PLD-L0-96). The descriptions in schemas/action_payloads.json move with it. The platform then held one builder account that held six live applications, read through list_accounts and read_platform_usage under the operator's session at the change. It is recorded here because SCH-L0-07 owns the member and is not a statement of this document.
This clause's thirty-seventh use: the request member tree of read_documentation in schemas/action_payloads.json, which leaves the request's required list. Where tree is absent, the read takes the tree from a page route whose first segment is a tree's base path, and a call naming neither still refuses invalid_request. The descriptions in schemas/action_payloads.json, schemas/management_api.json, and schemas/mcp_surface.json move with it. The platform then held one builder account that held six live applications, no synthetic account standing, read through list_accounts and read_platform_usage under the operator's session at the change. It is recorded here because CTX-07 owns the reads and is not a statement of this document.
This clause's thirty-eighth use: the request members application and environment of submit_feedback, read_feedback, rate_experience, and settle_feedback in schemas/action_payloads.json, removed and space added in their place. A call names the space it addresses, and a call naming either removed member is refused invalid_request naming space. The descriptions in schemas/action_payloads.json, schemas/management_api.json, and schemas/mcp_surface.json move with it. The platform then held one builder account and six live applications, a synthetic account aside, read through list_accounts and read_platform_usage under the operator's session at the change. MAPI-18 states the rows and records the use beside them.
This clause's thirty-ninth use: the application_spaces member of export_account's feedback in schemas/action_payloads.json, renamed spaces, each entry gaining kind and its application and environment admitting null. The member carries the account's own filings from each space the account owns, binds, or holds in custody for a standing pair. The description in schemas/action_payloads.json moves with it. The platform then held one builder account and six live applications, a synthetic account aside, read the same way at the change. It is recorded here because ACB-L0-47 owns the member and is not a statement of this document.
This clause's fortieth use: the request member query of read_documentation in schemas/action_payloads.json, which loses its minLength, so an empty query reaches the handler and is refused invalid_request in words saying what to send. A query naming no tree is now answered, searching every tree the connection may read, where it refused invalid_request. The descriptions in schemas/action_payloads.json, schemas/management_api.json, and schemas/mcp_surface.json move with it. The platform then held one builder account that held six live applications, a synthetic account aside, read through list_accounts and read_platform_usage under the operator's session at the change. It is recorded here because CTX-07 owns the reads and is not a statement of this document.
This clause's forty-first use: the section member of each sections_unavailable row in read_platform_status's response in schemas/action_payloads.json, an enumeration of eleven section names becoming one of twelve with settings added after azure. The section itself is an added member of the response, answering each served value as stored, and the request's sections enumeration widens with it. The descriptions in schemas/management_api.json and schemas/mcp_surface.json move with it. The platform then held one builder account that held six live applications, read through list_accounts and read_platform_usage under the operator's session at the change. It is recorded here because PLD-L0-76 owns the document and is not a statement of this document.
This clause's forty-second use: the contains member of read_logs' request in schemas/action_payloads.json, on a container read. A non-empty contains there was refused invalid_request since the twenty-seventh use, and is now answered, the console's lines matched in the plane, while level and field stay refused. The detail member of the response is present on such an answer wherever the read fetched a line, a pod's answer among them, opening with the lines searched and matched. The descriptions in schemas/action_payloads.json, schemas/management_api.json, and schemas/mcp_surface.json move with it. The platform then held one builder account that held six live applications, a synthetic account aside, read through list_accounts and read_platform_usage under the operator's session at the change. It is recorded here because system:LGS-L0-15 owns the member and is not a statement of this document, PLD-L0-62's thirteenth paragraph stating the behaviour.
This clause's forty-third use: the request member query of read_documentation in schemas/action_payloads.json. An empty query, or one of white space alone, was refused invalid_request since the fortieth use, and is now read as if the call had left the member out, so a page read that carries one is answered. Its length and its type are judged first, on the value as sent. The member's description in schemas/action_payloads.json moves with it. The platform then held one builder account, a synthetic account aside, read through list_accounts under the operator's session at the change. It is recorded here because CTX-07 owns the reads and is not a statement of this document.
This clause's forty-fifth use: the state member of the backend actions, data transfer, and stored data measures in read_usage's and read_platform_usage's responses in schemas/action_payloads.json. On such a measure no pass has recorded a state for, it answered unknown whatever its month_total. It now answers unknown where month_total is null, and otherwise unset where quota is null and ok where that figure is below the warning fraction of quota. It answers unknown where that state would be warning or over, and the read writes nothing. The descriptions in schemas/action_payloads.json, schemas/management_api.json, and schemas/mcp_surface.json move with it. The platform then held one builder account and no synthetic account, read through list_accounts under the operator's session at the change. It is recorded here because ACB-L0-26 owns the states and is not a statement of this document.
This clause's forty-sixth use, the preparing form of store_secret and rotate_secret and the members their requests and responses gained for it, is recorded by MAPI-08, the statement that states that form.
This clause's forty-seventh use: mint_upload_grant's request and response and deploy's request and response in schemas/action_payloads.json. mint_upload_grant's request gains local_path, held to the class the deploy call's local_path admits, and a call naming one outside it is refused invalid_request, in place of an answer that ignored the member. Its response gains command and command_windows, and deploy's upload gains command_windows among its required members. deploy's local_path now refuses &, |, <, >, and ^ too, as store_secret's and rotate_secret's value_file does. The descriptions in schemas/action_payloads.json, schemas/management_api.json, schemas/mcp_surface.json, and schemas/skills.json move with it. The platform then held one builder account that held six live applications, a synthetic account aside, read through list_accounts and read_platform_usage under the operator's session at the change. It is recorded here because OST-L0-08 and PLD-L0-86, which state the line, the member, the class, and the Windows form, are not statements of this document.
This clause's forty-eighth use: the download member of read_library_entry's entry answer in the payload contract. Its command was a one-line script that wrote an entry's files alone, and is now the line that runs the turnzero-cloud command's library take, which also writes the entry's manifest row and installs a package's copy. The member gains command_windows, the same line for Windows, and command leaves its required members, so an entry whose name the line cannot carry is answered next alone. The descriptions in the payload contract, the tool catalog, and the skill rows move with it. The platform then held one builder account that held six live applications, and no synthetic account, read through list_accounts and read_platform_usage under the operator's session at the change. It is recorded here because LC-05 and PLD-L0-100, which state the line and the take, are not statements of this document.
This clause's forty-ninth use: submit_manifest's request and response in schemas/action_payloads.json. Its request gains the optional member local_run, true alone, and a call naming any other value is refused invalid_request. Where the request names it, the response's provisioning carries command, command_windows, and expires_at. Its required members are for and command, and no longer the script's address and sha256, which a submission naming no local_run still answers. The descriptions in schemas/action_payloads.json, schemas/management_api.json, schemas/mcp_surface.json, schemas/skills.json, and schemas/wire_errors.json move with it. The platform then held one builder account that held six live applications, and no synthetic account, read through list_accounts and read_platform_usage under the operator's session at the change. It is recorded here because SEC-L0-07, DBS-L0-02, and SEC-L0-19, which state the member, the grant, and the line, are not statements of this document.
This clause's fiftieth use, the refusal of a call that names a member its action does not declare, is recorded by MAPI-22, the statement that owns the rule.
This clause's fifty-first use: submit_manifest's response in schemas/action_payloads.json. Its provisioning member no longer carries address and sha256, and its one required member is for. Where the request names no local_run, the member carries next, one sentence naming local_run, on the MCP surface, and is absent over the wire. Where the request names it over the wire, a response that minted a credential states credentials: withheld, and none carries credential or platform_credential. Each response that carries the line carries next beside it, which says where the values are. The descriptions in schemas/action_payloads.json, schemas/management_api.json, schemas/mcp_surface.json, schemas/skills.json, and schemas/wire_errors.json move with it. The platform then held one builder account that held six live applications, and no synthetic account, read through list_accounts and read_platform_usage under the operator's session at the change. It is recorded here because SEC-L0-07 and DBS-L0-02, which state the member and what each surface answers, are not statements of this document.
This clause's fifty-second use: what the grant in mint_download_grant's line reads on the storage file route, and the response's detail in schemas/action_payloads.json. Outside its export's folder the grant read each file of the application's other areas, and now reads one only where it was created by the time the export listed its stored files. A file created later answers 404 no_such_file where it answered 200. Where the export's row holds no instant, the grant reads the folder alone, and detail names a fresh export. The descriptions in schemas/action_payloads.json, schemas/management_api.json, schemas/mcp_surface.json, and schemas/wire_errors.json move with it. The platform then held one builder account that held six live applications, and no synthetic account, read through list_accounts and read_platform_usage under the operator's session at the change. It is recorded here because OST-L0-08, which states the reach, is not a statement of this document.
This clause's fifty-third use: the path members of five requests and publish_library's catalog in schemas/action_payloads.json. deploy's, mint_upload_grant's, and mint_download_grant's local_path, and store_secret's and rotate_secret's value_file, refuse a path that is ~ or opens with ~/ or ~\, 400 invalid_request, where each answered a line that read or wrote under a folder named ~. A publish_library call whose begin carries a catalog holding an entry name outside the form a take line carries is refused invalid_request, where it stored an entry no line could take. The descriptions in schemas/action_payloads.json and schemas/library_catalog.json move with it. The platform then held one builder account that held six live applications, and no synthetic account, read through list_accounts and read_platform_usage under the operator's session at the change. It is recorded here because PLD-L0-86 and LC-01, which state the class and the form, are not statements of this document.
This clause's fifty-fourth use: submit_feedback's issue member and three refusals on the platform's own space, for a credential that does not read the queue. The member is null where MAPI-18 withholds the issue, where it was an object in every answer. The recovered mark answers the member's id, status, and disposition alone, where it answered the issue as the 0.2.0 wire gives it. A confirmation that names a restricted issue, and a recovered mark MAPI-18 does not relay, are refused where each was relayed. The description in schemas/action_payloads.json moves with it. The platform then held one builder account and no open invitation, read at the change.
This clause's fifty-fifth use: the name member of mint_upload_grant's request in schemas/action_payloads.json. A name holding a backslash, or a segment that ends with a dot, is refused 400 invalid_request, where the call minted a grant for it, because the file route refuses a write of such a name (OST-L0-02). The same use records that used in read_usage's ai_allowance_units now counts the units of a forwarded call that ended early (EGW-L0-06), an answer that moves with no member's shape moving, as the forty-fifth use's did. The two members' descriptions move with it. The platform then held one builder account and no synthetic account, read through list_accounts under the operator's session at the change. It is recorded here because OST-L0-02 and EGW-L0-06, which state the two rules, are not statements of this document.
This clause's fifty-sixth use: record_check's issue and check members, for a credential that does not read the queue. The issue member carries the members a filing's answer gives of an issue and no report, where it carried the issue record whole. It is null where MAPI-18 withholds the issue, where it was an object. The check member carries no lease and no held_by member, and its own issue member is null where the answered issue is null, where each was as the service gave it. The descriptions in schemas/action_payloads.json move with it. The platform then held one builder account and no open invitation, read at the change.
This clause's fifty-seventh use: store_secret's answer to a store that would add a name to an environment scope of an application that holds 100 names, refused 409 secret_count_limit before any write, where the store was answered. The descriptions in schemas/mcp_surface.json and schemas/wire_errors.json move with it. The platform then held one builder account, read through list_accounts earlier on the day of the change. It is recorded here because SEC-L0-21, which states the bound, is not a statement of this document.
This clause's fifty-eighth use: the admission window on every management action. A call to list_library or read_library_entry, which need no credential, from a source past three thousand such calls in the minute is refused 429 rate_capped where it was answered. So is a call to list_context or read_context, or one that names an action with no handler or no action, from a source past six hundred requests in the minute. The admission window's 429 rate_capped at the control plane carries a Retry-After header, the seconds to the next minute, where it carried none. The summary of rate_capped in schemas/wire_errors.json moves with it. The platform then held one builder account and no open invitation, read at the change. It is recorded here because PLD-L0-67, which states the window, is not a statement of this document.
This clause's fifty-ninth use: the request members personal and excerpt of submit_feedback, and the personal member of its response's report, in schemas/action_payloads.json. The request declares neither, and a call that names one is refused invalid_request where it was taken, its detail adding the sentence the request's x-retired carries. The descriptions in schemas/action_payloads.json, schemas/management_api.json, and schemas/mcp_surface.json move with it. The platform then held one builder account that held six live applications, and no synthetic account, read through list_accounts and read_platform_usage under the operator's session at the change. It is recorded here because the removal reaches two statements of this document, MAPI-18 for the members and MAPI-22 for the refusal.
This clause's sixtieth use: the admission window of a request that presents a credential on the storage, egress, logging, and push wires. A request there whose presented value resolves to no credential counts in a window its source has for such requests, and past six hundred of them in the minute is refused 429 rate_capped where it was answered 401 authentication_required. Every token of one end-user session counts in that session's one window, where each counted in its own. A request there in another letter case, or with a route's one trailing slash, counts as the path as written does, where it counted by its source. The summary of rate_capped in schemas/wire_errors.json moves with it. The platform then held one builder account and no open invitation, read at the change. It is recorded here because PLD-L0-67, which states the window, is not a statement of this document.
This clause's sixty-first use: submit_feedback's answer to a confirmation that names a restricted issue, for a credential that reads the queue on the platform's own space and for any credential on a space the request names. The confirmation is refused 404 not_found as one naming no issue is, where it was relayed and linked, for a report the plane filed field, beta, person, or test, since the service confirms none of those onto a restricted issue (MAPI-18). The platform then held one builder account, one synthetic account, and no open invitation, read at the change.
This clause's sixty-second use: submit_feedback's issue and outcome members where a filing's evidence matches a report on a restricted issue, on the platform's own space and on a space the request names, for a report the plane filed field, beta, person, or test. The issue member carries the unrestricted issue the filing joined or opened, and outcome reads filed where the filing opens an issue of its own, where it read linked. On the platform's own space the issue member was null for a credential that does not read the queue; for one that reads it, and on a named space, it was that restricted issue through the projection (MAPI-18). The platform then held one builder account, one synthetic account, and no open invitation, read at the change.
This clause's sixty-third use: submit_feedback's recovered mark, for a credential that reads the queue on the platform's own space and for any credential on a space the request names. The mark is refused 404 not_found where the caller's filing under the key did not open the issue, or another reporter's report stands on it, where it was relayed and settled the filing (MAPI-18; the package's XIT-01). The platform then held one builder account, one synthetic account, and no open invitation, read at the change.
This clause's sixty-fourth use: what relay_issue_act answers a token below the owner level of its issues grant. A relayed follow, update, comment, relate, or give_back naming an issue ITS-L0-05 withholds is refused 404 issue_refused, as one naming no issue is, where it answered 200. A relayed submit's or check's issue member is null for such an issue, and a relayed next answers each member null, where each was as the service gave it. A relayed arising_from relation whose target has an issue identifier's form is refused 400 invalid_request, where it answered 200. A relayed submit's report carries the origin field, where it carried the origin the body named, so one of the kind question or task is refused 400 issue_refused. The platform then held one builder account and no open invitation, read at the change. It is recorded here because ITS-L0-05 is not a statement of this document.
This clause's sixty-fifth use: submit_manifest's settings rows on an application with one environment. The answer carries one row per setting, production's, where it also carried a row naming development. No deploy or promote of such an application reads the development scope, and an AI tool read that row's stored: false as a value to store. An application with both environments is answered both rows, as before. The platform then held one builder account and no open invitation, read at the change. It is recorded here because MAN-14 is not a statement of this document.
This clause's sixty-seventh use: deploy's answered state in schemas/action_payloads.json, with one request member and one refusal. The answered state gains the values awaiting_command and withdrawn. The request gains the member withdraw, which the HTTP action route alone carries, and the response gains command, command_windows, expires_at, and previous_code. The refusal catalogue in schemas/wire_errors.json gains deploy_code_refused. The plane admits the member and answers the values, the members, and the refusal only where it serves the line form of deploy. Where it does not, a call naming withdraw on the HTTP action route is refused 400 invalid_request. The platform then held one builder account and no open invitation, read at the change. It is recorded here because PLD-L0-86, which states the line form and the deploy code, is not a statement of this document.
This clause's sixty-eighth use: deploy's request and its answers in schemas/action_payloads.json. zip_sha256 is marked wire-only beside withdraw: the MCP tool declares neither, and a tool call naming either is refused 409 local_route_required where it prepared an upload. A call naming none of zip_sha256, artifact, and upload answers the line form, 200 awaiting_command, where it drew 400 zip_sha256_required, and that row leaves schemas/wire_errors.json. The preparing call's answer gains upload.grant, and upload.command and upload.command_windows carry that value where each carried a line. At the preparing form a grant-form bearer resolving to no credential is refused deploy_code_refused where it drew authentication_required, and a start under a session or token of an upload a later deploy call ended is refused upload_not_found. The platform then held one builder account and no open invitation, read at the change. It is recorded here because PLD-L0-86 owns the members and is not a statement of this document.
This clause's sixty-ninth use: deploy's answer to a deploy, by the artifact or the upload form, to an environment that holds no serving version, whose zip names its manifest's health path in no source file. It was answered 202 and started, and is now refused 400 health_path_unserved before any write, a row the refusal catalogue in schemas/wire_errors.json gains. The platform then held one builder account and no open invitation, read at the change. It is recorded here because PLD-L0-63, which states the check, is not a statement of this document.
This clause's seventieth use: read_logs' answer in schemas/action_payloads.json. A container read that was refused never_deployed where the environment names no compute is answered where a failed first deploy's or first promote's health check kept a record, and the answer gains the member failed_check. The platform then held one builder account and no open invitation, read at the change. It is recorded here because PLD-L0-59, which owns the behaviour, is not a statement of this document.
This clause's seventy-first use: what relay_issue_act answers a contribute-level issues grant, which the sixty-fourth use recorded for every level below owner. A relayed list answers a restricted issue it left out, and a relayed read answers one it refused 404 issue_refused. A relayed update, comment, relate, or give_back naming one now reaches the service, once refused 404 issue_refused. A relayed submit, check, or next answers such an issue whole, once null, with no lease given back. A relayed update whose fields name restricted with any value but true is refused 403 issues_level_refused, where it answered 200. A relayed follow naming one is still refused 404 issue_refused by the service, its report carrying the origin field. The platform held 1 builder account and 0 open invitations, read at the change; ITS-L0-05 is not a statement of this document.
This clause's seventy-second use: deploy's answer at its wire preparing form to a deploy code whose minting credential no longer stands, a token revoked or expired or a session ended since the mint. It was admitted where the code's own end was not written, and is now refused 403 deploy_code_refused, alike to an unknown code's answer. A code a session minted on the earlier revision is refused so once. The same use has reinstate_account refused with the store's failure, the account still suspended, where ending its codes fails, and a session's code answer an expires_at no later than its session's expiry. The platform then held one builder account and no open invitation, read at the change. It is recorded here because PLD-L0-86 is not a statement of this document.
This clause's seventy-third use: the lookup limit on the storage, egress, logging, and push wires. A request whose presented value the gateway cache does not hold, and whose lookup cannot start within the wait bound, is refused 503 credential_lookup_busy with Retry-After of one second, where it was looked up. Through the edge, such a request from a source at its bound for unresolved values is refused 429 rate_capped before its lookup, where a value that then resolved was admitted. The credential_lookup_busy row and the summary of rate_capped in schemas/wire_errors.json move with it. The platform then held one builder account, a synthetic test account beside it, and no open invitation, read at the change. It is recorded here because PLD-L0-67, which states the limit, is not a statement of this document.
This clause's seventy-fourth use: the token code form's dark leaves in schemas/action_payloads.json and schemas/wire_errors.json (MAPI-23), each answered only where the token code form is served. mint_token's request gains code_challenge, authorized_computer, and the wire-only code_verifier. Its response gains state, command, command_windows, expires_at, and detail; value leaves its required list, and id, created_at, revoked_at, and last_used_at leave the token object's, each form's description declaring its own; and the token object and list_tokens's rows gain authorized_computer. The row token_code_refused joins the refusal catalogue, additive (MAPI-15). The settings enums of set_status_setting and read_platform_status gain token_code_seconds, served whatever the switch. The platform then held one builder account, a synthetic test account beside it, and no open invitation, read at the change. Its owner is MAPI-23, a statement of this document.
This clause's seventy-fifth use: the action rotate_realm_keys, renamed revoke_realm_keys with its MCP tool, because the act revokes the realm's session signing keys (ACS-L0-08). The owner approved the rename. Over the actions route a call naming the old name answers 404 unknown_action, its detail naming revoke_realm_keys, and the tool surface moves with MCP-08's revision 2. The descriptions in schemas/action_payloads.json, schemas/management_api.json, schemas/mcp_surface.json, and schemas/wire_errors.json move with it. CQ-97's three action renames within version 1 are the precedent. The platform then held one builder account and no standing synthetic account, read at the change. It is recorded here because ACS-L0-08, which owns the action, is not a statement of this document.
This clause's seventy-sixth use: the value redeploy of the kind member of each row in list_versions' response, of the deploy member in read_status's response, and of failed_check in read_logs' response in schemas/action_payloads.json, renamed restart. The versions table's stored value, the stores that read it back, and the mark-redeploy pass keep the name redeploy, and the answers write restart for it, as the seventeenth use kept heartbeat_at. The descriptions in schemas/action_payloads.json, schemas/management_api.json, and schemas/mcp_surface.json move with it. The platform then held one builder account and no standing synthetic account, read at the change. It is recorded here because PLD-L0-63 owns the member and is not a statement of this document.
This clause's seventy-seventh use: the realm member routes, renamed sign_in_methods in configure_realm's request and answer, in read_realm's and export_account's answers, and in the manifest's realm member. The control database's column realms.routes keeps its name. configure_realm's request carries MAPI-22's x-renamed for routes, so a call naming it is refused invalid_request naming sign_in_methods. A recorded manifest naming realm.routes is read under sign_in_methods. A submitted one is refused manifest_invalid at /realm/routes, its detail naming sign_in_methods and the one-line edit that renames the member. The descriptions in the payload contract, the tool catalog, the API schema, and the manifest schema move with it. The platform then held one builder account and no standing synthetic account, read at the change. It is recorded here because ACS-L0-07 owns the member and is not a statement of this document.
MAPI-03 (decided): A credential is a bearer credential presented per request, never carried in a URL, and it is one of four kinds: the session credential, the minted token, the platform credential, and no credential. Beside them, the third, eighth, and ninth paragraphs admit four short-lived grants, each on the requests its act admits and on nothing else. The session credential is minted by a present person's sign-in and takes three forms. The first is the bearer session the OAuth flow issues (MCP-02's binding). The second is the browser credential the approval page runs under (MAPI-05) and the signed-in site's server-rendered pages run their acts under through the one seam (WEB-L0-16; CQ-63), no credential on the wire. The third is the browser session, the API cookie of the browser leg (WEB-L0-16), which the actions routes alone admit as a wire credential under a guard of their own (CQ-43).
The minted token of API-L0-05 is created by a session through mint_token and bounded at its minting to the account or to one application (API-L0-17; MAPI-14); the CI credential and the application-bounded builder credential are this one kind under its two scopes. The platform credential of SEC-L0-07 is admitted here by read_account alone. The fourth kind is no credential, on the rows MAPI-11 marks anonymous.
A credential the platform issues for a data-plane act alone is refused by name on every action of this contract, but for the start of an upload that deploy admits under that upload's own grant (OST-L0-08; PLD-L0-86; CQ-186). Those are the end-user credential the accounts service issues, the transfer grant object storage mints, and the egress key the platform mints for one upstream of one compute (SEC-L0-18), each stated by its own surface. The secret grant, which the platform mints for one custody act, is admitted on store_secret and rotate_secret over the wire for the requests its act admits, and on nothing else (SEC-L0-19). Every other action, and a request the grant's act does not admit, refuses it secret_grant_not_admitted, but for the rules the sixth paragraph names. A request it admits is refused secret_grant_spent once the grant is spent, and secret_grant_expired once it has expired unspent.
A bearer of a grant's form that resolves to no credential is refused authentication_required, with the challenge MCP-02 states for a presented credential that resolves to nothing. Such a bearer is a grant never minted, a grant whose record the platform has removed after its expiry or with its application or account, or a value that differs from the one minted. No record answers, so the refusal names no kind of grant. Its detail says that the platform serves no grant of that value, and that a grant lasts minutes and serves the one act its mint names. It names both ways to a fresh grant: a tool call whose answer carried the grant is made again and the fresh command it answers is run, and an application that requested the grant requests another. At deploy's wire preparing form the eighth paragraph's refusal answers such a bearer instead.
The browser session is read only from a same-origin JSON post that presents no Authorization header and is verified as the dashboard guard verifies its cookie. It is admitted only on an action whose catalog row names both bearer and browser_session among its clients, every other action refusing it authentication_required before any store read. A state-changing action under it past the freshness window WEB-L0-16 states is refused fresh_authentication_required. It runs on the browser surface, which is answered no credential value (SEC-L0-07). Every other surface, /mcp and the data-plane surfaces among them, keeps resolving the Authorization header alone. The authority tiers bind per credential (API-L0-06): what a credential may do is its grant, the destructive class is deny-until-granted, and no client kind carries a laxer tier than any other (API-L0-11).
This paragraph names the rules that answer a request presenting a secret grant ahead of the third paragraph's refusal. A browser-only action reads no credential and refuses any bearer browser_session_required (MAPI-05). An anonymous read reads none either, and answers as it answers a request that presents no credential (MAPI-11). An action switched off reads the grant and refuses by its switch's name (MAPI-16). None of the three admits the grant to anything.
A secret grant whose act is provision is admitted on rotate_secret over the wire for its application's two platform-minted names at the development scope, each once (SEC-L0-19). The request names no value and carries no member beyond the name, the application, and the environment. A second re-mint of a name is refused secret_grant_spent. submit_manifest takes the member local_run, which asks for that grant's line: true alone, on the MCP surface and over the wire under a bearer credential. Any other value, and the member on a surface that is answered no credential, is refused invalid_request with nothing recorded.
This paragraph adds the deploy code to the third paragraph's short-lived grants (PLD-L0-86). A deploy code is admitted at deploy's wire preparing form, once, for the requests its act admits, and on nothing else. At that form an unknown, a spent, and an expired code, and a bearer of a grant's form that resolves to no credential, are refused 403 deploy_code_refused, in place of the fourth paragraph's refusal. On every other request a deploy code resolves to no credential and is answered as the fourth paragraph states, unspent.
This paragraph adds the token code to the third paragraph's short-lived grants (MAPI-23), where the token code form is served. A token code is admitted at mint_token's wire exchange form, once, for the one exchange its mint names, and on nothing else. At that form an unknown, a spent, and an expired code, and a bearer of a grant's form that resolves to no credential, are refused 403 token_code_refused, in place of the fourth paragraph's refusal. On every other request a token code resolves to no credential and is answered as the fourth paragraph states, unspent. A transfer grant, a secret grant, or a deploy code presented at the exchange form is answered as this statement and PLD-L0-86 state, unspent.
MAPI-04 (decided): Every action carries its tier in the enumeration — observe, reversible, destructive — and the tier governs the call's shape. An observe action changes nothing and may be repeated freely. A reversible action completes in the call that made it or, where its own statement says so — run_schedule, deploy, promote, roll_back, restart_application, and purge_synthetic_accounts —, records the act and answers at once, its outcome read through the observe act that statement names. Of these, run_schedule and the four acts the sixth paragraph names answer at once unless the request's wait_seconds holds the answer, as that paragraph states. A retried reversible call is a second call of the action, what a repeat does being each action's own statement's to say.
A destructive action accepts a client-supplied request identity, the optional request_id member of its request, so a retried request lands on the same pending action once rather than creating a second one, because the callers are AI tools, and retry-on-timeout is how they behave. MAPI-05 states the match.
No reversible request schema in schemas/action_payloads.json carries a request identity the plane ignores. The twelve that did — suspend_account, reinstate_account, mint_token, revoke_token, set_egress_mode, configure_realm, revoke_end_user, reinstate_end_user, issue_invitation, revoke_invitation, set_plan, set_plan_quota — lost the member as MAPI-02's second paragraph records, and a call naming it is refused as MAPI-22 states. run_schedule's required request_id, which its own code reads, is not within that removal, what its repeat answers being that action's own statement's to say. The optional request_id of seed_synthetic_accounts and of purge_synthetic_accounts is a member of the same kind, read by their code, each repeat answering as MAPI-16 states.
This paragraph qualifies the first paragraph's clause that an act answered at once has its outcome read through an observe act. Two such reads, the status read read_status and the schedule read read_schedules, take an optional request member wait_seconds, an integer from 1 to 45, and hold their answer until nothing they wait for is in flight. For the status read that is any version-history row of the application still deploying (PLD-L0-63); SCH-L0-06 names the schedule read's. The payload schema states the range, which the MCP argument layer holds, and the handler refuses a value outside it invalid_request itself, because the HTTP route validates no member's value (MAPI-02). A held read reads the store every two seconds and stops polling at wait_seconds, counted as the seventh paragraph states. It then answers as the read always does, adding settled, true where its last store read found nothing in flight, and waited_ms.
This paragraph bounds the held read the paragraph above states. A held read's last store read is the read that composes its answer, which the fourth paragraph's settled reads, and each early end below answers settled from that read. A read that finds nothing in flight answers at once. A process holds at most one held read per application and fifty in all, and a read beyond either answers at once. The deploy command's progress read holds one place per upload, never an application's, counted in the fifty and stopping at its route's 25 seconds (PLD-L0-86). A held read answers at once when its process begins to shut down, before the listener closes, and ends when the caller's connection closes. An answer of an act of the sixth paragraph that did not settle names the wait in its detail, and run_schedule's answer without one names both waits by their actions.
This paragraph extends the fourth paragraph's held read to the four acts that start a version-history row, deploy in either of its starting forms, promote, roll_back, and restart_application (PLD-L0-63; PLD-L0-84; PLD-L0-86), and to run_schedule. Each takes the same wait_seconds and holds its answer until the row it started ends, answering as PLD-L0-63 states, or for run_schedule until its run ends (SCH-L0-06). Each hold is a held read of this statement, polling as the fourth paragraph states and bounded as the fifth states. So an act's hold takes its application's one held place, and a concurrent held read of that application on the same process answers at once. An act that finds the place taken answers at once, its settled from its own row or run. deploy's line-form and preparing calls start no row: each holds nothing and carries the member into its next, 45 where absent.
This paragraph bounds every wait this statement states by the call's own time. A held read or act stops polling once wait_seconds have passed since its credential was admitted, so the time an act spends before its hold, a slow artifact read among them, is spent from its wait. A container read's wait stops at the earlier of its wait_seconds and forty seconds, so a value above 40 is held 40. The hold adds nothing past that point but the final read's own time, so an answer whose work before the hold took less than its wait stays under fifty seconds. On the wire, a value outside 1 to 45 is refused invalid_request by the handler, its detail naming 45 as the most the member admits, for the three reads and the held acts alike. Over MCP the argument layer refuses it first, its text naming the same bound.
This paragraph extends the fourth paragraph's held read to the log read read_logs on a store source. It takes the same wait_seconds and holds its answer while the read with the call's own filters finds no entry, answering from a fresh read with waited_ms and no settled. Its hold is a held read of this statement, polling, bounded, and placed as the fourth, fifth, and seventh paragraphs state, and an empty answer whose wait found the place taken says so in its detail. A container read carrying the member holds as the twelfth paragraph states and never polls, because each console read is a query to the provider.
This statement records the twenty-second use of MAPI-02's clause on a member's shape, which MAPI-02 names among its uses. The request member wait_seconds of read_status and read_schedules in schemas/action_payloads.json narrows from 1 to 50 to 1 to 45, so a value from 46 to 50 that the reads admitted is refused invalid_request. The reads never polled past 45 seconds, so the narrowed range states the bound they honoured. The platform then held one builder account that held seven live applications, the synthetic estate's one account aside, read through list_accounts and read_platform_usage under the operator's session.
This paragraph names the one home of the waits' figures. One set of code constants holds the range, the poll, the polling stop, and the cap for the reads and the held acts, and the container wait's stop and its cap on followed consoles beside them. The deploy command's progress read takes its stop from its route (PLD-L0-86).
This paragraph qualifies the sixth paragraph's held acts and the first paragraph's retried call. An answer to one of those acts that is not the platform's own, an edge's error page or a closed connection among them, says nothing about whether the act was made. The server's instructions (MCP-05) and each act's description say so, and send the caller to the act's status read first, read_status, or read_schedules for run_schedule. One of the four acts started only where its environment's deploy member names the kind of row the act starts, with a started_at later than the call. A deploy's upload that pending_upload still names was not started, and its retry starts it. Each of the four acts is repeated only where that read shows no start, and run_schedule only with the same request_id, as its own statement says. What a repeat does stays each act's own statement's to say.
This paragraph extends the eighth paragraph's wait to a container read, which holds by following its console instead of polling. Where the operator's console_live_tail is 1 (PLD-L0-62), the read takes the application's one held place first. It then follows the console of each running instance of the serving compute and of a deploy's candidate, three at most, or of a pod's newest instance, beside the console store's read on the container grain. It holds its answer until a followed or stored line the call's filters admit, stamped at or after its since, is read, or until the seventh paragraph's stop. It answers as a container read does, every line its follows read merged in, with waited_ms and no settled. Where nothing runs, or every follow has closed, it lists the instances once more ten seconds later and follows a newcomer, never listing a third time.
This paragraph bounds the twelfth paragraph's wait. A process holds at most nine followed consoles beside the fifty held reads, and a wait following none counts one. A wait that finds the switch at 0, the place taken, the process's nine follows held, or, on the pod grain, no pod at its one more listing answers at once as an ordinary container read, its detail naming which. On the container grain, each listing reads the management API's remaining reads from its first answer; below fifty the wait answers at once with the lines read so far, and it lists a second time only where at least one hundred remain. A deploy, a promote, and a roll back do not read that figure, so fifty is what a burst of waits leaves them. The wait ends on the caller's close and at the process's shutdown, and each end closes every follow.
This statement records the sixty-sixth use of MAPI-02's clause on a member's shape. The request member wait_seconds of read_logs in schemas/action_payloads.json, refused on a container read, is now admitted there as the twelfth paragraph states. The descriptions in schemas/action_payloads.json and schemas/mcp_surface.json move with it. The platform then held one builder account that held six live applications, a synthetic account aside, read through list_accounts and read_platform_usage under the operator's session at the change.
This paragraph qualifies the twelfth paragraph's hold on the pod grain. A pod wait whose last follow closes after its one more listing, as when the pod's process exits, answers at once with the lines read so far and no sentence on how it ended, since a pod's console ends with the pod.
This paragraph qualifies the twelfth and thirteenth paragraphs for a container read answered from a failed check's kept lines (PLD-L0-59). That read reads the version row, not a console, so it takes no held place and answers at once, its detail saying so.
MAPI-05 (decided): The pending action is a resource of this contract: a destructive action's request creates one, and its record carries Turn Zero Cloud's own description of what will be destroyed. The one action that completes it — approval — is callable only by a signed-in person's browser session (WEB-L0-13), a client restriction the enumeration states and the suite refuses violations of. The requesting credential reads the record and its outcome; nothing but the browser approves. The request's request_id member is the pending action's request identity (MAPI-04): a string the caller chooses, matched by equality and never interpreted.
A second request carrying the same request_id, from the same requesting account, for the same action, while the earlier record is live (approved or executing, or requested and not past its expiry), answers that record, its approval link included, and creates no second one. A record that is no longer live — completed, failed, declined, expired, or requested and past its expiry — matches nothing, so the same request_id then starts a new pending action. A request carrying no request_id is matched to no earlier request, each such call creating its own pending action.
The match runs after the destructive request has passed the credential gates and its description has been produced, so a request that refuses by name refuses on every repeat and matches nothing. The subject named by a repeat is not compared, the caller's identity being the caller's to keep distinct. The durable store holds the match as one partial unique index over requesting account, action, and request identity on the live states. A test in the platform's suite holds the match, the per-account separation, the release after a decline, the unmatched case, and the lapsed case.
MAPI-06 (decided): Every action writes the append-only operational record — actor, credential, action, subject, outcome, any confirmation, and, on a dispatched call's row, the reference the call's answer carries (API-L0-19) — from the first action of C2 onward. The credential is recorded as itself and not only as its kind: its kind always, and its own identity wherever it has one, which an unattended token does and a browser session does not (API-L0-05; MAPI-03). Without that, every act a credential performs is indistinguishable from every other act of the account that minted it, and an automated publish running unattended reads in the record as the person doing it by hand. Telling the two apart is the one thing the record exists to be able to answer.
The record is readable and exportable by no served surface: it exists so that the platform's own operation has a durable account of what was done, not so that a customer or an operator can query one. Three readers inside the platform stand. Two join on the record's reference column under an account and near the call's time, because the reference is not unique across the record's retention (API-L0-19). The third reads a named action's completed calls inside a window of time. No served surface reads the record, and no export carries it.
The daily pass's feedback step answers two bits for a report's quoted reference, whether such a row stands and whether it records a refusal, and never a row, and marks the report at the issue service (PLD-L0-67). A filing's stamp reads the action, the outcome, the build, and the code site of the filer's own call, or of a call of a batch its token seeded (MAPI-18). The same step's exposure read answers each completed call of a fixed issue's action with its account, reference, instant, and build (PLD-L0-67).
Recording is never deferred to a reader's arrival, because a record that begins when a reader arrives is not a record, and it is buffered for at most one second. Every action's record is appended to the plane's meter buffer as the action completes and flushed to the action_records table within one second or two hundred rows, after the caller is answered. So a process end loses at most one flush interval of records, and no reader is ever the trigger (CQ-36). The table is monthly range partitions dropped after twenty-five months, every row carrying the environment.
A row the store refuses loses that row alone. A flush statement that fails twice is written again one row to a statement, and the rows the store refuses alone are dropped and reported once for the table in a flush, together with the table and their count. Two cases drop a failed statement's rows whole, reported, with no row written alone. One is a statement whose connection dropped after it was sent, because the store may already hold its rows. The other is a store the plane could not reach across its failover window or within a checkout, because a row-by-row write would wait that out once for each row (PLD-L0-67). A store lost inside the row-by-row write ends it, and the row it failed on and the rows not yet written are dropped and reported together, with their count, in a report apart from the rows refused alone.
The logging feature package (Q-226) owns the operational record once Turn Zero Cloud consumes it and the record writes through — raised in that package's PRD §5 — and this statement is re-parented to it then.
MAPI-07 (decided): A manifest change is the submit_manifest action on the application resource: validated against the manifest contract with refusals naming the failing path (MAN-12), applied as one deliberate action, recorded like every action (MAPI-06). Nothing else in the contract widens an application's declared reach, which is what ADM-L0-07's no-side-effect promise means here.
MAPI-08 (decided): The MCP tools are these actions, one to one and name for name: every tool of schemas/mcp_surface.json is an action of schemas/management_api.json at the same tier. Every action callable by AI clients is a tool — the browser-only actions are the one exception, absent from the tool surface by MAPI-05's restriction. The correspondence covers the call and not only the name: a tool declares the arguments its action accepts, derived from that action's request schema in schemas/action_payloads.json, so what a caller can express over the wire it can express as a tool.
One exception, on answers, owned by SEC-L0-07: an application's standing credential value is answered on the wire surface alone. So submit_manifest as a tool withholds its two value members and states credentials: withheld, and the two development re-mints of rotate_secret are refused as a tool, local_route_required, and answered on the wire. Those tools declare the same arguments as their actions, save a member marked x-wire-only, and the difference is in the answer alone. An exception to the listing rule, owned by MAPI-16: the two rows the enumeration marks switch: synthetic_estate are listed as tools while the synthetic estate's posture, the control plane's setting SYNTHETIC_ESTATE (MAPI-16), is not off. They are unlisted while it is off, their wire routes standing and refusing synthetic_estate_disabled by name.
An exception to the argument rule, owned by SCRT-L0-02 and CHI-L0-08 for a secret's value, by PLD-L0-86 for deploy's members, and by MAPI-23 for mint_token's: a tool declares no request member the schema marks x-wire-only, a member the HTTP action route alone carries. Those members are a secret's value, and three the turnzero-cloud command alone names: deploy's zip_sha256 and withdraw, and mint_token's code_verifier. A host may keep a tool call's arguments in its transcript, so store_secret and rotate_secret mark value and take it on the HTTP action route alone, under a bearer credential, a secret grant, or the browser session. Their tools take no value: a tool call naming a name of the caller's own is the preparing form the next paragraph states, save a store_secret call naming generate, the creating write SEC-L0-20 states, and rotate_secret's platform-minted names keep the answers above.
A store_secret or rotate_secret call that names a name of the caller's own and no value, and on store_secret no generate, is the preparing form (SEC-L0-19). It is answered through the tool and on the HTTP action route under the caller's own bearer credential, and under the browser session it is refused invalid_request. It writes nothing, mints a secret grant for the one write it names, and answers state as awaiting_value, expires_at, and the line that makes that write as command and command_windows (PLD-L0-94). A rotation's answer carries next, the restart_application call to make, where MAN-14 names one. The call may name value_file, the path the line reads the value from, which the tools declare, and a call naming it beside value is refused invalid_request. A tool call whose arguments carried a value is answered the same form with note, which says the platform neither read nor stored that value.
A store_secret call naming generate is no preparing form: it writes in the call on every surface and answers no value (SEC-L0-20). The store_secret tool declares generate, which carries no value, and the rotate_secret tool declares none. A tool call that carried a value and named generate is refused as SEC-L0-20 states, not answered the preparing form.
code_verifier is the exchange's one member, read on the HTTP action route where the token code form is served (MAPI-23). An MCP call of mint_token naming it is refused 409 local_route_required with nothing minted, read through the mark as deploy's handler reads its two, and a wire call naming it under any credential but a token code is refused 400 invalid_request.
This statement records the thirty-fourth use of MAPI-02's under-one-hundred-accounts clause, because it owns the argument derivation. The value member of store_secret's and rotate_secret's requests in schemas/action_payloads.json, until then declared by both tools, is marked x-wire-only and leaves both tool shapes, the HTTP route keeping it. The platform then held one builder account that held six live applications, synthetic accounts excluded, read through read_platform_usage under the operator's session at the change.
This statement records the forty-sixth use of MAPI-02's under-one-hundred-accounts clause, because it states the preparing form: store_secret's and rotate_secret's requests and responses in schemas/action_payloads.json. store_secret's value leaves the request's required list, and both requests gain value_file. Through the tool or on the HTTP route under the caller's own bearer credential, a call naming a name of the caller's own and no value writes nothing and answers the preparing form, in place of local_route_required and invalid_request. Both responses gain state, expires_at, command, command_windows, and note, and rotate_secret's gains next. The response members stored and rotated widen from the constant true to a boolean, false on the preparing answer. The descriptions in schemas/action_payloads.json, schemas/management_api.json, schemas/mcp_surface.json, schemas/skills.json, and schemas/wire_errors.json move with it. The platform then held one builder account that held six live applications, a synthetic account aside, read through list_accounts and read_platform_usage under the operator's session at the change.
The rows the enumeration marks grant: synthetic_estate (MAPI-09) are the synthetic estate's five (MAPI-16), the operator signal's (MAPI-17), and record_check (MAPI-18). Each is listed to a connection whose credential holds that grant or super_admin, or is bounded by a grant the row's admits mark names, and to no other connection. That listing is MCP-08's derivation from the enumeration's own mark under MAPI-09's rule that super_admin admits every grant-marked row. A connection whose token that grant bounds is listed the rows the grant marks, the rows the enumeration marks admits: ["synthetic_estate"], and the rows marked access: anonymous, and no other row (MCP-08; MAPI-16). An argument list authored beside that contract is a served form owning content, which CTX-03 forbids.
The suite holds the bijection and the argument derivation with it. So the MCP surface cannot grow a capability this contract lacks, nor this contract an AI-callable action the surface hides. Nor can a tool's action take an argument the tool cannot carry, save a member marked x-wire-only, which the wire alone carries.
MAPI-09 (decided): The super-admin's actions are enumeration rows like any other, marked grant: super_admin, the grant that exists only in Turn Zero's own accounts (ACB-L0-71), per credential and never by default. A row carries one grant mark. super_admin admits every grant-marked row whichever grant marks it: the dispatcher's grant gate admits a credential holding the row's grant or super_admin. The gate also admits a credential whose bounding grant the row's admits mark names (MAPI-16). A credential holding a narrower grant alone reaches, among the grant-marked rows, those marked with that grant, those whose admits mark names it where it bounds the credential, and no other.
The operator set that carries super_admin is the control plane's setting SUPER_ADMIN_IDENTITIES, comma-separated entries of the form <provider>:<subject>. The provider is one of the builder realm's two federated providers, google and github, and the subject is the provider's stable subject as the realm's identity row stores it, never an address. A process refuses its boot by name on an entry with no provider or no subject, a provider outside the two, or a subject carrying @. A release meets that refusal at its readiness step, the prior revision still active (PLD-L0-65).
The grant a session carries is read live and stored on no user or session row. Where a builder session, the dashboard cookie, or the browser action route resolves to a credential, the account's bound identities are read with the realm user's row. The credential carries super_admin where one of them is in the set. An entry removed from the setting therefore ends that grant at the next request. A token minted under super_admin keeps the grants its minting fixed (MAPI-14) until revoke_token ends it. So taking the entry out of the setting leaves the operator tokens the person's sessions minted working until each is revoked. The person's removal ends them in the same sitting, by revoke_token under a session of their own account or by suspend_account on it where that cannot be done (API-L0-12).
A reader that needs the operator accounts themselves, the catch-all purge (MAPI-16), the schedule-runs condition and the unlimited plan's signals (PLD-L0-83), and set_unlimited_plan (ACB-L0-85), resolves each entry to the account its identity has opened at each run. An entry whose identity has opened none resolves to none. The same value stands on every estate the register names (PLD-L0-85). A google entry names one person on each, the estates sharing one Google client (CRD-03), and a github entry admits only where the estate offers GitHub sign-in (CRD-02).
The inventory marked grant: super_admin is sixteen rows. They are enumerating accounts with standing, and reading one account's control-plane record, its standing, meters, and health, never its tenant data (ADM-L0-10). They are suspension with its reinstatement, revoke_product, the removal of one product profile from an account on suspension's pattern (API-L0-12; ACB-L0-76), and set_account_unbilled, the marking of an account unbilled, the company's own or a complimentary one, on the same pattern (ACB-L0-84). They are rotate_issue_space_token, re-minting a disclosed account space token on the same pattern (CRD-24; API-L0-12). They are set_egress_mode (EGW-L0-17; API-L0-12 as amended) and set_unlimited_plan (ACB-L0-85), the two marked rows whose subject is an application rather than an account. The grant widens the subject an operator credential may name to any account's application, set_unlimited_plan admitting an operator account's alone. What each row writes is the platform's own record, the enforcement posture or the plan, never the application's data.
The rows continue with the two control-plane reads of the logging service, read_control_plane_logs and read_control_plane_counters (LGS-L0-17), whose subject is the control plane's own record and no account. set_plan_quota is the company's act on the platform's served plan quantities on publish_library's pattern, naming no customer account (PRC-L0-16; API-L0-12 as amended). read_platform_usage is an enumeration across accounts on list_accounts's pattern (ACB-L0-79; API-L0-12 as amended). The operator status record's three rows are read_platform_status, the reading of the platform's own status document, record_incident, the hand-recorded incident, and set_status_setting, the record's served values (PLD-L0-76; PLD-L0-77; API-L0-12 as amended). Those three are the company's act on the platform's own record naming no customer account, on set_plan_quota's pattern.
The synthetic estate's five rows, seed_synthetic_accounts, purge_synthetic_accounts, read_synthetic_purge, read_synthetic_signin_code, and read_synthetic_account_state (MAPI-16), are the company's act on the company's own test fixtures, naming no customer account (ACB-L0-79). They are marked grant: synthetic_estate instead, the third grant beside the destructive class and super_admin, given on MAPI-14's terms. The operator signal's row, record_operator_signal, the act by which a company test harness reports a run's ending (MAPI-17), carries the same grant. So does record_check, the harness's posting of one run of a monitored check into the platform's own space, on the operator signal's pattern (MAPI-18).
Among the grant-marked rows the grant admits those seven alone, and it bounds the token that carries it. A minted token holding synthetic_estate and not super_admin is admitted to those seven rows, to the rows the enumeration marks admits: ["synthetic_estate"], and to the rows marked access: anonymous (MAPI-11), and is refused every other row of the account by name. A token minted with both grants is super_admin's and is bounded by nothing. What the narrow grant reaches within each row, what within them stays super_admin's alone, and the bound with its refusal, MAPI-16 states.
Publishing the system library, publish_library (API-L0-14), and publishing the public files, publish_public_files (PLD-L0-68), are each the company's own act on the company's own content naming no customer account at all. They are marked grant: publication instead, the fourth grant, given on MAPI-14's terms and bounding the token that carries it as MAPI-16 states. So the publisher's token, held on disk for those two acts alone (CRD-01), reaches them and the anonymous rows and no other row, where under super_admin it reached every row outside the destructive tier.
feedback_queue, the fifth grant, marks no row. It is given on MAPI-14's terms, bounds the token that carries it as MAPI-16 states, and widens two unmarked rows, read_feedback and settle_feedback (MAPI-18; API-L0-20), which carry it under admits, the grant decided at each handler. The settling of the platform's own queue is the company's act on the platform's own record of its friction, naming no customer account and reaching no customer's data. So a token holding the grant and not super_admin is admitted to those two rows and to the rows marked access: anonymous (MAPI-11). It is refused every other row by name, the grant gate answering first on a row another grant marks (MAPI-14).
Under the queue's grant the queue form, the whole read of any issue by its id, and the settling of an issue of the platform's own space answer, and the read with no member answers the operator account's own submissions (MAPI-18). With application, settle_feedback settles an issue of the acting account's own application space with no grant read (ITS-L0-03). issues, the sixth grant, is a space grant any session of the account gives for one space it holds (MAPI-14); it marks no row and bounds its token to the relay (MAPI-16).
The grant-marked rows are therefore twenty-five in all, a super_admin credential reaching all twenty-five, a synthetic_estate credential the seven, a publication credential the two, and a feedback_queue credential none, the grant marking no row. synthetic_seed_purge, the seventh grant, marks no row either: a credential it bounds reaches three of the estate's seven by their admits mark (MAPI-16).
Deleting a customer's account is not a further marked row. It is the same delete_account action through the same pending action (API-L0-07), the grant widening the subject an operator credential may name and nothing else: same API, same tiers, same record, which is API-L0-12's whole claim.
Administering the builder realm is not a further marked row either. issue_invitation called with no application member, revoke_invitation, application optional and invitation required, called with none, list_invitations, application optional, called with none, and configure_realm called with none address the builder realm (ACS-L0-08; ACS-L0-07). The four rows are unmarked, and that application-less form is admitted to a credential holding super_admin alone. It is refused by name to every other credential, and refused token_scope_refused to an application-bounded token, the form naming no application the token is bound to (API-L0-17). So the grant widens the subject an operator credential may name on an unmarked row, the builder realm in place of a realm of the caller's own application, exactly as it does on delete_account. The action record and the meter name the builder realm as the subject (MAPI-06).
The queue form of read_feedback, the read called with queue (MAPI-18), is the same pattern on a further unmarked row, the widening grant the queue's own. The form is admitted to a credential holding feedback_queue or super_admin. It is refused grant_required naming feedback_queue to every other credential that reaches the handler, and token_scope_refused to an application-bounded token, the scope gate answering ahead of the handler in MAPI-14's order. The read without queue answers every credential its own submissions. The read with issue answers a credential holding either grant any account's submission by its id and every other credential its own alone, another account's answered not_found. The super_admin-marked rows are sixteen, the synthetic_estate-marked rows seven, the publication-marked rows two, and no row carries feedback_queue, twenty-five grant-marked in all. A test in the platform's suite holds each count: sixteen, seven, two, none, and twenty-five.
MAPI-10 (decided): The wire surface is uniform and derived: every action is an HTTP endpoint at /api/v1/actions/<action_name> — POST for every tier, GET additionally for the observe tier — built from the enumeration at server start. A route therefore exists exactly when its action does, which is MAPI-01 enforced on the wire rather than reviewed onto it.
Every response carries the contract version (MAPI-02). Every refusal is the wire error shape at schemas/wire_error.schema.json. Its six base members are the version, a machine-readable error slug, the action where one is in question, a human detail, the reference the action dispatcher minted for the call (API-L0-19), and help, the address of the refusal's explanation. The reference is admitted and not required, as the action and the detail are, and it is carried by every refusal the action dispatcher answers to a dispatched call.
help is admitted and not required. It is carried by every refusal the action dispatcher answers to a dispatched call, and by the unknown_action, method_not_allowed, and not_yet_provisioned refusals the actions routes answer before dispatch. It holds the address of the refusal's row on the refusals page, <origin>/cloud/reference/refusals/#<refusal name>, on the estate's configured public origin (MCP-02). Where that origin is a loopback or an http one, the address is composed on the production origin instead, so a local run names the page production serves.
Beyond the base members, on the management action surface, a refusal carries exactly the members its row of schemas/wire_errors.json names under members (MAPI-15). Each is admitted and none is required, so a body that omits one stays valid. A member no row names for that refusal is a defect of the body or of the row. This is MAN-12's named-refusal discipline applied to the plane itself: a caller reads a violated path, a plan's floor, or a conflicting schedule as a typed member and never parses it out of the detail.
A grant is one such member, grant, named and described by the row of each refusal that answers it. Under grant_required it is the grant the action requires: a grant-marked row's own, super_admin (MAPI-09) on the application-less builder-realm form of the four unmarked rows, or feedback_queue on the queue form of read_feedback (MAPI-18). Under the other refusals it is the grant requested or held.
The schema file's member region, its declarations beyond the base six and its conditionals, is generated from the rows and never written apart from them. The file stays closed, declares every member any row names, and admits each under the refusals whose rows name it and under no other. The platform's suite holds the file equal to its generation from the rows, and holds every refusal the action dispatcher answers under test to the file.
Three rules hold on every surface a customer or a public caller reads, among them the router's and the egress gateway's own refusals, the version row's outcome read through list_versions, and a deletion walk's receipts read through read_pending_action. A refusal a thrown transport failure produced — Node's fetch failed, whose deciding fact rides the error's cause — carries in its detail the message with the cause's code alone beside it, fetch failed (ENOTFOUND). It never carries the cause's message, which can name an address inside the platform's network. A raw socket error is what http.request and https.request reject with, the router's application leg among them: its code is on the error itself with no cause, and its own message names the address the leg dialled. It carries a fixed sentence with that code alone beside it, the connection failed (ECONNREFUSED), and never its message.
A refusal the provider answered is a status the management plane, a storage account, or the registry returned. Its own message names the platform's subscription, a resource group, a request identifier, the registry's login server, or the provider's vocabulary. On those surfaces it carries a fixed sentence with the status word alone beside it, refused by the provider (http_403), or failed (error) where no status rode and no code of the transport's classifies, and never the provider's message. An operator diagnostic — a control-plane record, a run stamp, a command's standard error, the operator's own dashboard — carries the cause's code and message whole, a socket error's message whole, and the provider's message whole. So a lookup a network blocked, a certificate a firewall replaced, and a right the platform's identity lacks each read as what they are and never as an outage.
A thrown error whose transport code stands only along its cause, and whose own message is neither Node's fetch failed nor a raw socket error's, is the platform's own wrapper, its message composing an operator's text. On those surfaces it carries the fixed sentence with that code alone, the connection failed (ECONNRESET), and never its message.
A container provision the provider failed because pulling the application's image answered 429 or a 5xx status is a refusal the provider answered, its message naming the registry's storage host and the provider's vocabulary. On those surfaces it carries a fixed sentence naming the busy image registry with that status word alone beside it, The image registry was busy (http_503), and never the provider's message. The sentence says the fault is the platform's and transient, and names the act to call again.
An unknown action refuses as unknown_action, never a bare 404 page. A mutating action reached with GET refuses as method_not_allowed. An action whose implementation has not arrived refuses as not_yet_provisioned. MAPI-05's browser-only restriction is enforced at authentication, never by hiding the route.
This statement records the ninth use of MAPI-02's under-one-hundred-accounts clause, because it owns the wire error shape. The shape, a closed object of five members, the fifth the grant and given to one refusal alone, became the four base members and the members each refusal's row names. Twenty-nine rows named the members the platform already answered under them, and no answer changed. The platform then held two builder accounts that each held a live application: five live applications in all, four on the operator's account and one on the second account, read through list_accounts and read_platform_usage under the operator's session.
This statement records the fourteenth use of that clause. The reference, reference, became the fifth base member, admitted and not required, carried by every refusal the action dispatcher answers to a dispatched call. The schema file's base region and the generator's base-member list moved with it, and no row of schemas/wire_errors.json changed. The platform then held one builder account that held five live applications (read through list_accounts and read_platform_usage under the operator's session). Every later use of that clause that adds a member to a row, removes one, or changes the typing of a member's fragment (MAPI-15) is recorded here.
This statement records the thirty-second use of that clause. help became the sixth base member, admitted and not required, carried by every refusal the action dispatcher answers to a dispatched call and by the three refusals the actions routes answer before dispatch. The schema file's base region and the generator's base-member list moved with it, and no row of schemas/wire_errors.json changed. The platform then held one builder account that held six live applications, synthetic accounts excluded, read through list_accounts and read_platform_usage under the operator's session.
This statement records the forty-fourth use of that clause. The row account_outside_batches gained the member grant, admitted and not required, naming the synthetic grant that bounds the caller (MAPI-16). The purge's refusal carries it under either synthetic grant, so a synthetic_estate caller's answer gained the member too. A purge repeating another credential's request_id answers the row with grant and no accounts. The same change widened the grants enumeration of the token mint_token answers, and of each list_tokens row, with synthetic_seed_purge (MAPI-14). The platform then held one builder account and no synthetic account, read through list_accounts under the operator's session at the change.
This statement records the seventy-eighth use of that clause. The row declared_audience_contradicts_route lost its member routes and gained sign_in_methods, admitted and not required, the same array of the realm's configured sign-in methods under the realm member's new name (ACS-L0-07; MAPI-02). The refusal keeps its name (MAPI-15), the schema file's member region was generated again from the rows, and no other row's member changed. The platform then held one builder account and no standing synthetic account, read at the change.
MAPI-22: A call that names a member its action does not declare is refused by name, on every surface: the HTTP route, the tool surface, and the console. The refusal is invalid_request. So a caller that misnames a member is told which member it sent, and is never answered as if it had sent none.
What an action declares is the properties of its request in schemas/action_payloads.json. A request's root is closed. A nested object whose schema carries properties, empty or not, is closed too. A nested object that carries none is a map and admits any member, and an array's items follow the same rule. On the HTTP route a member of the query string counts as a member of the body. A caller's _origin is refused, that member being the plane's own.
The detail names what the caller sent and what the action takes. It names each undeclared member, a nested one by its path, and then every member declared at that place. It quotes at most five undeclared names and counts the rest. It quotes a name only where the name has a member's form, letters, digits, and underscores up to 64 characters. It never carries a value.
A member the contract replaced is answered with its successor. A request may carry x-renamed, a map from a member the request once declared to the declared member that took its place, and the detail then adds a sentence naming that member. A caller's guess gets no row. The four feedback requests carry the map for application and environment, which space replaced (MAPI-18), and their detail says which space a call naming none addresses.
A member the contract removed, with no member in its place, is answered with the reason. A request may carry x-retired, a map from a member the request once declared to a sentence that says why it is gone, and the detail then adds that sentence. submit_feedback's request carries the map for personal and excerpt: its sentence says that a report has no personal option, and that the caller files again without the member and leaves out what it does not want kept (MAPI-18).
The check stands in the dispatcher, behind its access gates. It runs after the refusal of text the plane cannot hold (PLD-L0-91) and after every access gate: the scope, grant, and bound gates, and the destructive class's (MAPI-12). So an access refusal keeps its name, and a credential the row does not admit is told no member names. It runs before a pending act is described, so a refused call creates none. Each surface hands the dispatcher the caller's member names and no value. A body that is not a JSON object is refused at the same place, in words that name no member. The replay of a stored input is not checked again.
On the tool surface the refusal answers before the argument layer validates the call. A single tool call that carries an undeclared member is handed to the dispatcher as the HTTP route hands a body. So a call that misnames a required member is answered with the member it sent, not with the member it lacks. A batch of calls keeps the argument layer's order, and a request the transport refuses for its headers keeps that refusal. The members the detail lists on this surface are the tool's arguments, a member marked x-wire-only left out (MAPI-08). One exception stands: a tool call whose only member outside the tool's arguments is marked x-wire-only keeps the answer MAPI-08 gives it. A call that also names an undeclared member is refused by name.
This statement records a use of MAPI-02's shape clause, the fiftieth: a call that named an undeclared member was answered, and is now refused. The platform then held one builder account that held six live applications, synthetic accounts excluded, read through list_accounts and read_platform_usage at the change.
The served-surface suite holds the rule for every action, on each surface that serves it.
MAPI-11: Action rows carry the access marking where MAPI-09 carries the grant marking. An action row marked anonymous answers without a session on the wire surface: the library’s inventory and content reads (LC-02), and the platform context catalog and content reads (CTX-07). Over MCP any connected identity reads it, since MCP-02 challenges a connection presenting none. An unmarked action answers as the connected identity behind the standard challenge (the 401 pointing at the protected-resource metadata, CQ-04's machinery).
The anonymous platform_context observe actions additionally retain a supplied valid, active bearer or minted credential, checking the required OAuth scope where that credential is OAuth-bound, for their credential-filtered view and attribution. On the wire an absent, invalid, suspended or insufficiently scoped credential reads the anonymous view. Over MCP a credential that resolves to an account without acting, suspended or unscoped, reads it, a message requiring an identity refused 403, and an absent or unresolved one draws the challenge (MCP-02). A resolved platform credential, end-user credential or transfer grant retains its named kind refusal. This optional-identity rule does not change the library HTTP routes.
The marking is the enumeration’s own member: the server derives its authentication gate from it, no surface keeps a hand-curated set beside it, and the suite holds every action to a marking-consistent gate (Q-239).
MAPI-12: The destructive class is granted by presence. A session credential minted by a person's own browser sign-in carries the destructive class from its minting — the sign-in is the explicit grant API-L0-06 requires. A minted token (API-L0-05) takes the class only at its own minting, from a session holding it (MAPI-14), and from nothing afterward. The application's platform credential (SEC-L0-07), the end-user credential the accounts service issues, the transfer grant object storage mints, the secret grant (SEC-L0-19), and the egress key (SEC-L0-18) hold no destructive class and can be granted none. A credential kind added later holds none until its own statement says otherwise (API-L0-06). The check runs where a destructive request arrives, before any pending action is created, and its refusal names the missing grant — a refusal distinct from the pending path, so an ungranted caller cannot fill a person's browser with approval requests.
A deploy code (PLD-L0-86) holds no destructive class and can be granted none. A token code (MAPI-23) holds none either and can be granted none; the token its exchange mints takes the class only as a minted token does, at the code's mint, from a session holding it.
MAPI-14: A minted token is created by mint_token (reversible tier), callable by the session credential alone — never by another token, the platform credential, or an anonymous caller — but for the fourteenth paragraph's exchange form, where that form is served. Or, for a synthetic account alone, it is minted by seed_synthetic_accounts through the same code path under a credential the seed's row admits: a session holding super_admin, or a minted token carrying synthetic_seed_purge, synthetic_estate, or super_admin (MAPI-09). So a harness holding a token carrying either synthetic grant mints the fixtures' tokens and no other (MAPI-16). Or it is minted by the code exchange of Turn Zero Blueprint's first-party client (MCP-02): one issues token at the owner level, for a space the signed-in account holds, under the label the request named.
mint_token names its scope (the account, or one application of it), an optional expiry, an optional label, and the grants requested. Where the token code form is served it takes an optional code_challenge, under which the call mints a token code in place of the token and answers no value, and an optional boolean authorized_computer, each as the fourteenth and sixteenth paragraphs and MAPI-23 state. The destructive class (MAPI-12's explicit grant) and super_admin (MAPI-09) are each given only where the minting session holds it and refused by name otherwise.
The five narrow grants are synthetic_seed_purge, synthetic_estate, publication, feedback_queue, and issues. synthetic_seed_purge is the one the seed, the purge, and the purge's read admit (MAPI-16), and synthetic_estate the one MAPI-09 marks the synthetic estate's rows with. publication is the one it marks the two publish rows with, feedback_queue the one read_feedback and settle_feedback admit (MAPI-18), and issues the space grant the next two paragraphs state. Each bounds the token that carries it to the reach MAPI-16 states. The first four are given only where the minting session holds super_admin and refused by name otherwise. At most one of the five is given to a token that takes no super_admin, a request naming two refused 400 invalid_request with nothing minted. None of super_admin and the five narrow grants is given to an application-bounded token (API-L0-17).
issues is given by any session of the account for one space the account holds, where the account holds the blueprint profile, the Blueprint license (ACB-L0-82). The request names the space in space, a lower-case UUID list_issue_spaces answers, the level in level, report, contribute, or owner, and a label, each required with the grant and refused invalid_request where absent; space or level without the grant is refused the same. The label names the holder in printable characters, and no unrevoked token of the account carries it for the same space, expired or not, until the daily pass deletes the row (PLD-L0-67). A duplicate or a non-printable label refuses invalid_request, and the level is not capped by the space's kind. The relay names the acting actor as the account's identifier qualified by the label (the issue service PRD's relay row).
Without the grant, a space naming a space the account does not hold is refused space_not_owned ahead of the form, the identifier judged before the form as every identifier is (VER-11).
The exchange's mint records on the token the client it was issued to, which no answer carries. In the same act it revokes each unrevoked token of that account, space, and label that the same client was issued. So a clone's earlier token is replaced, and no other token is. Where another token carries the label in that space, one mint_token minted or one another client was issued, the exchange is refused 409 label_in_use with nothing minted or revoked, and the confirm page MCP-02 states refuses that space by the same name. mint_token keeps refusing a label an unrevoked token of the space carries, whatever minted it. label_in_use is this statement's row of schemas/wire_errors.json (MAPI-15).
A space the account does not hold is refused 403 space_not_owned naming the space, whatever the session holds. That is another account's space, an unknown one, the platform's own space to every account but the one the plane names its owner, and an application's space until a binding records it (the issue service PRD's relay row). space_not_owned is this statement's row of schemas/wire_errors.json (MAPI-15), answering the mint, the relay, and create_issue_space under one name.
The license is read once the owner is judged. An account that lacks the blueprint profile is refused 403 blueprint_required with nothing minted, whatever the space's kind. The relay reads the same profile on each call, and create_issue_space reads it before it creates anything (the issue service PRD's relay and provisioning rows). blueprint_required is ACB-L0-82's row of schemas/wire_errors.json (MAPI-15).
The answer carries the value exactly once beside the token's identity, but for a mint naming code_challenge, which answers no value. Its token member then carries the properties the exchange mints with and no identity, and the exchange's answer carries the identity and the value once (MAPI-23). The store holds the value's hash, the scope, the grants, the label, the revocation, and the authorized computer's marker, never the value. It holds the three stamps — the minting, the expiry, and the last use, which the credential seam writes as it resolves a presented value — and a space grant's space and level.
revoke_token (reversible) ends one token by its identity, and list_tokens (observe) answers identities, scopes, grants, labels, a space grant's space and level, and all three stamps, the last use among them, never values, and mint_token answers that same shape for the token it mints. Where the token code form is served, list_tokens also answers authorized_computer, true on an authorized computer's token and false on every other. revoke_token is idempotent: a repeat answers the row with its first revocation stamp. Once the daily pass has deleted the row, after the retention PLD-L0-67 states, list_tokens lists it no more and revoke_token naming it answers not_found.
mint_token and revoke_token each write one line into the control plane's own diagnostics (system:LGS-L0-16) carrying the token's identity, its scope, its grants, its label, and its expiry, and never the value. The fixtures seed_synthetic_accounts mints through the same code path write none, as do the sweeps an application's deletion and an account's erasure run, and the ends of the exchange's tokens MCP-02 states, each being another act's. The exchange's end of a token it minted while the generation moved writes revoke_token's line. The operational record answers no reader (MAPI-06), so that line is where an operator reads what was minted under an account and when it ended. The exchange's mint writes the same line, naming the client and the tokens its act revoked.
A revoked or expired token is refused at once on the management surface and the MCP endpoint, and on the storage, egress, and logging wires at the gateways' next read past their cache interval (PLD-L0-67). A stored token whose grants name one outside the grants the running build serves resolves to no credential, refused authentication_required as an absent credential is. So a build that predates a narrow grant never serves that grant's token unbounded. A minted token renews nothing — it is replaced by minting another — and its grants admit nothing its minting session's grants did not admit (MAPI-09). Every action a token performs is recorded under the token's own identity (MAPI-06): a credential identity on the record beside the kind, empty where the credential has none.
Its refusals run in one order, each named and none creating a pending action. The scope comes first (API-L0-17). Then, on a row whose implementation has not arrived, comes not_yet_provisioned (MAPI-10). Then comes the grant (MAPI-09), under which a grant-marked row that does not admit the token keeps grant_required with the row's own grant. Then comes the bound of a token a narrow grant bounds, synthetic_seed_purge_bounded, synthetic_estate_bounded, publication_bounded, feedback_queue_bounded, or issues_bounded by the grant (MAPI-16). The destructive class comes last (MAPI-12).
This paragraph states the exchange, the first paragraph's one exception, served only where the plane's environment holds TOKEN_CODE_FORM with the value on, a name no template declares and no estate holds (MAPI-23). The exchange is mint_token on the HTTP action route whose bearer is a token code the session's own call minted and whose body is code_verifier alone. It mints the token from the code's row, with every property that call named, and answers the value once. Where the form is not served, a call naming code_challenge, code_verifier, or authorized_computer is refused 400 invalid_request naming each as not served on this estate, nothing minted, and every other answer is the one this contract states for a call naming none of them.
The code's mint runs every refusal of this statement's mint before it mints, the label rule read from the account's token rows before anything is written, so a taken label is refused in this statement's words and no code is minted. A state arisen since the mint, an application, a space, or the Blueprint licence no longer held, or the label taken, is answered at the exchange by this statement's own named refusal for it, the code spent and nothing minted (MAPI-23).
authorized_computer, an optional boolean of the same form, marks the token of an authorized computer, the one the turnzero-cloud command presents from the computer whose challenge the call names. A marked mint names a challenge, since the token's value is answered to no call, is account-scoped, and lives at most 30 days, 30 where expires_in_days is absent. A marked mint naming no challenge, scope_kind application, or expires_in_days above 30 is refused 400 invalid_request with nothing minted, the cap a refusal and never a clamp. The exchange writes the marker on the token's row, and revoke_token ends the token as it ends any.
Where the token code form is served, a mint naming code_challenge writes one line into the control plane's own diagnostics naming the code's identifier, the session's kind, the scope, the grants, the label, the marker, and the code's expiry, and no value. The exchange writes mint_token's line for the token it mints, naming the code's identifier beside the token's (MAPI-23).
MAPI-23: The token code is a one-time grant mint_token mints in place of a token where the call names code_challenge, admitted once at mint_token's wire exchange form, where the exchange mints the token from the code's row. The plane serves the token code form where its environment holds TOKEN_CODE_FORM with the value on, a name no template declares and no estate holds. Where it does not, a mint_token call naming code_challenge, code_verifier, or authorized_computer is refused 400 invalid_request naming each as not served on this estate, nothing minted. Every other answer, list_tokens's among them, is the one this contract states for a call naming none of them.
Whatever the switch, the served descriptions carry the form's three members and mint_token's tool argument list its two, code_challenge and authorized_computer, each saying it is answered only where the form is served. The served value token_code_seconds (PLD-L0-76) and the daily pass's step token_codes_purged (PLD-L0-67) are served whatever the switch.
Under a session credential, a call naming code_challenge, 43 base64url characters, the S256 challenge of a verifier the caller's turnzero-cloud command holds, runs every refusal of the mint and then mints one code in place of the token (MAPI-14). The space grant's label rule is read from the account's token rows before anything is written, so a taken label is refused in the mint's own words and no code is minted. A challenge of another form is refused 400 invalid_request, nothing minted. The call answers 200 with the state awaiting_command, command, command_windows, expires_at, the code's, token, and detail, and no value. token carries every property the exchange mints with, scope_kind, application, grants, label, expires_at, authorized_computer, and an issues token's space and level, and no id or stamps. The token's expiry is fixed at the mint, from the days the call named.
command is one line that pipes the code to the turnzero-cloud command on its standard input, in none of its arguments, in one of two forms: an authorized computer's where the call marked one, and every other mint's. It names the pinned version on the estate's configured origin, never a host a request names, and adds --origin <origin> where that origin is not the command's default. command_windows carries the line's Windows form (PLD-L0-94). The detail says the line is a credential until expires_at, to run once, as given, and paste into nothing but the terminal that runs it. It says who runs it: a tool runs the first form, and the person runs the second, in a terminal outside the AI tool and never by a tool.
A token code is a grant of a kind of its own, the fourth beside the transfer grant, the secret grant, and the deploy code, and its value has a grant's form (MAPI-03). Its record kind, on the action record, the authorization matrix, and the credential-surface census, is token_code. The plane stores it by its SHA-256 alone, in the control database's token_codes table (PLD-L0-67). Its row records the account, the minting session's kind and row key, which no record, answer, or log line carries, the challenge, every property the mint named, and the marker. It also records the token's expiry, the code's creation and expiry, the instant and manner of its end, and the token it minted.
A code lasts the served token_code_seconds, 300 seconds by default and held between 30 and 300 (PLD-L0-76), and never past the minting session's row's expiry. A later mint by the same session under the same label ends that session's unspent codes of the label.
The exchange is mint_token on the HTTP action route with the code as its bearer and the body code_verifier and no other member. There the dispatcher's kind gate looks the code up and spends it by one compare-and-set bounded by its expiry, ahead of every refusal of its own and ahead of the verifier's match. So every presentation there of a code the plane holds unspent spends it, whatever the call then answers, and two presentations of one code are admitted once.
The plane mints the token where the verifier's S256 challenge is the recorded challenge, the account is not suspended, and the minting session's own row stands unrevoked, unexpired, and not behind its account's generation. That one read covers a sign-out everywhere, a revoke_connection, a device's sign-out, a passkey change's revert, and the session's expiry. It also reads again what the mint read: an application-scoped code's application, and an issues code's space, Blueprint licence, and label. Where the account no longer holds the application, the space, or the licence, or an unrevoked token has taken the label since the mint, the exchange answers the standing mint's refusal, no_such_application, space_not_owned, blueprint_required, or invalid_request, the code spent and nothing minted. A fault reading the space is answered as the standing mint answers it, and any other fault is the dispatcher's internal failure.
It mints with the recorded properties and the marker, writes the token's identity on the code's row, and answers 200 with token, the identity beside the same shape, and value, to that one caller, and no later read shows the value.
One refusal answers every other state: 403 token_code_refused, alike in name, status, and detail, each answer carrying its own reference (MAPI-10). The states are an unknown, spent, expired, or ended code; a body naming more than the verifier; an unmatched verifier, or one outside its form; and a code of a suspended account or an ended session. So is a bearer of a grant's form that resolves to nothing there. A mismatch, or a verifier outside its form, spends the code, so a copy presented without the verifier mints nothing, and the person's own line is then refused and told to call mint_token again. The detail says the code cannot be used, being unknown, expired, or already presented, its verifier unmatched, or its session ended, that nothing was minted, and the remedy. token_code_refused is this statement's row of schemas/wire_errors.json (MAPI-15).
Every presentation at the exchange form counts in its source's admission window ahead of the lookup, whether or not the plane holds the code (PLD-L0-67), so the gate's 429 rate_capped alone precedes the spend and leaves a found code unspent. A transfer grant, a secret grant, or a deploy code presented there is answered as MAPI-03 and PLD-L0-86 state and stays unspent. Elsewhere a code is no credential: on every other management action, on mint_token's other forms, on the MCP surface, and on the storage and egress wires it is answered as a value of a grant's form that resolves to no credential is (MAPI-03), unspent. code_verifier is a wire-only member (MAPI-08): an MCP call naming it is refused 409 local_route_required, and a wire call naming it under any credential but a token code 400 invalid_request, nothing minted. A token code holds no destructive class (MAPI-12).
A code ends with its one presentation, its expiry, a later mint_token by the same session under the same label, and the account's sign_out_everywhere, a passkey change's revert, and suspension; the account's erasure removes the rows (PLD-L0-66). A revoke_connection, a device's sign-out, and the session's expiry write no end on the code: the exchange refuses such a code by its read of the session's row. A reinstatement brings no ended code back. The daily pass's step token_codes_purged deletes each code a day past its expiry (PLD-L0-67).
The mint's action record names the session's kind and the code's identifier and holds no part of the answer. The exchange's record is attributed to the owning account with the code's kind and identifier, and names the token minted. A refused presentation of a code the plane holds is recorded against its identifier, and one of a value it does not hold with no value. The mint and the exchange each write one control-plane line, the mint's naming the code's identifier and the exchange's the token's and the code's (MAPI-14). No code, verifier, or token value stands in any record, event, or log line, and no hash of a refused value is logged (system:SCRT-L0-02); the challenge may stand on the code's row, since it is public.
At the launch population (PLD-L0-74) the token_codes table holds about a day's mints, tens of thousands of rows, and minted_tokens gains one live row per authorized computer and origin, about 900,000 rows inside the thirty-day retention at 300,000 accounts. The marker is one nullable column with no index, read as a token is read today. The pass's delete reads expires_at, which no index serves, an index owed at the next order.
MAPI-19: The connection resource is a signed-in tool's OAuth 2.1 refresh family (API-L0-21; MCP-10), one per sign-in a registered client completed, and the account grain holds its two actions. list_connections (observe) answers the acting account's live connections. Each row is its identity, its client, the instant of the sign-in that opened it, its last renewal or null, and its expiry, and never a credential value or hash. The listing is idempotent and answers GET as every observe row does (MAPI-10). revoke_connection (reversible) ends the connection its id names: the family's refresh credentials are deleted and its access-token session rows revoked, so the tool is refused at once on the management surface, the MCP endpoint, and the wires alike. It touches no other connection, cookie, or minted token. An id no live family of the acting account carries is refused 404 not_found, another account's among them.
Both rows are callable by the session credential and by the browser session (MAPI-03; MAPI-05), the Account page's connections section being their one page (WEB-L0-21), and by a minted token as MAPI-03 admits an account act. Neither is grant-marked (MAPI-09). Each end writes one line into the control plane's own diagnostics carrying the account, the client, and the family, never a token (system:LGS-L0-16). The row sign_out_everywhere (reversible), on the account resource under the same callers and no grant mark, ends every session and every connection of the account at once and answers sessions_ended, refresh_rows_deleted, and exchange_tokens_revoked. The last counts the tokens Turn Zero Blueprint's exchange issued the account that it ended (MCP-02; ACS-L0-18). The site's Sign out ends that browser's session alone.
MAPI-15: The refusal names are enumerated. Every refusal name a surface of the plane answers is listed once in schemas/wire_errors.json beside this document. Each row carries the surfaces that answer it, the HTTP status where one status is fixed across every site, and the statement that owns the behaviour. It also carries one clause saying when it is answered and one clause saying what the caller does next, the row's remedy, written by the change that adds the row. The surfaces are the management actions on their routes and through the tools that surface them (MAPI-08), and the MCP server's own challenge. The others are these:
- object storage;
- the egress gateway;
- the push service's send route;
- the accounts service's realm surface;
- the builder sign-in;
- the serving router;
- the deploy command's progress read, the catalogue's deploy_progress (PLD-L0-86).
Four more surfaces answer names of the list: the egress tunnel seat (egress_tunnel), the logging ingest (logging), the runner harness inside every application container (harness), and the documentation trees' machine files (documentation).
Where the refusal's body on the management action surface carries members beyond the six base members (MAPI-10), the row carries a members object giving each member's name a JSON Schema fragment that types and describes it. The published refusals page reads both clauses and the members from the row and derives none of them. Each clause is written in sentences of fewer than 45 words, because the page carries them as table cells under the documentation's prose bound, a member's description held to the same bound for the same reason.
A row's members state the body the management action surface answers and nothing of another surface's body under the same name, so a row that does not name that surface carries none. The rows and the schema generated from them state the management action surface's refusal bodies alone. The body another surface answers under a name of this list is that surface's owning statement's to state, in the shape the surface answers, and no row, schema, or description of this catalogue holds it to the management action surface's shape.
The rows are the members' one home. A fragment uses type, items, properties, pattern, and description alone, through its nested fragments, and never an enumeration, a constant, a format, or a required list. It never uses them because a closed vocabulary in a fragment would make every later value a change of the body's shape and because every member is admitted and none required. A member that may be null says so in its type, and a nested object declares the properties the platform answers and stays open.
The list is derived from nothing and reviewed onto nothing. A test in the platform's suite extracts the names from the source by the call forms the surfaces use to put a name on the wire and holds the two sets equal. So a name the source answers that the list lacks, and a row the source no longer answers, each fail the suite. A name absent from the list is a defect in the change that added it, closed by adding the row in the same change, never by excluding a real wire form from extraction. When the implementation introduces another way to carry a refusal name on the wire, the extractor covers that form and the catalogue gains any new names in the same change.
The JSON body shape stays MAPI-10's (schemas/wire_error.schema.json), whose member region is generated from the rows' members. The suite holds each row's members to this form and each declared member's name to a key the platform source writes at a site that builds that refusal's body. So a member the rows declare and no site of that refusal still writes fails it, as a row the source no longer answers does. This catalogue includes the JSON error member's values and standard OAuth error parameters in WWW-Authenticate challenge headers and authorization redirects; it does not impose the JSON body shape on those standard protocol fields. This is MAN-12's named-refusal discipline made a check. Within a contract version the list grows and never shrinks: retiring a name is a new contract version (MAPI-02).
One case stands beside that rule while MAPI-02's under-one-hundred-accounts clause stands. A name the source stops answering because its cause has left the platform may leave the list within version 1, recorded as MAPI-02 records a use of that clause, with the account count read at the change.
The members' evolution is MAPI-02's and no rule of this statement's own. While its under-one-hundred-accounts clause stands, a member added to a row, a member removed from one, and a fragment's typing changed, its type, items, properties, or pattern, are each a change of the body's shape, recorded by MAPI-10 as a use of that clause. A description's wording is a content change that moves the version and no use. Once it lapses, a member added is a new optional field, and a member removed or a fragment's typing narrowed is a new contract version.
MAPI-13: The running build states its identity on the health read. The artifact carries a build stamp written at bundle time — the source commit, whether the tree was dirty, and the build instant — as a stamp file beside the bundle. GET /healthz answers it as build beside MAPI-02's contract_version. Beside the stamp's three members, build carries bundle_hash, the SHA-256 of what the process's image copies: the one bundle file for the serving router and the tunnel seat, and for the plane the dist/ tree its image copies whole. For that tree the hash reads every file under the folder holding the bundle, each relative path joined with /, the paths sorted by bytes, each path then its file's bytes fed to one hash, build.json and the bundle's source map excluded.
bundle_hash is read at the process's boot from the file it runs as harness_hash is, and it is null where the process does not run from its image's file. Beside build, /healthz answers harness_hash, the SHA-256 of the runner harness bundle beside the running bundle, the harness the platform bakes into every application image it builds (PLD-L0-63). A source tree with no stamp answers null members, never an invented value, and a process with no harness bundle beside it answers harness_hash null the same way.
The identity answers on that one anonymous read rather than riding every exchange. It also answers on two aliases the edge's standing routes carry to the services its default route does not reach: GET /accounts/v0/healthz on the accounts mount set and GET /logging/v0/healthz on the gateways mount set. Each answers the body /healthz answers, read through the edge under the origin lock's check where /healthz itself is exempt (PLD-L0-67). So two builds of one contract are distinguishable to any caller at the cost of one call, and a deploy's completion is the served identity changing to the deployed commit (PLD-L0-65; the handshake SVC-L0-11 asks of a customer's backend, kept by the plane itself).
The build also states its readiness on GET /readyz: one statement per database pool the process holds. It answers 200 with ready true, pools naming each pool with ok, and unapplied 0, or 503 with ready false, pools naming the pool that failed, unapplied counting the migration files the ledger lacks, and detail. The answer carries them beside MAPI-02's contract_version and build, the member /healthz answers, so the one readiness read carries the process's identity.
On the accounts mount set the answer also carries realm_keys, ready once the realm key-encryption key is unwrapped (SEC-L0-07). On a process mounting the gateways set alone, a control pool whose statement failed while the credential cache holds an entry within its stale ceiling answers 200 with ready true, that pool failed in pools, and serving_stale true. The wires answer from the held entries (PLD-L0-67's cache rule), and every other failed statement refuses as stated. A process holding no pool answers ready with an empty pools.
On a build that mounts the gateways set, GET /healthz also answers caches: for each gateway cache, credential and rows (PLD-L0-67), the positive and negative entries held and the hits, misses, and stale serves counted since the process started, read from the process alone. The health read stays the identity read and touches no store, so a host's liveness probe and its readiness probe ask different questions (PLD-L0-67).
The process binds its listener before it builds its routes. A connection attempted before the bind is refused at the socket. A request accepted after the bind and before startup completes, a liveness or readiness probe included, is held unanswered until the routes are built and the pre-serve work the entry runs for its mount set has completed (PLD-L0-67). That work is the timers' start and, on the management set, the first sweeps; the request is then served by the built application. Where that work fails after the bind, no held request is answered, each held connection is destroyed, the listener closes, and the startup call fails with the error, which ends the executable's entry.
MAPI-16: The synthetic estate is five grant-marked rows of the enumeration under grant: synthetic_estate (MAPI-09): seed_synthetic_accounts (reversible), purge_synthetic_accounts (reversible), read_synthetic_purge (observe), read_synthetic_signin_code (observe), and read_synthetic_account_state (observe). Its grant is a third grant beside the destructive class and super_admin, minted on MAPI-14's terms, the grant the compat harness's and the live tests' tokens carry. The estate is the company's own act on the company's own test fixtures, naming no customer account (the synthetic account kind the accounts and billing PRD states; API-L0-12).
The grant bounds the token that carries it, at the platform's two seams. So does publication, the fourth grant, which marks the two publish rows, publish_library and publish_public_files (MAPI-09). It is minted on MAPI-14's terms, the one grant the publisher's token carries (CRD-01). So does feedback_queue, the fifth, which marks no row and is the one grant read_feedback and settle_feedback name under admits (MAPI-18), the one grant the feedback queue's triage token carries. So does issues, the sixth, a space grant any session of the account gives for one space it holds (MAPI-14), which marks no row and is admitted on list_tokens and relay_issue_act. So does synthetic_seed_purge, the seventh, a staff grant minted on MAPI-14's terms, which marks no row and is named under admits on three of the estate's rows. The five are the bounding grants.
A minted token whose grants hold one of them and not super_admin is bounded by it exactly as this statement states for synthetic_estate. It is admitted the rows its grant marks, the rows the enumeration marks admits with its grant's name, and the rows marked access: anonymous. It is refused every other row under the grant's own name, synthetic_seed_purge_bounded for the hosted trial's, publication_bounded for the publisher's, feedback_queue_bounded for the triage token's, and issues_bounded for a token the space grant bounds, the refusal's members the same.
A mint gives a token that takes no super_admin at most one of the bounding grants, and a request naming two is refused 400 invalid_request with nothing minted (MAPI-14). So no token carries two bounds. A stored row that did would be bounded by the first of them in the order the predicate reads them, synthetic_seed_purge, then synthetic_estate, then publication, then feedback_queue, then issues, its reach the narrower for it. synthetic_seed_purge stands first because its three rows are among the estate's, so a row naming both meets the three alone. No row of the enumeration marks admits with publication, so the publisher's token reaches its two rows and the anonymous rows and no other, list_tokens and read_account among the refused.
The triage token reaches settle_feedback, read_feedback in every form, and the anonymous rows and no other, submit_feedback, list_tokens, and read_account among the refused. So a report it reads can turn it to no filing and to no act beyond the queue. A token the space grant bounds reaches relay_issue_act for the one space its grant names, list_tokens, and the anonymous rows and no other, the space and the level judged at the relay's handler (the issue service PRD's relay row). An act above its level is refused issues_level_refused naming the level and the acts it admits, so a token a teammate's clone or a build step holds reaches one space of its account at one level and nothing else.
On the management surface, a minted token whose grants hold synthetic_estate and not super_admin is admitted to those five rows: the purge for the batches the caller's own credential seeded, and the code read and the state read for accounts in those batches. It is admitted to the operator signal's row and to record_check, the two other rows the enumeration marks with the grant (MAPI-17; MAPI-18).
It is admitted to the rows the enumeration marks admits: ["synthetic_estate"], two rows, nine rows in all with the seven above. One is list_tokens, the observe read under which every consumer of such a token finds its own row's expiry. The other is submit_feedback, the filing of a report into the company's own space of the issue service (MAPI-18). That filing names no customer account and reaches no customer's data, the ground the operator signal's row stands on (MAPI-17), so a company harness files its findings under the token it already holds. Such a filing may cite the reference of a call an account of a batch that credential seeded made, the stamp and the daily pass's join reading under that account (MAPI-18; PLD-L0-67).
The token is also admitted to the rows marked access: anonymous (MAPI-11), which lie outside the bound and answer a bounded token as they answer every connection, the credential-filtered view where MAPI-11 gives one. Every other row refuses it 403 synthetic_estate_bounded, read_documentation among them, which carries no anonymous mark. The exception is where a refusal that answers every credential ahead of the bound answers it first. A browser-only row's browser_session_required (MAPI-05) and not_yet_provisioned on a row whose implementation has not arrived (MAPI-10) are among those refusals. The bound's refusal carries a grant member naming the bounding grant. Its admitted member names the rows the grant and the admits mark admit, the anonymous rows outside the bound and named in the row's clause.
A minted token whose grants hold synthetic_seed_purge and not super_admin is the hosted trial job's credential. Three rows carry admits: ["synthetic_seed_purge"] beside grant: synthetic_estate: seed_synthetic_accounts, purge_synthetic_accounts, and read_synthetic_purge. The token is admitted to those three and to the rows marked access: anonymous, and to no other row. A grant-marked row that does not admit it answers 403 grant_required naming the row's own grant: read_synthetic_signin_code, read_synthetic_account_state, the operator signal's row, record_check, and every row super_admin or publication marks. Every unmarked row answers 403 synthetic_seed_purge_bounded, list_tokens, submit_feedback, and read_account among them, save where a refusal that answers every credential ahead of the bound answers first. So under this token a disclosed copy writes no operator-signal line, posts no check, files no report, reads no sign-in code, no account's state, and no token row, and reaches no customer account.
Under that grant a seed is bounded below every posture: one account for each call, a token of at most one day, and no products. A seed past a bound is refused 403 synthetic_posture_refuses naming the bound and the grant. A batch seeded under it expires with its account's token, where the posture's lifetime is longer, so the lifetime sweep purges an account a trial left standing after one day. The purge refuses all: true and an account outside the caller's own batches, as under synthetic_estate. read_synthetic_purge answers only a purge every account of which lies in a batch the caller's own credential seeded, and any other identifier as it answers an unknown one.
Under that grant a repeat is answered only where the batch or the purge is the caller's own. A seed repeating another credential's request_id is refused 400 invalid_request, and a purge doing so 409 account_outside_batches. Under synthetic_estate the read and both repeats answer every caller, the harness's tokens sharing one operator account. The token's own row stands in its owner's list_tokens answer, which the token itself does not read.
The admits mark is the enumeration's own member on MAPI-11's pattern, this statement's to own. The bound's gate runs after the grant gate, under which a grant-marked row that does not admit the token keeps grant_required, and before the destructive-class gate (MAPI-14). The grant gate admits a token on a grant-marked row where it holds the row's grant or super_admin, or where the row's admits mark names the grant that bounds it (MAPI-09). One exported predicate over the enumeration's three marks, the grant, the admits mark, and the access mark, serves the gate, the MCP listing (MCP-08), and the admitted member, no list kept beside the enumeration (MAPI-11). One exported predicate likewise decides the grant gate and the listing's grant rule, reading the token's bound and never another grant it holds.
On the data planes the bounded token reaches no declaration of the account. Object storage refuses it 403 area_scope_refused on a route of a declared area and at a minting request the route would otherwise admit. The egress gateway refuses it 403 upstream_scope_refused on a call naming a declared upstream. The refusals that answer ahead of each surface's reach rule answer it as they answer any account-wide credential. With those and the two scope refusals, neither surface serves it. The two refusals carry the bodies those surfaces' owning statements state (OST-L0-03; EGW-L0-08). So every consumer of the estate presents the seeded account's own token on the data planes and never the grant-carrying one. The same two refusals answer the hosted trial's token, the publisher's token, the triage token, and a token the space grant bounds, whose acts are management actions alone.
A token minted with a bounding grant and super_admin is super_admin's and is bounded by nothing (MAPI-09). And all: true on the purge, the purge of a batch another credential seeded, and the code read and the state read for any synthetic account are super_admin's (MAPI-09).
The seed takes count (1 to 100), an optional label_prefix (synthetic- by default), the required token_expires_in_days (1 to 3650), an optional request_id, refused invalid_request where it opens the reserved first-sign-in: (below), an optional sign_in, and an optional products. The last is the product profiles each account holds beside cloud on the invitation member's vocabulary (ACB-L0-79; ACB-L0-77), ["cloud"] where absent. The seed creates count synthetic accounts and mints one account-scoped token per account through mint_token's own code path: no grant, the given expiry, the label <label_prefix><n>. It answers each token value exactly once, as mint_token does (API-L0-05). It writes one action record per created account and per minted token naming the calling credential, the operator's session or the harness's token (MAPI-06). The tokens are ordinary minted tokens, shown by list_tokens and ended by revoke_token.
Every seed, one without request_id too, records a batch under a server-minted identity answered as batch. The batch row carries the expiry instant fixed at seeding, swept_at, and the nullable seeding_credential, a minted token's identity and null for a session seed. The expiry instant is the posture's account lifetime from the seeding instant, so a posture change moves new seeds alone and a stress expiry never turns twenty-one days into three mid-test. With sign_in: true the seed binds, per account, the second identity ACB-L0-79 states — the email identity at the reserved fixture domain synthetic.turnzero.ai — in the seed's own transaction beside the synthetic identity, and the answer carries, per account, email.
A repeat carrying the same request_id from the same operator's account answers the same batch's identity, account ids, labels, and, where the seed carried sign_in: true, each account's email, without token values. The repeat creates nothing, so a retried call never double-creates, and a batch whose values were lost is purged and seeded again.
The purge takes accounts (account ids) or all: true, an optional request_id, and an optional drop_metering. Where any named id is a standing account that is not synthetic, the purge refuses the whole request 409 account_not_synthetic and deletes nothing. Under either synthetic grant alone it admits an account only where its batch's seeding_credential equals the caller's own identity, refusing the whole request 409 account_outside_batches otherwise. That refusal names the grant that bounds the caller, and so does the refusal of all: true where the posture admits all: true. Under synthetic_seed_purge the scoping is read first, so an id outside the caller's batches answers account_outside_batches whatever account it names. So an account no batch names, a batch a session seeded, and a batch another credential seeded are purgeable under super_admin alone.
Where neither refusal answers, the purge runs, per account, the deletion walk delete_application runs after approval for each of the account's applications, and then the account's own removal as delete_account runs it, its tokens revoked (ACB-L0-47; PLD-L0-66). The application walk covers compute, databases, realms with their passkeys and invitations, bound areas with every partition, secrets, platform credentials, version rows and images, and logs and schedule rows, and it retires the hostnames. After an account's walk returns, the purge deletes the sign-in codes the emailed-code route holds under the account (ACS-L0-12). The purge is reversible tier and never a pending action, decided here. The accounts are the company's own test fixtures holding no customer data, on set_plan_quota's and publish_library's pattern (MAPI-09). MCP-07 rules out the alternative, a tool that approves a pending action.
The purge takes deploy's shape (MAPI-04): it answers 202 at once with the purge's id, the state running, and the accounts. It answers instead the state completed at once where the call named nothing to walk, every named account joined to another purge or all: true naming no account. read_synthetic_purge { purge } answers the purge's state and, per account, the state and the receipts the walk wrote.
A second purge naming an account a running purge already holds joins that purge. The account is walked once and its state read from either purge, the joining purge's own state covering the accounts it walked itself. A unique index over the live account rows holds the join across replicas. A joining purge that asked the metering drop raises the walking purge's own drop_metering, which its runner reads again before each walk. So the walking purge drops the metering for every account it walks after the join. An account whose walk was in flight at the join may keep its rows until a repeat purge under drop_metering: true.
An account already gone completes with zero removals, so a repeat purge of purged ids is a no-op. A walk that stops at a failing member ends the account failed with the error and the receipts written before the failing member (the estate receipts, the application receipts, and the failing member's name). A repeat purge naming that account runs the walk again, every member idempotent.
A purge interrupted by a platform restart ends failed with the outcome interrupted under the rule deploys follow, and a repeat converges. Under that rule the shutdown handler finishes the runs the process holds. An account whose walk was in flight at the interruption still ends completed with its receipts where the walk returns. A sweep on the stale-deploying sweep's cadence finishes a running purge whose heartbeat is older than the deploy's stale bound. A store failure of the runner's own ends the purge failed with the outcome runner_failed. A repeat carrying the same request_id answers the same purge.
With drop_metering: true the purge also removes each account's meter rows, so the test leaves no trace in platform usage. The meter rows are its usage events, its storage and egress call rows, and its applications' traffic, verification rollup, and database sample rows. The action records stand, because MAPI-06 makes the operational record append-only. The realm event log's rows stand, because no action removes them (ACS-L0-02).
The estate runs under a posture, one value of the control plane's setting SYNTHETIC_ESTATE: off, compat, or stress:<YYYY-MM-DD>. The date is the stress posture's expiry, after which new seeds take compat's cells while the purge and every other ceiling read the value's posture. on is an alias of compat, and any other value reads as off.
The ceilings are constants this statement states and the code holds, never settings rows, so no runtime surface raises them. They are shared: a seed counts against them whichever of the two synthetic grants its credential holds. Each is stated as its off, compat, and stress cells with the refusal it names. Standing synthetic accounts are 0, 25, and 6,000, the seed refusing 409 synthetic_ceiling_reached. Standing synthetic applications, and those on a paid plan, are 0 and 0, 50 and 10, and 12,000 and 12,000. They are refused 409 synthetic_ceiling_reached at create_application and at set_plan for a synthetic-owned application. Accounts one seed call creates are none, 25, and 100, the seed refusing 403 synthetic_posture_refuses. Token expiry the seed admits, in days, is none, 3, and 30, the seed refusing 403 synthetic_posture_refuses.
Account lifetime, in days, fixed at seeding and the sweep purging at its end, is none, 3, and 21, with no refusal, the catch-all's bound under off being compat's. Accounts seeded per operator account per UTC day are 0, 1,000, and 6,000, the seed refusing 409 synthetic_ceiling_reached. all: true on the purge is refused, refused, and admitted to super_admin alone, the refusal 403 synthetic_posture_refuses, so a purge under compat names the accounts it removes. The posture's expiry is none, none, and the date in the value. The seed reads its two ceilings by one call's count under no lock. So seeds admitted concurrently may together pass a ceiling by at most their counts, corrected at the next seed's read and by the lifetime sweep.
The synthetic_seed_purge grant has a standing ceiling of its own, a constant the code holds beside the cells. Under it a seed is refused 409 synthetic_ceiling_reached, naming the ceiling standing_accounts_per_credential, once twelve standing synthetic accounts are ones the calling credential seeded. The count reads the batches that credential seeded against the standing synthetic accounts, ahead of the posture's own ceiling. An account whose purge is still in progress counts until its walk removes it, so the count errs closed. It is read under no lock, so two seeds admitted at once may both pass it. A token minted to replace another starts at zero while the lifetime sweep purges the old one's batches. So a disclosed copy holds at most twelve of the standing accounts. A synthetic_estate token and a super_admin credential meet no such ceiling.
An account seeded under that grant holds one application, on the Free plan. A paid plan at create_application or set_plan is refused 409 synthetic_ceiling_reached naming the ceiling paid_applications_per_account, under every posture, and a second application meets the Free plan's own limit. The account is told by its batch's seeding credential, a token the grant bounds, whether or not that token still stands. So a disclosed copy's accounts take none of the estate's paid-plan places.
The two writes, the seed and the purge, are admitted only while the posture is not off. While it is off they refuse 403 synthetic_estate_disabled before any other check. The dispatcher's switch gate runs ahead of the credential-kind, scope, grant, bound, and destructive-class gates, so a customer's session meets this refusal and not grant_required. Their rows, marked switch: synthetic_estate in the enumeration, are listed as tools while the posture is not off and unlisted while it is. They are listed only to a connection whose credential holds synthetic_estate or super_admin or is bounded by synthetic_seed_purge, both rules MCP-08's. The listing is derived from the enumeration's own marks, the credential, and the setting, and no list is kept beside it (MAPI-11).
read_synthetic_purge, read_synthetic_signin_code, read_synthetic_account_state, and the reads of existing synthetic accounts keep working with the posture off. So a stranded estate is inspected, swept at its lifetime by the lifetime sweep this statement states, and, after the posture leaves off, purged by hand.
The lifetime sweep is the platform's own locked pass in the management service, every ten minutes on the stale-deploying sweep's cadence, one replica per tick. It runs outside the switch gate, so it meets no posture gate. It starts each expired batch's first purge once, by a compare-and-set of swept_at from null in the statement that starts the purge, so a second tick starts nothing. That purge carries drop_metering: true, the batch's own requesting account, and a request_id of null, never a batch identity. A batch identity would let an operator's earlier purge under the same key answer the sweep's as a repeat and start nothing. The purge also carries an action record whose actor is the requesting account under the credential kind platform_sweep, the platform's own act, which holds no grant and no destructive class (MAPI-06; MAPI-12).
A batch whose seeding credential reads revoked or expired is swept at the next tick, so no batch outlives its credential. A batch whose credential is null is swept at its expiry alone.
The pass's catch-all returns what a failed walk left. Each tick, a builder-realm user row carrying the synthetic flag is due where it is older than the posture's lifetime by its own creation instant (compat's lifetime under off). It is also due where a swept batch whose expiry is past names it. The sweep starts one purge per requesting account for the due rows under a fresh per-tick request_id, never a batch identity. The requesting account is the batch's own where a swept batch names the row. Otherwise it is the account opened by the first entry, in the setting's order, of the control plane's operator set SUPER_ADMIN_IDENTITIES whose identity has opened one (MAPI-09). So where no entry has, the rows a swept batch names are still purged under the batch's own account, while the rows no batch names are skipped with a marker line once per pass.
A row is excluded while an unswept batch names it or while a purge account row in pending or running holds it. So a walking account is never walked twice, and one tick's purge is not restarted at the next. A tick that swept a batch or started a catch-all purge writes one info line to the control-plane stream naming the batches it swept, the purges it started, and the count of the catch-all's accounts. A tick that did neither writes none. The console marker line below is apart from that line.
read_synthetic_signin_code, request { account | address, binding? }, answers the unspent codes the emailed-code route holds for the account (ACS-L0-12 states the holding and when a start writes it) newest first. Each carries its issued instant, its expiry instant, its binding hash, and the attempts remaining. Where binding names one browser's binding hash, the base64url of the SHA-256 of the cookie value, it answers that ticket's code alone. It is admitted for an account in the caller's own batches under synthetic_estate and for any synthetic account under super_admin.
Under synthetic_estate any account outside the caller's reach, a standing customer account among them, refuses 409 account_outside_batches, the reach read first; under super_admin a standing account that is not synthetic refuses 409 account_not_synthetic. An id no account stands for reads as no codes under super_admin, and every read lands in the action record (MAPI-06). read_platform_usage answers the estate whole under the optional top-level member synthetic ACB-L0-79 states.
The codes held under an account are its own sign-in's on the builder realm, and those of fixture end users in the realms of applications it owns. ACS-L0-12 holds a code in an application's realm only where the realm's owning account is synthetic and the address is at the fixture domain. So the read answers such a code by the owning account and the start's binding hash, and answers nothing of a person's sign-in. It answers no code for an account whose record is gone, under either grant, whatever row a start left standing under it until the sweep's delete.
The management service writes a console-log line carrying a marker constant when a seed is refused at a ceiling, when the standing accounts pass half the posture's ceiling, and when the sweep starts a purge over an account that still stands. Such a purge is every catch-all purge, and a batch's purge where an account the batch names outlived its seeder's own purge. The service writes no line for a batch's purge whose accounts are all gone, which completes with zero removals and is started all the same for the metering it drops. It writes none there because the ordinary batch's seeder purged it long before its expiry, and a line there would mail the operator at every seed's expiry. The line's count is the accounts still standing.
A sixth scheduled-query rule in plane_alerts.bicep reads the line, counting those three events alone and never the catch-all's skip line, which a standing empty list would raise every pass, one of the alert kinds PLD-L0-67 counts. The wire route POST /api/v1/actions/seed_synthetic_accounts under a minted token carrying either synthetic grant is a harness's route, so a token value never passes through an AI transcript.
The twelve refusal names this statement owns are rows of schemas/wire_errors.json (MAPI-15). synthetic_estate_bounded (403) answers a token the grant bounds on a row outside the bound. synthetic_seed_purge_bounded (403) is the same answer for a token the synthetic_seed_purge grant bounds, on a row no grant marks. publication_bounded (403) is the same answer for a token the publication grant bounds, feedback_queue_bounded (403) for a token the feedback_queue grant bounds, and issues_bounded (403) for a token the issues grant bounds. issues_level_refused (403) answers a relayed act the level of the token's issues grant does not admit, naming the level and the acts it admits.
synthetic_estate_disabled (403) answers every wire write of the estate while the posture reads off. synthetic_posture_refuses (403) answers an act the standing posture does not admit, and a seed past the synthetic_seed_purge grant's own bounds. synthetic_ceiling_reached (409) answers a count the posture bounds, and the synthetic_seed_purge grant's own two ceilings. account_not_synthetic (409) covers the code read and the state read beside the purge, the two reads under super_admin alone. account_outside_batches (409) answers the purge, the code read, and the state read under a synthetic grant naming an account outside the caller's batches. The two reads read the reach first, as the purge does under synthetic_seed_purge. Under synthetic_seed_purge it also answers a purge repeating another credential's request_id.
A test in the platform's suite holds the seed with its batch and its sign_in option, the purge with its scoping under the narrow grant and its join, the reads, and the posture with its grammar and its alias. It holds each ceiling at its refusal, the grant, and the bound of each bounding grant at the dispatcher's gate, in the listing, and on the two data planes. It holds the synthetic_seed_purge grant's three rows, its bounds on a seed, its two ceilings, and its scoping of the purge, the read, and both repeats. It holds the sweep — its once-per-batch mark, its null request_id, its credential rule, and its catch-all — the code read, the usage member, the alert line, and the interruption. It holds an application realm's code read, the purge's delete of held codes, and no code for a gone account.
read_synthetic_signin_code takes address in place of account, one of the two required, binding? beside either. The address is one in ACB-L0-79's label form at the fixture domain, lowercased. The read resolves the account through the realm store's email identity lookup on that address. It answers the codes held under the account where one exists and those held under the address where none, account null until the account exists and its id after, and writes nothing (MAPI-04). An address held by an account outside the caller's reach is refused 409 account_outside_batches, as the read by id refuses one. An address outside the fixture domain is refused 409 address_not_synthetic, the twelfth name this statement owns, and answers nothing, the refusal carrying no address. The typed address reaches no action record, log line, usage row, or refusal detail except as PLD-L0-79's keyed member.
A first sign-in at the fixture domain (ACB-L0-79) writes one batch at its confirmation. Its requesting account is the operator set's first opened account (MAPI-09), its seeding_credential null, and its request_id first-sign-in:<lowercased address>:<account id>. Its expiry is the posture's lifetime from the creation instant, so the lifetime sweep takes an abandoned account by its batch as it takes any expired batch, and the catch-all reads nothing new. A label re-used after its first account's purge writes a second batch, the first untouched. The prefix first-sign-in: is reserved to that write: a seed carrying a request_id opening with it is refused 400 invalid_request, and no seed answers such a batch as a repeat. The form is one exported constant of the estate module, read by the store and by the confirmation.
Under synthetic_estate the purge, the code read, the state read, and read_synthetic_purge admit, beside the batches the credential itself seeded, every first-sign-in batch and the code held for a first-sign-in address before its account exists. Every such credential's reach widens to those batches within the one operator account the harness's tokens share, so no adoption is written. A disclosed live-pass or journeys-hosted copy then reads the code of, and purges, another run's stranger account and no customer's (CRD-14; CRD-17). super_admin reads as today. A token the synthetic_seed_purge grant bounds reaches no first-sign-in batch: the code read and the state read are refused it grant_required, and the purge and the purge's read answer only what its own credential seeded (CRD-25).
read_synthetic_account_state, request { account }, answers a synthetic account's state in six parts, each in its customer row's shape and carrying no secret value. They are the account record as read_account answers it, without the caller's credential members, the applications as list_applications, and each application's status with its environments as read_status, without tables and without a wait. They are its versions as list_versions, the tokens as list_tokens, never a value, a hash, or anything a token could be rebuilt from, and the usage as read_usage. The six shapes have one home, the payload file's shapes, which this row references by entry; each customer row's inline response equals its entry, a test holding them equal.
Its reach is the code read's, the hosted trial's token refused grant_required. Under synthetic_estate any account outside the caller's reach refuses 409 account_outside_batches, a standing customer account and an id no account stands for among them, the reach read ahead of the not-synthetic check. Under super_admin a standing account that is not synthetic refuses 409 account_not_synthetic and an id no account stands for 404 not_found.
MAPI-17: The operator signal is one grant-marked row of the enumeration, record_operator_signal, by which a company test harness reports a run's ending, or its result, to the operator under a source name. The row is resource account, reversible tier, marked grant: synthetic_estate (MAPI-09). So the dispatcher's grant gate admits a credential holding synthetic_estate or super_admin and refuses every other credential grant_required, a customer's session among them, save where a refusal that answers a credential ahead of the grant gate answers it first (MAPI-14). A token the synthetic_estate grant bounds is admitted to it as it is to the synthetic estate's five rows (MAPI-16). The row is no row of the synthetic estate, which stays the five rows MAPI-16 names: the act touches no test fixture and names no account.
It carries no switch mark, so it is listed and answers whatever the SYNTHETIC_ESTATE posture reads. It carries no request_id, each call being one report, and no clients member. Its annotations are readOnlyHint false, destructiveHint false, and openWorldHint false, with no idempotentHint member, each call writing another counted line (MCP-11). The request names event, source, and an optional detail. event is one word of a closed vocabulary of two: ok, a run that ended clean, and failed, a run that did not end clean or a result that failed. The words are generic, and the name of what is reported is carried in source, which matches ^[a-z0-9_.-]{1,64}$.
detail is a string of at most 200 characters, a null refused as any other non-string, counted on the wire in code points as a JSON Schema maxLength counts them. The MCP tool's derived validator counts UTF-16 units and so refuses, ahead of the platform, a detail of characters outside the Basic Multilingual Plane that the wire admits. detail is scrubbed before it is written: the value of a minted token, of an end user's session, and of a transfer grant, an address, and a URL are each replaced by a marker.
A source or a detail that contains control_plane_, in any letter case, is refused. It is refused because that prefix begins every marker the platform's own log lines carry and the platform's marker rules match a marker over a whole line (PLD-L0-67), so a free member naming a marker would satisfy another rule. A source that contains the prefix of one of those three credential values is refused too, a source being written to the line as given. A request outside these shapes answers 400 invalid_request with the member named in the detail, and the action adds no refusal name (MAPI-15).
This paragraph qualifies "three credential values" in the scrub and in the refused source with the egress key (SEC-L0-18). A value of its shape in detail is replaced by a marker as the other three are, and a source that contains its prefix, turnzero_cloud_egk_, is refused.
The act writes one line to the management service's standard output, a JSON object of exactly the members marker, event, source, detail, and credential in that order. marker is the constant control_plane_operator_signal, and detail is the scrubbed text or null. credential is the calling credential's identity, the value the action record names (MAPI-06), a minted token's id and null for a session, which carries none, so a line a token wrote is attributable from the log store alone. The act writes nothing of its own beyond the line, no table, no setting, and no fixture, and the dispatcher records and meters the call as it does every action's (MAPI-06). The answer is recorded: true with the event and the source as given.
The tier is reversible and not observe because the line can notify the operator. PLD-L0-67 owns the two alert rules that read it, the failure rule that counts failed lines split by a bounded source and the heartbeat rule that reads the newest ok line of one named source. This statement owns the row, the vocabulary, the bounds, the scrub, and the line. The action has no rate bound and no refusal name of its own: a harness makes a few calls a run. For any other holder of the grant, the platform's admission window per source address (PLD-L0-67), inside the edge's own limit on the management path, bounds the lines one address can write.
Every holder of the grant is admitted to the row, so a disclosed copy of any token carrying it can write a line under any source name. Among those lines are a failed line that notifies the operator and an ok line under the source the heartbeat rule reads, which keeps that rule from firing. The line names its credential, and the credential register's rows state that reach (CRD-14; CRD-17).
The event words and the wire call have one home beside the platform's other operator clients. A client script exports the two words and makes the one call, and it loads the operator client inside the call alone, so that importing the words runs nothing. The platform's suite holds the script's words, the platform module's words, and the payload schema's enum equal. It also holds the request as the client sends it, the client's refusals ahead of a call, and a refusal's status and code passed on as the wire call threw them.
MAPI-18: The five feedback actions, submit_feedback, read_feedback, rate_experience, settle_feedback, and record_check, are rows of the enumeration on the account resource (API-L0-20; the AI tool interface's feedback scenario). Beside them stand the relay relay_issue_act and the two space rows create_issue_space and list_issue_spaces, whose forms the issue service PRD's relay and provisioning rows state and whose bounds and refusals this statement states. Each is registered while the control plane's setting ISSUE_SERVICE_ORIGIN names the issue service, and unlisted, refusing not_yet_provisioned, while it is empty (MCP-08; MAPI-10).
On every call to the platform's own space the plane presents the space's operator token the setting ISSUE_SERVICE_TOKEN carries by secret reference (CRD-19), on the package's 0.3.0 wire, the recovered mark alone on the 0.2.0 wire. On a call naming space it presents that space's own token, read from the plane's vault or, for a standing pair's space, from custody, and on the relay the named space's own token. On a provisioning act and on an account space's creation it presents the provisioning credential the register's issue service provisioning credential row states. The platform space's owning account is the setting ISSUE_SERVICE_PLATFORM_ACCOUNT, empty where unset (the issue service PRD's relay row).
Each of the four feedback rows takes space beside its own members (the issue service PRD's actions row); record_check takes none. space names, as a lower-case UUID, a space the acting account holds, which the call then addresses under that space's own token: a space of the account's own, an application's own space, or one space of a standing pair. An identifier matching none refuses 404 not_found before any token is read; a token that does not answer refuses 503 issue_service_unreachable. A request naming application or environment refuses invalid_request naming space. The bounds below are judged before the space is resolved.
With space, read_feedback reads the space whole in every form and settle_feedback settles an issue of it, no grant read. The scope gate refuses a token bounded to an application on the four rows token_scope_refused, the form naming no application (API-L0-17). The removal of application and environment from the four rows is MAPI-02's thirty-eighth use of its within-version allowance, made while the platform held one builder account and six live applications, a synthetic account aside. The paragraphs below state each row on the platform's own space.
submit_feedback is reversible tier, unmarked, carrying admits: ["synthetic_estate"] (MAPI-16), so any bearer, any account-scoped minted token, and a token the synthetic-estate grant bounds file into the platform's own space. The request names source, the actor's kind, person, agent, or system, with provider and session on an agent's, both or neither. It names kind, one of the record's seven, bug, gap, docs, friction, question, task, and praise, or the 0.2.0 words missing_capability, documentation_gap, refusal_not_understood, and usability, read as the record's (the package's XIT-01), and title, 1 to 200 characters. A question or a task is refused invalid_request from a filing the plane gives the field origin, ahead of any call.
Its optional members are text (or body), of at most 20,000 characters, impact (or severity, read as an impact), and workaround and proposed_resolution, each of at most 4,000 characters. They are also labels, evidence, restricted, problem_key (or key), and repeat_of; two names of one member are refused together. evidence holds action, refusal, reference, and code_site, each 1 to 200 printable characters, the 0.2.0 environment and version, which the plane reads as one build the report saw, and a context of at most 20 short named strings.
The request declares neither personal nor excerpt, and a call that names either is refused as MAPI-22 states. The report the answer carries holds no personal member.
The plane gives each report its origin and no filer names one (the package's XIT-04). On the platform's space a system filing under a credential holding the synthetic_estate grant is beta, the AI beta run's, and every other filing field; on a space the request names a person's filing is person, an agent's workspace, and a program's test. On a space the request names, a confirmation is relayed as given under that space's own token, and the service then judges it, and a filing's link by evidence, by the report's origin (the package's XIT-05).
problem_key names the problem among the caller's own reports: a same-key repeat with the same evidence answers retried, and one with new evidence files a second report linked to the same issue, linked. With key, recovered: true, and no member of a filing, the call is the 0.2.0 recovered mark, relayed on the 0.2.0 wire, which settles the open filing the key names among the caller's own as recovered. The service settles it only where the caller's own filing under that key opened the issue and every report on it is the caller's; otherwise it refuses the mark, and the call answers 404 not_found (the package's XIT-01).
The answer carries the caller's own report, the issue through the projection, the outcome, filed, linked, retried, or noted, up to three candidates it may repeat, masked, the credential forms the service's scanner hid, and stamped. The plane answers each candidate as the service answers it. Its title is the issue's or null by the package's rule, so a candidate carries no title that a report of an origin other than workspace or platform gave (the package's XIT-05). repeat_of beside a filing confirms a candidate after the filing, and report with repeat_of and no member of a filing confirms one alone, the contract's follow (the package's XIT-05); a filing that confirms counts two calls in the bound.
On the platform's own space, for a credential that does not read the queue, the plane reads the issue a confirmation names before it relays the follow, the read counted once in the read bound. A confirmation that names a restricted issue is answered 404 not_found exactly as one that names no issue is, and links nothing. A credential holding feedback_queue or super_admin, which reads the queue, has its confirmation relayed as given, with no read. The service then judges it: it confirms a report of the origin field or beta onto no restricted issue under any token, and refuses the follow as one naming no issue (the package's XIT-05). So that credential is answered 404 not_found too, and nothing is linked. The plane's reading stands as a second check: it judges the record's own restricted member, and answers a record that carries none as a restricted one.
On that space, a filing whose answered issue is restricted, or carries no restricted member, answers a credential that does not read the queue its own report, the outcome as given, and a null issue, no member naming the issue, whatever linked the report. A repeat_of naming that issue is answered as one naming no issue is. The report stays filed. The service itself links a report of the origin field or beta to no restricted issue by its evidence, so such a filing is answered the unrestricted issue it joined or opened (the package's XIT-05). A filing that asks the mark itself, and a repeat under the filer's own key onto a restricted issue, answer that credential the null issue. The plane's withholding stands as a second check, judged from the record's own mark.
On the platform's space, for a credential that does not read the queue, the plane relays the recovered mark only where the filer's filing under that key opened the issue it lands on, and that issue is unrestricted and holds that filer's reports alone. Otherwise the plane refuses it 404 not_found before any write. A key under which the filer holds no report is refused by the plane as the service refuses it, relaying nothing, and a read the service could not answer is refused as any unanswered call is. A relayed mark answers the issue's id, status, and disposition alone, and the plane's two reads ahead of the mark count in the read bound.
Where the evidence quotes a reference, the plane reads the newest row of the action record carrying it under the acting account within the twenty-five days before the filing, once more after the record's one-second flush where the first read finds none (MAPI-06). Under a credential holding the synthetic_estate grant it reads the accounts of the batches that credential seeded too, the synthetic-batch clause (MAPI-16).
Where a row joins, the evidence carries the row's action and the context the filer gave. Where the row's outcome is a refusal and the filing's kind is bug, the evidence carries that refusal and the row's code_site too and is stamped, and the request goes to the service with evidence_basis: stamped. Where the call completed or waits for approval, or the filing is of another kind, the request names no basis, no refusal, and no code site, and the report stands claimed. An answered action names no problem, and a report of another kind names a problem other than the refusal it cites, where the service joins stamped reports on their action, refusal, and component whatever their kind (the package's XIT-05).
The seen_in of a report whose row joins names the build that answered the call: its version the build's source commit, and its environment the plane's, development where the estate's apex opens dev. and production otherwise. Its line is cloud.plane where the platform's space declares that line and null otherwise (the package's XIT-14). Where no row joins, the filer's evidence stands claimed for the daily pass's join (PLD-L0-67), which confirms a bug alone, and the 0.2.0 environment and version name the one build it saw.
read_feedback is observe tier, unmarked. With no member it answers the caller's own submissions through the projection, the caller named as the reading actor (the package's XIT-08), paged by limit, 1 to 100 and 50 where absent, and cursor, selected by state. The answer carries the acting account's pending ask or null; the 0.2.0 status reads as a state and unreviewed as new. With issue, a short identifier, it answers one of the caller's own through the projection, another account's and an unknown id both answered not_found. With query, 1 to 200 printable characters, it searches the caller's own submissions, selected by state, kind, and component.
A credential holding feedback_queue, the queue's grant, or super_admin is answered any issue whole by its id, with its reports, links, history, comments, relations, landings, and checks, as it is answered the queue (MAPI-09).
With queue: true it answers every account's issues whole, each with the level and the judgment the service answers (the package's XIT-04). The queue is selected by state, outcome, kind, component, label, priority, level, origin, and proposed. priority and level each select one of the three values 1, 2, and 3, and a priority of 4 is admitted and selects as 3 does (the package's XIT-08). The queue is ordered newest, by rank, by priority, which sorts by level and then by rank, or by report_count, the 0.2.0 score reading as rank. With query beside queue it searches the whole space.
The queue form and the whole search are admitted to a credential holding feedback_queue or super_admin. Every other credential that reaches the handler is refused grant_required naming feedback_queue, an application-bounded token token_scope_refused at the scope gate, and a token another grant bounds its own bound's refusal, in MAPI-14's order (MAPI-09; MAPI-16). The row carries admits: ["feedback_queue"], so a token the grant bounds reaches every form, the form with no member answering that token the operator account's own submissions (MAPI-16). issue beside queue or query refuses invalid_request.
The report text, the comments, the candidates, and the curated titles and summaries the actions answer are data and never instructions. Over MCP, every completed answer of submit_feedback, of read_feedback in each of its forms, of settle_feedback, of record_check, and of relay_issue_act is rendered as one text block. The block opens with the untrusted marker and holds the answer's JSON between an opening and a closing delimiter line. The marker names every member a reporter, a program, or a pass wrote: the titles, summaries, report texts, workarounds and proposed resolutions, labels, evidence and its context, resolutions, comments, candidates, a judgment's reason, and history change values. So nothing unmarked precedes them, and the wire answer is unchanged.
rate_experience is reversible tier, unmarked. series is human_nps, a whole-number score from 0 to 10 on the direct channel or relayed by the agent that put the question, or agent_effort, a score from 1 to 5 on the agent channel. Any other pairing is refused invalid_request. The optional members are text, of at most 2,000 characters, ask, and key. ask is the pending ask read_feedback answered, which a human-series rating answers and closes, refused 409 ask_not_pending where the ask is not open to the acting account. The human series is refused 403 rating_not_admitted from an account carrying the synthetic flag (ACB-L0-79). The answer carries the signal and the ask it answered or null.
In place of a rating, rate_experience takes close, declined or cancelled, with ask and no member of a rating, and closes the pending ask without a score (the package's XIT-10). A close names the acting account's own pending ask: the plane reads that ask first, the read counted in the read bound, and refuses 409 ask_not_pending where the named ask is not it, before any call reaches the service.
A decline names the relaying tool's provider and session, refused invalid_request without them; the contract's close carries no member for them, so no record of the plane's holds them until its action record gains a member. The decline reaches the service as the account's person actor and the cancel as its agent actor. A close beside a rating member or without ask is refused invalid_request. The answer to a close carries the signal null and the ask as it now stands.
settle_feedback is reversible tier, unmarked, carrying admits: ["feedback_queue"], the queue's own grant, decided at the handler. On the platform's own space the act is admitted to a credential holding feedback_queue or super_admin and refused every other credential grant_required naming feedback_queue; with space it settles an issue of a space the acting account holds with no grant read (ITS-L0-03). A token holding the grant and not super_admin is bounded by it as MAPI-16 states: refused feedback_queue_bounded on every other row no earlier gate answers, a row another grant marks keeping grant_required (MAPI-14; MAPI-16). It is minted on MAPI-14's terms from a session holding super_admin. So a session that triages the queue from an AI client holds no credential a planted instruction could turn to a filing or to any act beyond the queue.
The act names issue and act, one of settle, merge, wait, reopen, and unmerge, with an optional key. settle names an outcome, one of the record's eight, and, where the outcome is duplicate, target, the master. A resolution of 1 to 4,000 characters is required for every outcome but noted and duplicate, and the 0.2.0 disposition reads as its outcome (the package's XIT-01). merge names its target and closes the issue duplicate; wait names its resolution; reopen and unmerge take neither. approve and decline are retired and refused invalid_request by name: no person approves or declines a duplicate, which the service's passes merge where they agree on stamped or confirmed evidence (the package's XIT-07). An act the issue's state excludes refuses invalid_request naming the service's refusal, and the answer carries the issue as it now stands.
record_check is reversible tier, marked grant: synthetic_estate on MAPI-17's pattern (MAPI-09): the dispatcher's grant gate admits a credential holding synthetic_estate or super_admin and refuses every other credential grant_required. A token the grant bounds is admitted to it as to the synthetic estate's rows (MAPI-16). The request names check, the run's stable key of 1 to 200 printable characters, and result, green or red. Its optional members are covers, the components and actions the run exercised, builds, at most 20 builds it ran, cause, harness, estate, or null, component, evidence naming no build, key, and source, system where absent, with an agent's provider and session.
The plane posts the check into the platform's own space naming the acting actor, so the service judges the key among that actor's checks, and answers { check, issue, outcome } (the package's XIT-17). The filing bound counts the call.
To a credential that does not read the queue, record_check answers issue as a filing's answer does: through the projection with no report, or null where the issue is restricted or its record carries no restricted member. Its check then carries no lease and no held_by member, and the issue member of that check is null unless it names the issue the answer carries. The plane judges this from the check's own answer and makes no further call. A credential that reads the queue is answered both whole.
A refusal the dispatcher answers, and an internal failure, carries after its detail the known-issue line where the plane's copy of the known-issue table names the action and the refusal (PLD-L0-67). The line names the issue's identifier and its trusted workaround where one stands, and, once a fix has shipped, the build that carries it and a request to file again naming repeat_of. The line is read from the process's copy, loaded at boot and every minute, never from the store or the service at the call. The dispatcher also writes on every action record row the build that answered the call and, on a refusal the handler threw, the code site, <file>:<line> (MAPI-06).
The plane bounds the calls it relays in fixed windows of one minute. Each count is taken before the call as the service counts its own, a refused call counted with the rest, and each past its figure is refused 429 feedback_rate_limited with a cause word of its own. The filings, ratings, closes, and checks are at most 20 from one account and at most 100 from every account together. The reads of read_feedback are counted once per service call the form makes: two for the read with no member, its list and its ask read, and one for the other forms. They are at most 20 from one account and at most 50 from every account together.
Each relayed call counts once in the window of the credential that made it, at most 60 a minute for one token by its identity, a session's account where it has none (MAPI-06). It counts once more in its target space's aggregate, at most 150 a minute for an account's own space. A relayed call counts once more there for each call the platform may make beside it (ITS-L0-05). The platform's own space counts its relayed calls in the two aggregates above, a read act among the reads and every other act among the filings. An account creates at most 5 spaces a minute through create_issue_space. The relay's figures and the overshoot stay at or under two-thirds of a space's own rate, so a space's other callers keep their third.
An account holds at most 50 spaces of its own. At 50, a creation naming a space it does not hold is refused 403 space_creation_ceiling with nothing created, and a repeat naming a space it holds answers created: false. The license is read ahead of the minute's bound and this ceiling. A creation by an account lacking the blueprint profile, a repeat naming a space it holds among them, is refused 403 blueprint_required and does not count toward the minute's 5 (ACB-L0-82).
The figures are constants the code holds. They are sized so that the relayed total, the read aggregate, and the replica overshoot together stay at or under two-thirds of the service's space rate of 300 calls a minute, one count across the permission levels (the package's XIT-12). The other third is headroom for the platform's own calls: the erasure, the export's pages, the asks it opens and reads, and the daily pass. The export itself is not bounded, being one of the calls the headroom protects.
The pending ask's read the MCP layer makes beside a completed read_status or list_versions result is one of those calls, and so is the live-fixed read beside it, the account's fixed issues through the projection (CHI-L0-14). Each is made at most once a minute for the account and both count in the 30 a minute from every account together, each read under a two-second bound, the aggregate carrying the same replica overshoot. A read past a figure or the bound leaves the result without its block and refuses nothing. The relayed share, the ask reads' figure, their overshoot, and a reserve of 25 calls a minute for the rest together stay at or under the space rate, the sum the suite holds.
The overshoot is what the management replicas together can admit past a figure before a flushed row shows every replica's hits, each replica reading a window as its last flushed row plus its own unflushed hits and flushing every second. It is at most the plane's replica ceiling of nine times five calls a replica in one interval, a design figure the suite holds beside the sum and the template's replica count. The service's own rate refusal answers under the same name.
A call the service could not answer answers 503 issue_service_unreachable with the cause word in the detail. The causes are the transport failing, the call passing the plane's bound of ten seconds, a fault of the service's own, the router's quota refusal on it, and a refusal of the platform's own credential. A refusal of the platform's credential is also written once per interval to the control plane's record as a warn line naming the cause, so a lost, revoked, or unset token is read there rather than found at a customer's deletion (CRD-19). The service's not-found refusals answer 404 not_found, and every other refusal of the service, a lease's among them, answers invalid_request with its name in the detail.
On the relay a refusal of the service by the act's content, the issue's state, a lease, or a record that does not stand answers issue_refused with the service's own status and its name in refusal. The five refusal names this statement owns, feedback_rate_limited, issue_service_unreachable, rating_not_admitted, ask_not_pending, and issue_refused, are rows of schemas/wire_errors.json (MAPI-15), the last carrying the service's status and a refusal member and the rest no member beyond the base six.
A test in the platform's suite holds, over the package's test double, the eight rows, the words against the package's, the bound gate's admission of the bounded tokens, and each refusal at its gate. It holds each cause a service out of reach answers, the stamp with the synthetic-batch clause, record_check, and the known-issue line. It holds the queue grant's mint, its reach in every form of the read and on the settle, its refusal of every other row, and its refusal on both data planes. It also holds the plane's bounds with their figures' sum, the relay's bounds, the export's member, the deletion walk's member with its failure, its retry, and its form for an account already gone, and the MCP layer's rendering and blocks.
MAPI-21: The application-grain data archive is three rows of the enumeration on the application resource (API-L0-23). The fifth paragraph states the third, mint_download_grant. request_export is reversible tier and takes application, required, and environment, optional. It answers 202 on deploy's shape (MAPI-04) with the export's identifier, the state running, the export area's name, the export's folder, and repeated. repeated is true where the request answered an export already running for the application and environment. read_export is observe tier and takes application and export. It answers the state, running, completed, or failed, the outcome of a failed export, the progress counts, and the instants. Once the export has ended it answers the manifest, and null where the manifest file is gone.
The outcomes are interrupted, table_bound_exceeded, database_failed, files_failed, area_unavailable, and runner_failed. A token bounded to one application reaches the three rows for that application (API-L0-17). An application the acting account does not hold refuses 404 no_such_application. An export the named application does not hold refuses 404 not_found. A missing member, or an environment outside the platform's two, refuses 400 invalid_request.
The export's row is the act's operational record: its state, its counts, and its instants, and no table or file name. The names are the manifest's, a file of the export area, which ends with the area. A running row whose heartbeat is older than the deploy's stale bound is ended failed interrupted by the read that meets it, read_export's or request_export's, and no timer sweeps the rows. A pass whose application is deleted stops at its next heartbeat and ends interrupted, writing nothing more into the export area the teardown removed. A test in the platform's suite holds the pass over an engine and the storage double, and the two rows over the routes.
Before its pass writes, request_export removes the folders of the pair's earlier ended exports from the export area, so one folder stands per application and environment (API-L0-23). The replaced export's row stands, and its read_export answers the manifest null. The suite's test holds the removal over the storage double.
mint_download_grant is reversible tier and takes application and export, required, and local_path, optional. It answers the export, the application, the environment, expires_at, and one line as command and command_windows (PLD-L0-94). The grant appears inside the two line members and in no other. The row is admitted to the credentials read_export admits for the application (OST-L0-08). local_path is held to the class deploy's local_path admits, and a path outside it refuses 400 invalid_request (PLD-L0-86). An export that is not completed refuses 409 export_not_completed, and a completed one whose manifest file is gone refuses 404 not_found. Each refusal mints nothing. A test in the platform's suite holds the mint, its refusals, and the line run against the suite's own plane.
MAPI-20: restart_application is one row of the enumeration on the environment resource at the reversible tier (API-L0-22). Its request carries application and environment, the environment one of the platform's two (PLD-L0-40). Its answer, status 202, carries the contract version, the application, the environment, the version the environment serves, the state deploying, and the environment's hostname under the current label. It also carries health_path, the recorded manifest's health path as the health gate will probe it, cut at 256 characters (PLD-L0-63). The action record holds the outcome deploying (MAPI-06), and its refusals are the platform redeploy's, each a row of schemas/wire_errors.json (PLD-L0-84; MAPI-15).
Exact source Markdown
---
document: management_api_contract
prefix: MAPI
---
# The Management API — Resource Contract
## Purpose
This file is the resource contract for the one management API the management API PRD describes: the resources the plane exposes, the actions over them, how the contract is versioned, and how a credential binds to it. It settles the first point of that PRD's open questions together with MCP-02's authentication binding. It is the layer the MCP surface derives from: the tools of `mcp_surface.md` are these actions, surfaced (MCP-03). A test in the platform's suite holds the two enumerations to each other — an automated check of API-L0-01's requirement that each client expose only capabilities of the management API.
The launch enumeration has one home: `schemas/management_api.json` beside this document — the resources, and action by action the resource it operates on, its authority tier, and which clients may call it. This document states the rules the enumeration obeys and repeats none of its rows.
What this document does not cover: the per-action payload schemas, which land with each action's implementation (raised below; the route rule, methods, and error shape are MAPI-10's); the served three-form derivation of API-L0-09, `served_context.md`'s; and the pending action's own mechanics, which stay API-L0-07's.
Requirements are numbered MAPI-nn.
## The contract
MAPI-01 (decided): The management API is one versioned HTTP contract of resources and actions: every capability is a read of a resource or an action upon one, and every resource and action is enumerated in `schemas/management_api.json`. A capability enters the plane by entering that enumeration. There is no unenumerated endpoint for a surface to lean on, which is what keeps every surface a client (API-L0-01).
MAPI-02 (decided): The contract carries its version — `1` at launch — stated in every exchange. Within a version, evolution is additive: new resources, new actions, new optional fields. Removing or renaming anything, or changing an action's tier, is a new contract version, never a quiet edit — the callers are AI tools acting on served descriptions of this contract, and a description that drifts under a caller is a capability that lies.
Removing a request member within a version is a change a caller observes, since a call that names a member its action does not declare is refused (MAPI-22). So a removal is admitted only as a use of the shape clause below while that clause runs, and is a new contract version after. One removal was made before that rule stood, when a caller that sent the member observed no difference in the call's answer. It took the optional `request_id` member, which no implementation ever read, from twelve reversible request schemas in `schemas/action_payloads.json`, named in MAPI-04. The HTTP route holds a call's member names to the request schema and validates no member's value.
Until the platform holds one hundred builder accounts that each hold a live application, and no later than the end of the beta, a member's shape may change within version 1 in the interest of a cleaner contract. A synthetic account (ACB-L0-79) is not a builder account for this count. The shape may change without the owner's approval of each change, under the owner's standing ruling that no approval is owed while the platform holds fewer than one hundred such accounts. While the clause runs, an action whose rename the owner approved may be renamed within version 1, where over the actions route its old name answers `unknown_action` naming the successor, the tool surface following MCP-08's revision move.
The session records the account count at the change and records the change in this document — by the statement that owns the member, or by this statement where none does. The served schema's version member moves at the change's landing, so that a caller regenerates its view. The change is admitted because until then every caller of the contract is the platform's own or a tester's, changed with the member, and no served description drifts under a caller it was made for.
Every content change to a served schema file moves that file's `version` member. The served schema files are the files the index `schemas/served_context.json` names, itself among them, that carry a top-level `version` member, a date and a counter. A description's wording and an enumeration widened to values the service already answers are included, because the served descriptions are the contract an AI caller acts on, and one version string naming two contents is the drift this statement forbids.
No session writes the member: on a session branch the registrar refuses a revision that changes it. The served `integrate` writes the next value at the landing into each such file whose bytes differ from the trunk's. The next value is the trunk's value with its counter plus one, or the landing day's UTC date with the counter 1 where that day is later than the trunk value's date (kit:REG-15; kit:REG-88). So the rule is mechanical, no session judges which changes move it, and two branches that revise one file land as consecutive values. `schemas/library_catalog.json`, the catalog's shape and not its rows, carries no `version` member, lands byte for byte, and rides CTX-01's suite.
Because the value is written at the landing, a control-plane release never carries an unlanded change to a file that declares the member. The control plane's release script (PLD-L0-65) fetches the remote trunk and refuses a release whose HEAD holds such a file in bytes the remote trunk's first-parent history does not hold at that path, or whose working copy of such a file differs from HEAD's. The branch is integrated first, and the release then runs from the landed trunk commit.
The rule holds on every estate the register names (PLD-L0-85). A development-role estate is released to from the landed trunk as production is, so a promote of its build to production (PLD-L0-65) carries forms the trunk holds.
The fetch must succeed, except in a rollback. There, where the fetch fails, the script reads the remote-tracking ref the clone holds, admits the rollback only where every such file stands at that ref's tip or in its first-parent history, and says that the fetch failed and the held ref vouched. The exception stands because a ref the run could not refresh holds a past value of the remote trunk, which can only under-report what landed, and a rollback is the act an incident needs.
A widened response enumeration is a member's shape change under the clause above, recorded as one of its uses. This clause's first use: the `environments` member of `list_applications`'s response in `schemas/action_payloads.json`, an array of environment names becoming an array of objects, each an environment's name, state, serving version, and hostname, when the platform held one builder account.
This clause's second use: the `state` member of each environment in `list_applications`'s response in `schemas/action_payloads.json`, an enumeration of three values — `deploying`, `deployed`, `never_deployed` — becoming one of five with `halted` and `deleting` added. The platform then held one builder account. It is recorded here because no statement of this contract owns the member.
This clause's third use: the `source` member of `read_logs`'s request in `schemas/action_payloads.json`, whose value `all` (three console logs merged by time) and whose omission (the `app` and `platform` sources) became the application's stream whole, every source the logging store holds. The platform then held one builder account. It is recorded here because no statement of this contract owns the member.
This clause's fourth use: `submit_manifest`'s response members `credential` and `platform_credential` in `schemas/action_payloads.json`, answered on the wire surface alone and withheld on the MCP surface, the member `credentials` added to state which form the answer took. The same use made `rotate_secret`'s request member `value` optional for the two platform-minted re-mints. The platform then held two builder accounts. It is recorded here because SEC-L0-07 and DBS-L0-02 own the members and neither is a statement of this document.
This clause's fifth use: the cutover of the platform's wire vocabulary to the product's public names (CQ-44). That vocabulary is the headers the serving router sets and the control plane reads, the settings the deploy injects, the OAuth scope, the credential prefixes and the browser cookies, and the product profile value. It is a change that stops every application built before the release until its owner rebuilds it and refuses every credential issued before the release, admitted by API-L0-16 as amended. The platform then held two builder accounts that each held a live application (three live applications in all, two on the operator's account and one on the second account). It is recorded here because the change reaches every member and no one statement of this contract owns it.
This clause's sixth use: the documentation reads split into an index and a whole text. `read_documentation`'s request gains the optional member `part`, `index` (the default) or `full`. `list_context`'s catalog gains one `docs:<tree>:full` entry per tree beside `docs:<tree>`, whose text becomes the tree's index, and every catalog entry may carry `part`. The MCP resource `docs://<tree>/llms.txt` answers the index where it answered the whole text, and `docs://<tree>/llms-full.txt` is added. The platform then held two builder accounts that each held a live application (three live applications in all, two on the operator's account and one on the second account, read through list_accounts and read_platform_usage under the operator's minted token). It is recorded here because CTX-07 owns the reads and is not a statement of this document.
This clause's seventh use: the `standing` member of each entry in `list_library`'s response in `schemas/action_payloads.json`, an enumeration of three values — `current`, `newer`, `withdrawn` — becoming one of four with `not_held` added for a served entry the caller's `installed` list does not name. The platform then held two builder accounts that each held a live application (four live applications in all, three on the operator's account and one on the second account, read through list_accounts and read_platform_usage under the operator's minted token). It is recorded here because LC-06 owns the member and is not a statement of this document.
This clause's eighth use: the `outcome` member of each row in `list_versions`'s response and of the `deploy` member in `read_status`'s response in `schemas/action_payloads.json`. Its shape on a row failed at the health gate, served by the control plane's released build d8cc3b62, becomes the one `gate` member PLD-L0-59 states, carried whole by both reads. The shape it replaces is the four members `last_status`, `startup_output`, `startup_output_truncated`, and `startup_output_pending`, `startup_output` answered on `read_status` alone and the other three on both reads. The platform then held two builder accounts that each held a live application (four live applications in all, three on the operator's account and one on the second account, read through list_accounts and read_platform_usage under the operator's minted token). It is recorded here because PLD-L0-59 owns the member and is not a statement of this document.
This clause's ninth use, the wire error shape's members, is recorded by MAPI-10, the statement that owns the shape, as is every later use that changes a refusal's members, the fourteenth and the thirty-second among them.
This clause's tenth use: the index `schemas/served_context.json` and the skill rows `schemas/skills.json` each take a string `version` member on the served forms' spelling, a date and a counter, in place of their own markers, the number `context_version` and the number `skills_revision`. The served context bundle's member `context_version` becomes the string `version` with the index's, the two titles drop their revision numbers, and the smoke test reads the index's `version` (VER-02), so that the registrar's version rule and the landing's write reach both forms. The platform then held two builder accounts that each held a live application (five live applications in all, four on the operator's account and one on the second account, read through list_accounts and read_platform_usage under the operator's session). It is recorded here because CTX-01 owns the index and API-L0-10 the skill rows and neither is a statement of this document.
This clause's eleventh use: the `detection_source` member of the `incident` row `record_incident` answers in `schemas/action_payloads.json`, the row shape `read_platform_status`'s `open_incidents`, `incidents`, and `last_incident_closed` members carry by description. Its enumeration of three values — `automatic`, `operator`, `backfill` — becomes one of four with `condition` added, the plane's conditions pass alone writing it (PLD-L0-83). The platform then held two builder accounts that each held a live application (six live applications in all, five on the operator's account and one on the second account, read through list_accounts and read_platform_usage under the operator's session). It is recorded here because PLD-L0-77 owns the member and is not a statement of this document.
This clause's twelfth use: the `section` member of each `sections_unavailable` row in `read_platform_status`'s response in `schemas/action_payloads.json`, an enumeration of ten section names becoming one of eleven with `conditions` added after `watches`. The section itself is an added member of the response, and the response's `summary_text` bound moves from sixteen lines to seventeen, the added line naming the watched conditions open and failing (PLD-L0-83). The platform then held two builder accounts that each held a live application (six live applications in all, five on the operator's account and one on the second account, read through list_accounts and read_platform_usage under the operator's session). It is recorded here because PLD-L0-76 owns the document and is not a statement of this document.
This clause's thirteenth use: the `kind` member of each row in `list_versions`'s response and of the `deploy` member in `read_status`'s response in `schemas/action_payloads.json`, an enumeration of two values — `deploy`, `promote` — becoming one of three with `redeploy` added. `redeploy` is the platform's re-creation of an environment's serving compute under its current settings (PLD-L0-84). The descriptions that enumerate the kinds in `schemas/action_payloads.json`, `schemas/management_api.json`, and `schemas/mcp_surface.json` move with it. The platform then held one builder account that held five live applications (read through list_accounts and read_platform_usage under the operator's session). It is recorded here because PLD-L0-63 owns the member and is not a statement of this document.
This clause's fifteenth use: the `state` member of `read_status`'s response and of each member of its `environments` in `schemas/action_payloads.json`, answered `never_deployed` or the compute's own word. It gains `deploying` where an environment holds no serving version and a deploy or promote row is in flight, so an environment's state and its deploy record agree. The descriptions in `schemas/action_payloads.json`, `schemas/management_api.json`, and `schemas/mcp_surface.json` move with it beside an added `environment` member naming the environment the top-level members describe. The platform then held one builder account that held five live applications (read through list_accounts and read_platform_usage under the operator's session). It is recorded here because no statement owns the member.
This clause's sixteenth use: the `state` member of `read_status`'s response, at the top level and on each member of its `environments`, in `schemas/action_payloads.json`. It answered `never_deployed`, `deploying`, or the compute provider's own word, and becomes one of the six words PLD-L0-40 states, the provider's word moving to the added member `compute_state`. The same use widens the `state` member of each environment in `list_applications`'s response, an enumeration of five values, to one of six with `failed` added. The descriptions in `schemas/action_payloads.json`, `schemas/management_api.json`, and `schemas/mcp_surface.json` move with it. The platform then held one builder account that held six live applications (read through list_accounts and read_platform_usage under the operator's session). It is recorded here because PLD-L0-40 owns the words and is not a statement of this document.
This clause's seventeenth use: the `heartbeat_at` member of the `deploy` member of each environment in `read_status`'s response in `schemas/action_payloads.json`, renamed `worker_heartbeat_at`, so that no caller reads the deploy worker's liveness as the application's. The versions table's column, the stale sweep that reads it, and `read_platform_status` keep the name `heartbeat_at`. The descriptions in `schemas/action_payloads.json`, `schemas/management_api.json`, and `schemas/mcp_surface.json` move with it. The platform then held one builder account that held six live applications (read through list_accounts and read_platform_usage under the operator's session). It is recorded here because PLD-L0-63 owns the member and is not a statement of this document.
This clause's eighteenth use: the `step` member of the `outcome` of each row in `list_versions`' response in `schemas/action_payloads.json`, the outcome `read_status` answers whole on its `deploy` member, an enumeration of fourteen values becoming one of fifteen with `issue_space` added. The value is the step a promote runs while it provisions the production issue-tracking space, which a failed or stopped promote's row already carried. The platform then held one builder account that held six live applications (read through list_accounts and read_platform_usage under the operator's session). It is recorded here because PLD-L0-63 owns the member and is not a statement of this document.
This clause's nineteenth use: the `issue_tracking` member of `submit_manifest`'s response in `schemas/action_payloads.json`, each environment's entry losing its `origin` and `settings` members and keeping the space's identifier and its outcome. No setting of the issue service is injected any more: an application reaches its space through the egress gateway's `issue-tracking` upstream, which presents the space's token (EGW-L0-06). The platform then held one builder account that held six live applications, the synthetic estate's one account aside (read from the production control database's rows). It is recorded here because ITS-L0-01 owns the member and is not a statement of this document.
This clause's twentieth use: `deploy`'s request and response in `schemas/action_payloads.json`. The request's `artifact` becomes optional beside the added members `upload` and `local_path`. A call naming neither `artifact` nor `upload` answers 200 with the state `awaiting_upload` and the added members `upload` and `next`. So the response's `state` widens from one value to two, and its `version` and `hostname` are answered with the state `deploying` alone. The descriptions in `schemas/action_payloads.json`, `schemas/management_api.json`, and `schemas/mcp_surface.json` move with it. The platform then held one builder account that held seven live applications, read through list_accounts and read_platform_usage under the operator's session. It is recorded here because PLD-L0-86 owns the members and is not a statement of this document.
This clause's twenty-first use: the `outcome` member of each row in `list_versions`' response in `schemas/action_payloads.json`, the outcome `read_status` answers whole on its `deploy` member. It was null on a `deployed` row and becomes an object carrying `result`, which every ended row carries: `succeeded`, `failed`, `interrupted`, or `superseded`. The same use widens the `state` member of the answers of `deploy`, `promote`, `roll_back`, and `restart_application` with `deployed` and `failed`, answered where the call's wait saw its row end. The descriptions in `schemas/action_payloads.json`, `schemas/management_api.json`, and `schemas/mcp_surface.json` move with it. The platform then held one builder account that held seven live applications, the synthetic estate's one account aside, read through list_accounts and read_platform_usage under the operator's session. It is recorded here because PLD-L0-63 and PLD-L0-84 own the members and neither is a statement of this document.
This clause's twenty-second use, the narrowed range of `wait_seconds` on `read_status` and `read_schedules`, is recorded by MAPI-04, the statement that owns the member.
This clause's twenty-third use: the `next_due` member of each row of `submit_manifest`'s `schedules` in `schemas/action_payloads.json`. It carried each row's next due time in both environments, and becomes null for a row whose environment holds no deploy or promote made at or after the row's declaration, as `read_schedules` answers it (SCH-L0-07). The same use adds the member `starts_with` beside it. The descriptions in `schemas/action_payloads.json` and `schemas/mcp_surface.json` move with it. The platform then held one builder account that held seven live applications, read through list_accounts and read_platform_usage under the operator's session. It is recorded here because SCH-L0-07 owns the member and is not a statement of this document.
This clause's twenty-fourth use: the `detail` member of `read_logs`' response in `schemas/action_payloads.json`. It was present on an empty answer alone, and is now present too on an answer whose window ends within its source's lag of the read, saying that the newest records may not have arrived yet. The descriptions in `schemas/action_payloads.json`, `schemas/management_api.json`, and `schemas/mcp_surface.json` move with it. The platform then held one builder account that held seven live applications, read through list_accounts and read_platform_usage under the operator's session. It is recorded here because the served form alone states when the member is present.
This clause's twenty-fifth use: the `state` member of each application in `list_applications`' response and in `export_account`'s `export` in `schemas/action_payloads.json`, an enumeration of two values, `deployed` and `never_deployed`, becoming one of three with `failed` added. An application reads `failed` where its production environment reads `failed` and nothing serves, as after a failed first promote. The descriptions in `schemas/action_payloads.json` and `schemas/mcp_surface.json` move with it. The platform then held one builder account that held six live applications, read through list_accounts and read_platform_usage under the release coordinator's granted reads. It is recorded here because WEB-L0-17 owns the member and is not a statement of this document.
This clause's twenty-sixth use: the top-level `hostname` member of `read_status`'s `application` in `schemas/action_payloads.json`. It was null before a deployment was recorded, and becomes the hostname of the environment the top-level members describe, as the `environments` member answers it, whether or not a deployment is recorded. The description in `schemas/action_payloads.json` moves with it, its clause that the hostname is null before a deployment retired. The platform then held one builder account that held six live applications, read through list_accounts and read_platform_usage under the release coordinator's granted reads. It is recorded here because no statement owns the member.
This clause's twenty-seventh use: the `contains`, `level`, and `field` members of `read_logs`' request in `schemas/action_payloads.json`. A `container` read ignored them and answered the console's lines unfiltered. It now refuses `invalid_request` where one would narrow a store read, as a non-empty `contains`, one of the four levels, or a named `field` does, and a store read filters by them as before. The descriptions in `schemas/action_payloads.json`, `schemas/management_api.json`, and `schemas/mcp_surface.json` move with it. The platform then held one builder account that held six live applications, read through list_accounts and read_platform_usage under the release coordinator's granted reads. It is recorded here because system:LGS-L0-15 owns the members and is not a statement of this document. That statement names them a stream read's filters and stands as written, its additive evolution under MAPI-02 admitting this use of the shape clause.
This clause's twenty-eighth use: the `next` member of `deploy`'s answer to its preparing call in `schemas/action_payloads.json`. It named the second `deploy` call, and becomes the `read_status` call for development, with the preparing call's own `wait_seconds`, 45 where it gave none. The descriptions in `schemas/action_payloads.json`, `schemas/management_api.json`, and `schemas/mcp_surface.json` move with it. The platform then held one builder account that held six live applications, read through list_accounts and read_platform_usage under the release coordinator's granted reads. It is recorded here because PLD-L0-86 owns the member and is not a statement of this document.
This clause's twenty-ninth use: the request member `environment` of `deploy` in `schemas/action_payloads.json`, which narrows from a slug pattern to an enum of `development` and `production`. Over MCP a value outside the two now draws the argument's validation error before the handler, where the handler answered `unknown_environment`. The HTTP route validates no member's value and still answers `unknown_environment`. No value that succeeded before is refused, since every name but `development` was refused already. The platform then held one builder account that held six live applications, read through list_accounts and read_platform_usage under the release coordinator's grant of 14:48 UTC. It is recorded here because PLD-L0-40, which owns the refusal, is not a statement of this document.
This clause's thirtieth use: the `previous_versions` member of each entry in `list_library`'s response in `schemas/action_payloads.json`, removed, so a full inventory answer no longer grows with every publish. The stored catalog keeps each entry's versioned history, and `read_library_entry` answers it. The same use has `publish_library`'s commit phase refuse a commit other than the served one unless its added request member `served_commit` names the served commit. The descriptions in `schemas/action_payloads.json` and `schemas/mcp_surface.json` move with it. The descriptions moved when the platform held one builder account, which held six live applications. It is recorded here because LC-06 and LC-04 own the members and neither is a statement of this document.
This clause's thirty-first use: the `issue_tracking` member of `submit_manifest`'s response in `schemas/action_payloads.json`, an object of one entry per environment becoming a list of one entry per space the application's calls reach, each with `space`, `scope`, `environments`, `outcome`, and `level`. The descriptions in `schemas/action_payloads.json` move with it. The platform then held one builder account that held six live applications, read through list_accounts and list_applications under the operator's session at the change. It is recorded here because ITS-L0-01 owns the member and is not a statement of this document.
This clause's thirty-third use: `deploy`'s request and its answer to the preparing call in `schemas/action_payloads.json`. The answer's `upload` loses `address` and `commands` and gains `command`, the one line that runs the turnzero-cloud command (PLD-L0-94). The request gains `zip_sha256`, which every preparing call must name, a call without it, or with a value of another form, refused `zip_sha256_required` on every surface. The request's `local_path` gains a pattern refusing the characters a shell would change inside the line's double quotes, its absence naming the folder the line runs in, not `app.zip`. Over MCP a `local_path` outside the pattern draws the argument's validation error before the handler. The descriptions in `schemas/action_payloads.json`, `schemas/management_api.json`, `schemas/mcp_surface.json`, and `schemas/wire_errors.json` move with it. The descriptions moved when the platform held one builder account, which held six live applications. It is recorded here because PLD-L0-86 owns the members and is not a statement of this document.
This clause's thirty-fourth use, the `value` member of `store_secret`'s and `rotate_secret`'s requests marked `x-wire-only` and leaving both tool shapes, is recorded by MAPI-08, the statement that owns the argument derivation.
This clause's thirty-fifth use: `deploy`'s request member `environment` in `schemas/action_payloads.json`, required becoming optional. A call that names none deploys to the application's deploy target, production on an application with one environment and development on one with two (PLD-L0-96). The same use has the `environment` of the `next` call in `deploy`'s answer to its preparing call name that target, where it named development alone. The descriptions in `schemas/action_payloads.json`, `schemas/management_api.json`, `schemas/mcp_surface.json`, and `schemas/wire_errors.json` move with it. The platform then held one builder account that held six live applications, read through list_accounts and read_platform_usage under the operator's session at the change. It is recorded here because PLD-L0-96 owns the members and is not a statement of this document.
This clause's thirty-sixth use: the `starts_with` member of each row of `submit_manifest`'s `schedules` in `schemas/action_payloads.json`, an enumeration of four values and null becoming five values and null, with `the next deploy to production` added. That value names the act a production schedule awaits on an application with one environment, where a deploy reaches production (PLD-L0-96). The descriptions in `schemas/action_payloads.json` move with it. The platform then held one builder account that held six live applications, read through list_accounts and read_platform_usage under the operator's session at the change. It is recorded here because SCH-L0-07 owns the member and is not a statement of this document.
This clause's thirty-seventh use: the request member `tree` of `read_documentation` in `schemas/action_payloads.json`, which leaves the request's `required` list. Where `tree` is absent, the read takes the tree from a `page` route whose first segment is a tree's base path, and a call naming neither still refuses `invalid_request`. The descriptions in `schemas/action_payloads.json`, `schemas/management_api.json`, and `schemas/mcp_surface.json` move with it. The platform then held one builder account that held six live applications, no synthetic account standing, read through list_accounts and read_platform_usage under the operator's session at the change. It is recorded here because CTX-07 owns the reads and is not a statement of this document.
This clause's thirty-eighth use: the request members `application` and `environment` of `submit_feedback`, `read_feedback`, `rate_experience`, and `settle_feedback` in `schemas/action_payloads.json`, removed and `space` added in their place. A call names the space it addresses, and a call naming either removed member is refused `invalid_request` naming `space`. The descriptions in `schemas/action_payloads.json`, `schemas/management_api.json`, and `schemas/mcp_surface.json` move with it. The platform then held one builder account and six live applications, a synthetic account aside, read through list_accounts and read_platform_usage under the operator's session at the change. MAPI-18 states the rows and records the use beside them.
This clause's thirty-ninth use: the `application_spaces` member of `export_account`'s `feedback` in `schemas/action_payloads.json`, renamed `spaces`, each entry gaining `kind` and its `application` and `environment` admitting null. The member carries the account's own filings from each space the account owns, binds, or holds in custody for a standing pair. The description in `schemas/action_payloads.json` moves with it. The platform then held one builder account and six live applications, a synthetic account aside, read the same way at the change. It is recorded here because ACB-L0-47 owns the member and is not a statement of this document.
This clause's fortieth use: the request member `query` of `read_documentation` in `schemas/action_payloads.json`, which loses its `minLength`, so an empty query reaches the handler and is refused `invalid_request` in words saying what to send. A `query` naming no `tree` is now answered, searching every tree the connection may read, where it refused `invalid_request`. The descriptions in `schemas/action_payloads.json`, `schemas/management_api.json`, and `schemas/mcp_surface.json` move with it. The platform then held one builder account that held six live applications, a synthetic account aside, read through list_accounts and read_platform_usage under the operator's session at the change. It is recorded here because CTX-07 owns the reads and is not a statement of this document.
This clause's forty-first use: the `section` member of each `sections_unavailable` row in `read_platform_status`'s response in `schemas/action_payloads.json`, an enumeration of eleven section names becoming one of twelve with `settings` added after `azure`. The section itself is an added member of the response, answering each served value as stored, and the request's `sections` enumeration widens with it. The descriptions in `schemas/management_api.json` and `schemas/mcp_surface.json` move with it. The platform then held one builder account that held six live applications, read through list_accounts and read_platform_usage under the operator's session at the change. It is recorded here because PLD-L0-76 owns the document and is not a statement of this document.
This clause's forty-second use: the `contains` member of `read_logs`' request in `schemas/action_payloads.json`, on a `container` read. A non-empty `contains` there was refused `invalid_request` since the twenty-seventh use, and is now answered, the console's lines matched in the plane, while `level` and `field` stay refused. The `detail` member of the response is present on such an answer wherever the read fetched a line, a pod's answer among them, opening with the lines searched and matched. The descriptions in `schemas/action_payloads.json`, `schemas/management_api.json`, and `schemas/mcp_surface.json` move with it. The platform then held one builder account that held six live applications, a synthetic account aside, read through list_accounts and read_platform_usage under the operator's session at the change. It is recorded here because system:LGS-L0-15 owns the member and is not a statement of this document, PLD-L0-62's thirteenth paragraph stating the behaviour.
This clause's forty-third use: the request member `query` of `read_documentation` in `schemas/action_payloads.json`. An empty `query`, or one of white space alone, was refused `invalid_request` since the fortieth use, and is now read as if the call had left the member out, so a page read that carries one is answered. Its length and its type are judged first, on the value as sent. The member's description in `schemas/action_payloads.json` moves with it. The platform then held one builder account, a synthetic account aside, read through list_accounts under the operator's session at the change. It is recorded here because CTX-07 owns the reads and is not a statement of this document.
This clause's forty-fifth use: the `state` member of the backend actions, data transfer, and stored data measures in `read_usage`'s and `read_platform_usage`'s responses in `schemas/action_payloads.json`. On such a measure no pass has recorded a state for, it answered `unknown` whatever its `month_total`. It now answers `unknown` where `month_total` is null, and otherwise `unset` where `quota` is null and `ok` where that figure is below the warning fraction of `quota`. It answers `unknown` where that state would be `warning` or `over`, and the read writes nothing. The descriptions in `schemas/action_payloads.json`, `schemas/management_api.json`, and `schemas/mcp_surface.json` move with it. The platform then held one builder account and no synthetic account, read through list_accounts under the operator's session at the change. It is recorded here because ACB-L0-26 owns the states and is not a statement of this document.
This clause's forty-sixth use, the preparing form of `store_secret` and `rotate_secret` and the members their requests and responses gained for it, is recorded by MAPI-08, the statement that states that form.
This clause's forty-seventh use: `mint_upload_grant`'s request and response and `deploy`'s request and response in `schemas/action_payloads.json`. `mint_upload_grant`'s request gains `local_path`, held to the class the deploy call's `local_path` admits, and a call naming one outside it is refused `invalid_request`, in place of an answer that ignored the member. Its response gains `command` and `command_windows`, and `deploy`'s `upload` gains `command_windows` among its required members. `deploy`'s `local_path` now refuses `&`, `|`, `<`, `>`, and `^` too, as `store_secret`'s and `rotate_secret`'s `value_file` does. The descriptions in `schemas/action_payloads.json`, `schemas/management_api.json`, `schemas/mcp_surface.json`, and `schemas/skills.json` move with it. The platform then held one builder account that held six live applications, a synthetic account aside, read through list_accounts and read_platform_usage under the operator's session at the change. It is recorded here because OST-L0-08 and PLD-L0-86, which state the line, the member, the class, and the Windows form, are not statements of this document.
This clause's forty-eighth use: the `download` member of `read_library_entry`'s entry answer in the payload contract. Its `command` was a one-line script that wrote an entry's files alone, and is now the line that runs the turnzero-cloud command's `library take`, which also writes the entry's manifest row and installs a package's copy. The member gains `command_windows`, the same line for Windows, and `command` leaves its required members, so an entry whose name the line cannot carry is answered `next` alone. The descriptions in the payload contract, the tool catalog, and the skill rows move with it. The platform then held one builder account that held six live applications, and no synthetic account, read through list_accounts and read_platform_usage under the operator's session at the change. It is recorded here because LC-05 and PLD-L0-100, which state the line and the take, are not statements of this document.
This clause's forty-ninth use: `submit_manifest`'s request and response in `schemas/action_payloads.json`. Its request gains the optional member `local_run`, `true` alone, and a call naming any other value is refused `invalid_request`. Where the request names it, the response's `provisioning` carries `command`, `command_windows`, and `expires_at`. Its required members are `for` and `command`, and no longer the script's `address` and `sha256`, which a submission naming no `local_run` still answers. The descriptions in `schemas/action_payloads.json`, `schemas/management_api.json`, `schemas/mcp_surface.json`, `schemas/skills.json`, and `schemas/wire_errors.json` move with it. The platform then held one builder account that held six live applications, and no synthetic account, read through list_accounts and read_platform_usage under the operator's session at the change. It is recorded here because SEC-L0-07, DBS-L0-02, and SEC-L0-19, which state the member, the grant, and the line, are not statements of this document.
This clause's fiftieth use, the refusal of a call that names a member its action does not declare, is recorded by MAPI-22, the statement that owns the rule.
This clause's fifty-first use: `submit_manifest`'s response in `schemas/action_payloads.json`. Its `provisioning` member no longer carries `address` and `sha256`, and its one required member is `for`. Where the request names no `local_run`, the member carries `next`, one sentence naming `local_run`, on the MCP surface, and is absent over the wire. Where the request names it over the wire, a response that minted a credential states `credentials: withheld`, and none carries `credential` or `platform_credential`. Each response that carries the line carries `next` beside it, which says where the values are. The descriptions in `schemas/action_payloads.json`, `schemas/management_api.json`, `schemas/mcp_surface.json`, `schemas/skills.json`, and `schemas/wire_errors.json` move with it. The platform then held one builder account that held six live applications, and no synthetic account, read through list_accounts and read_platform_usage under the operator's session at the change. It is recorded here because SEC-L0-07 and DBS-L0-02, which state the member and what each surface answers, are not statements of this document.
This clause's fifty-second use: what the grant in `mint_download_grant`'s line reads on the storage file route, and the response's `detail` in `schemas/action_payloads.json`. Outside its export's folder the grant read each file of the application's other areas, and now reads one only where it was created by the time the export listed its stored files. A file created later answers 404 `no_such_file` where it answered 200. Where the export's row holds no instant, the grant reads the folder alone, and `detail` names a fresh export. The descriptions in `schemas/action_payloads.json`, `schemas/management_api.json`, `schemas/mcp_surface.json`, and `schemas/wire_errors.json` move with it. The platform then held one builder account that held six live applications, and no synthetic account, read through list_accounts and read_platform_usage under the operator's session at the change. It is recorded here because OST-L0-08, which states the reach, is not a statement of this document.
This clause's fifty-third use: the path members of five requests and `publish_library`'s `catalog` in `schemas/action_payloads.json`. `deploy`'s, `mint_upload_grant`'s, and `mint_download_grant`'s `local_path`, and `store_secret`'s and `rotate_secret`'s `value_file`, refuse a path that is `~` or opens with `~/` or `~\`, 400 `invalid_request`, where each answered a line that read or wrote under a folder named `~`. A `publish_library` call whose `begin` carries a catalog holding an entry name outside the form a take line carries is refused `invalid_request`, where it stored an entry no line could take. The descriptions in `schemas/action_payloads.json` and `schemas/library_catalog.json` move with it. The platform then held one builder account that held six live applications, and no synthetic account, read through list_accounts and read_platform_usage under the operator's session at the change. It is recorded here because PLD-L0-86 and LC-01, which state the class and the form, are not statements of this document.
This clause's fifty-fourth use: `submit_feedback`'s `issue` member and three refusals on the platform's own space, for a credential that does not read the queue. The member is null where MAPI-18 withholds the issue, where it was an object in every answer. The recovered mark answers the member's `id`, `status`, and `disposition` alone, where it answered the issue as the 0.2.0 wire gives it. A confirmation that names a restricted issue, and a recovered mark MAPI-18 does not relay, are refused where each was relayed. The description in `schemas/action_payloads.json` moves with it. The platform then held one builder account and no open invitation, read at the change.
This clause's fifty-fifth use: the `name` member of `mint_upload_grant`'s request in `schemas/action_payloads.json`. A name holding a backslash, or a segment that ends with a dot, is refused 400 `invalid_request`, where the call minted a grant for it, because the file route refuses a write of such a name (OST-L0-02). The same use records that `used` in `read_usage`'s `ai_allowance_units` now counts the units of a forwarded call that ended early (EGW-L0-06), an answer that moves with no member's shape moving, as the forty-fifth use's did. The two members' descriptions move with it. The platform then held one builder account and no synthetic account, read through list_accounts under the operator's session at the change. It is recorded here because OST-L0-02 and EGW-L0-06, which state the two rules, are not statements of this document.
This clause's fifty-sixth use: `record_check`'s `issue` and `check` members, for a credential that does not read the queue. The `issue` member carries the members a filing's answer gives of an issue and no report, where it carried the issue record whole. It is null where MAPI-18 withholds the issue, where it was an object. The `check` member carries no `lease` and no `held_by` member, and its own `issue` member is null where the answered `issue` is null, where each was as the service gave it. The descriptions in `schemas/action_payloads.json` move with it. The platform then held one builder account and no open invitation, read at the change.
This clause's fifty-seventh use: `store_secret`'s answer to a store that would add a name to an environment scope of an application that holds 100 names, refused 409 `secret_count_limit` before any write, where the store was answered. The descriptions in `schemas/mcp_surface.json` and `schemas/wire_errors.json` move with it. The platform then held one builder account, read through list_accounts earlier on the day of the change. It is recorded here because SEC-L0-21, which states the bound, is not a statement of this document.
This clause's fifty-eighth use: the admission window on every management action. A call to `list_library` or `read_library_entry`, which need no credential, from a source past three thousand such calls in the minute is refused 429 `rate_capped` where it was answered. So is a call to `list_context` or `read_context`, or one that names an action with no handler or no action, from a source past six hundred requests in the minute. The admission window's 429 `rate_capped` at the control plane carries a `Retry-After` header, the seconds to the next minute, where it carried none. The summary of `rate_capped` in `schemas/wire_errors.json` moves with it. The platform then held one builder account and no open invitation, read at the change. It is recorded here because PLD-L0-67, which states the window, is not a statement of this document.
This clause's fifty-ninth use: the request members `personal` and `excerpt` of `submit_feedback`, and the `personal` member of its response's `report`, in `schemas/action_payloads.json`. The request declares neither, and a call that names one is refused `invalid_request` where it was taken, its detail adding the sentence the request's `x-retired` carries. The descriptions in `schemas/action_payloads.json`, `schemas/management_api.json`, and `schemas/mcp_surface.json` move with it. The platform then held one builder account that held six live applications, and no synthetic account, read through list_accounts and read_platform_usage under the operator's session at the change. It is recorded here because the removal reaches two statements of this document, MAPI-18 for the members and MAPI-22 for the refusal.
This clause's sixtieth use: the admission window of a request that presents a credential on the storage, egress, logging, and push wires. A request there whose presented value resolves to no credential counts in a window its source has for such requests, and past six hundred of them in the minute is refused 429 `rate_capped` where it was answered 401 `authentication_required`. Every token of one end-user session counts in that session's one window, where each counted in its own. A request there in another letter case, or with a route's one trailing slash, counts as the path as written does, where it counted by its source. The summary of `rate_capped` in `schemas/wire_errors.json` moves with it. The platform then held one builder account and no open invitation, read at the change. It is recorded here because PLD-L0-67, which states the window, is not a statement of this document.
This clause's sixty-first use: `submit_feedback`'s answer to a confirmation that names a restricted issue, for a credential that reads the queue on the platform's own space and for any credential on a space the request names. The confirmation is refused 404 `not_found` as one naming no issue is, where it was relayed and linked, for a report the plane filed `field`, `beta`, `person`, or `test`, since the service confirms none of those onto a restricted issue (MAPI-18). The platform then held one builder account, one synthetic account, and no open invitation, read at the change.
This clause's sixty-second use: `submit_feedback`'s `issue` and `outcome` members where a filing's evidence matches a report on a restricted issue, on the platform's own space and on a space the request names, for a report the plane filed `field`, `beta`, `person`, or `test`. The `issue` member carries the unrestricted issue the filing joined or opened, and `outcome` reads `filed` where the filing opens an issue of its own, where it read `linked`. On the platform's own space the `issue` member was null for a credential that does not read the queue; for one that reads it, and on a named space, it was that restricted issue through the projection (MAPI-18). The platform then held one builder account, one synthetic account, and no open invitation, read at the change.
This clause's sixty-third use: `submit_feedback`'s recovered mark, for a credential that reads the queue on the platform's own space and for any credential on a space the request names. The mark is refused 404 `not_found` where the caller's filing under the key did not open the issue, or another reporter's report stands on it, where it was relayed and settled the filing (MAPI-18; the package's XIT-01). The platform then held one builder account, one synthetic account, and no open invitation, read at the change.
This clause's sixty-fourth use: what `relay_issue_act` answers a token below the `owner` level of its `issues` grant. A relayed `follow`, `update`, `comment`, `relate`, or `give_back` naming an issue ITS-L0-05 withholds is refused 404 `issue_refused`, as one naming no issue is, where it answered 200. A relayed `submit`'s or `check`'s `issue` member is null for such an issue, and a relayed `next` answers each member null, where each was as the service gave it. A relayed `arising_from` relation whose target has an issue identifier's form is refused 400 `invalid_request`, where it answered 200. A relayed `submit`'s report carries the origin `field`, where it carried the origin the body named, so one of the kind `question` or `task` is refused 400 `issue_refused`. The platform then held one builder account and no open invitation, read at the change. It is recorded here because ITS-L0-05 is not a statement of this document.
This clause's sixty-fifth use: `submit_manifest`'s `settings` rows on an application with one environment. The answer carries one row per setting, production's, where it also carried a row naming development. No deploy or promote of such an application reads the development scope, and an AI tool read that row's `stored: false` as a value to store. An application with both environments is answered both rows, as before. The platform then held one builder account and no open invitation, read at the change. It is recorded here because MAN-14 is not a statement of this document.
This clause's sixty-seventh use: `deploy`'s answered `state` in `schemas/action_payloads.json`, with one request member and one refusal. The answered `state` gains the values `awaiting_command` and `withdrawn`. The request gains the member `withdraw`, which the HTTP action route alone carries, and the response gains `command`, `command_windows`, `expires_at`, and `previous_code`. The refusal catalogue in `schemas/wire_errors.json` gains `deploy_code_refused`. The plane admits the member and answers the values, the members, and the refusal only where it serves the line form of `deploy`. Where it does not, a call naming `withdraw` on the HTTP action route is refused 400 `invalid_request`. The platform then held one builder account and no open invitation, read at the change. It is recorded here because PLD-L0-86, which states the line form and the deploy code, is not a statement of this document.
This clause's sixty-eighth use: `deploy`'s request and its answers in `schemas/action_payloads.json`. `zip_sha256` is marked wire-only beside `withdraw`: the MCP tool declares neither, and a tool call naming either is refused 409 `local_route_required` where it prepared an upload. A call naming none of `zip_sha256`, `artifact`, and `upload` answers the line form, 200 `awaiting_command`, where it drew 400 `zip_sha256_required`, and that row leaves `schemas/wire_errors.json`. The preparing call's answer gains `upload.grant`, and `upload.command` and `upload.command_windows` carry that value where each carried a line. At the preparing form a grant-form bearer resolving to no credential is refused `deploy_code_refused` where it drew `authentication_required`, and a start under a session or token of an upload a later deploy call ended is refused `upload_not_found`. The platform then held one builder account and no open invitation, read at the change. It is recorded here because PLD-L0-86 owns the members and is not a statement of this document.
This clause's sixty-ninth use: `deploy`'s answer to a deploy, by the artifact or the upload form, to an environment that holds no serving version, whose zip names its manifest's health path in no source file. It was answered 202 and started, and is now refused 400 `health_path_unserved` before any write, a row the refusal catalogue in `schemas/wire_errors.json` gains. The platform then held one builder account and no open invitation, read at the change. It is recorded here because PLD-L0-63, which states the check, is not a statement of this document.
This clause's seventieth use: `read_logs`' answer in `schemas/action_payloads.json`. A `container` read that was refused `never_deployed` where the environment names no compute is answered where a failed first deploy's or first promote's health check kept a record, and the answer gains the member `failed_check`. The platform then held one builder account and no open invitation, read at the change. It is recorded here because PLD-L0-59, which owns the behaviour, is not a statement of this document.
This clause's seventy-first use: what `relay_issue_act` answers a `contribute`-level `issues` grant, which the sixty-fourth use recorded for every level below `owner`. A relayed `list` answers a restricted issue it left out, and a relayed `read` answers one it refused 404 `issue_refused`. A relayed `update`, `comment`, `relate`, or `give_back` naming one now reaches the service, once refused 404 `issue_refused`. A relayed `submit`, `check`, or `next` answers such an issue whole, once null, with no lease given back. A relayed `update` whose `fields` name `restricted` with any value but `true` is refused 403 `issues_level_refused`, where it answered 200. A relayed `follow` naming one is still refused 404 `issue_refused` by the service, its report carrying the origin `field`. The platform held 1 builder account and 0 open invitations, read at the change; ITS-L0-05 is not a statement of this document.
This clause's seventy-second use: `deploy`'s answer at its wire preparing form to a deploy code whose minting credential no longer stands, a token revoked or expired or a session ended since the mint. It was admitted where the code's own end was not written, and is now refused 403 `deploy_code_refused`, alike to an unknown code's answer. A code a session minted on the earlier revision is refused so once. The same use has `reinstate_account` refused with the store's failure, the account still suspended, where ending its codes fails, and a session's code answer an `expires_at` no later than its session's expiry. The platform then held one builder account and no open invitation, read at the change. It is recorded here because PLD-L0-86 is not a statement of this document.
This clause's seventy-third use: the lookup limit on the storage, egress, logging, and push wires. A request whose presented value the gateway cache does not hold, and whose lookup cannot start within the wait bound, is refused 503 `credential_lookup_busy` with `Retry-After` of one second, where it was looked up. Through the edge, such a request from a source at its bound for unresolved values is refused 429 `rate_capped` before its lookup, where a value that then resolved was admitted. The `credential_lookup_busy` row and the summary of `rate_capped` in `schemas/wire_errors.json` move with it. The platform then held one builder account, a synthetic test account beside it, and no open invitation, read at the change. It is recorded here because PLD-L0-67, which states the limit, is not a statement of this document.
This clause's seventy-fourth use: the token code form's dark leaves in `schemas/action_payloads.json` and `schemas/wire_errors.json` (MAPI-23), each answered only where the token code form is served. `mint_token`'s request gains `code_challenge`, `authorized_computer`, and the wire-only `code_verifier`. Its response gains `state`, `command`, `command_windows`, `expires_at`, and `detail`; `value` leaves its `required` list, and `id`, `created_at`, `revoked_at`, and `last_used_at` leave the `token` object's, each form's description declaring its own; and the `token` object and `list_tokens`'s rows gain `authorized_computer`. The row `token_code_refused` joins the refusal catalogue, additive (MAPI-15). The settings enums of `set_status_setting` and `read_platform_status` gain `token_code_seconds`, served whatever the switch. The platform then held one builder account, a synthetic test account beside it, and no open invitation, read at the change. Its owner is MAPI-23, a statement of this document.
This clause's seventy-fifth use: the action `rotate_realm_keys`, renamed `revoke_realm_keys` with its MCP tool, because the act revokes the realm's session signing keys (ACS-L0-08). The owner approved the rename. Over the actions route a call naming the old name answers 404 `unknown_action`, its detail naming `revoke_realm_keys`, and the tool surface moves with MCP-08's revision 2. The descriptions in `schemas/action_payloads.json`, `schemas/management_api.json`, `schemas/mcp_surface.json`, and `schemas/wire_errors.json` move with it. CQ-97's three action renames within version 1 are the precedent. The platform then held one builder account and no standing synthetic account, read at the change. It is recorded here because ACS-L0-08, which owns the action, is not a statement of this document.
This clause's seventy-sixth use: the value `redeploy` of the `kind` member of each row in `list_versions`' response, of the `deploy` member in `read_status`'s response, and of `failed_check` in `read_logs`' response in `schemas/action_payloads.json`, renamed `restart`. The versions table's stored value, the stores that read it back, and the mark-redeploy pass keep the name `redeploy`, and the answers write `restart` for it, as the seventeenth use kept `heartbeat_at`. The descriptions in `schemas/action_payloads.json`, `schemas/management_api.json`, and `schemas/mcp_surface.json` move with it. The platform then held one builder account and no standing synthetic account, read at the change. It is recorded here because PLD-L0-63 owns the member and is not a statement of this document.
This clause's seventy-seventh use: the realm member `routes`, renamed `sign_in_methods` in `configure_realm`'s request and answer, in `read_realm`'s and `export_account`'s answers, and in the manifest's `realm` member. The control database's column `realms.routes` keeps its name. `configure_realm`'s request carries MAPI-22's `x-renamed` for `routes`, so a call naming it is refused `invalid_request` naming `sign_in_methods`. A recorded manifest naming `realm.routes` is read under `sign_in_methods`. A submitted one is refused `manifest_invalid` at `/realm/routes`, its detail naming `sign_in_methods` and the one-line edit that renames the member. The descriptions in the payload contract, the tool catalog, the API schema, and the manifest schema move with it. The platform then held one builder account and no standing synthetic account, read at the change. It is recorded here because ACS-L0-07 owns the member and is not a statement of this document.
MAPI-03 (decided): A credential is a bearer credential presented per request, never carried in a URL, and it is one of four kinds: the **session credential**, the **minted token**, the **platform credential**, and **no credential**. Beside them, the third, eighth, and ninth paragraphs admit four short-lived grants, each on the requests its act admits and on nothing else. The session credential is minted by a present person's sign-in and takes three forms. The first is the bearer session the OAuth flow issues (MCP-02's binding). The second is the browser credential the approval page runs under (MAPI-05) and the signed-in site's server-rendered pages run their acts under through the one seam (WEB-L0-16; CQ-63), no credential on the wire. The third is the browser session, the API cookie of the browser leg (WEB-L0-16), which the actions routes alone admit as a wire credential under a guard of their own (CQ-43).
The **minted token** of API-L0-05 is created by a session through `mint_token` and bounded at its minting to the account or to one application (API-L0-17; MAPI-14); the CI credential and the application-bounded builder credential are this one kind under its two scopes. The **platform credential** of SEC-L0-07 is admitted here by `read_account` alone. The fourth kind is **no credential**, on the rows MAPI-11 marks anonymous.
A credential the platform issues for a data-plane act alone is refused by name on every action of this contract, but for the start of an upload that `deploy` admits under that upload's own grant (OST-L0-08; PLD-L0-86; CQ-186). Those are the end-user credential the accounts service issues, the transfer grant object storage mints, and the egress key the platform mints for one upstream of one compute (SEC-L0-18), each stated by its own surface. The secret grant, which the platform mints for one custody act, is admitted on `store_secret` and `rotate_secret` over the wire for the requests its act admits, and on nothing else (SEC-L0-19). Every other action, and a request the grant's act does not admit, refuses it `secret_grant_not_admitted`, but for the rules the sixth paragraph names. A request it admits is refused `secret_grant_spent` once the grant is spent, and `secret_grant_expired` once it has expired unspent.
A bearer of a grant's form that resolves to no credential is refused `authentication_required`, with the challenge MCP-02 states for a presented credential that resolves to nothing. Such a bearer is a grant never minted, a grant whose record the platform has removed after its expiry or with its application or account, or a value that differs from the one minted. No record answers, so the refusal names no kind of grant. Its detail says that the platform serves no grant of that value, and that a grant lasts minutes and serves the one act its mint names. It names both ways to a fresh grant: a tool call whose answer carried the grant is made again and the fresh command it answers is run, and an application that requested the grant requests another. At `deploy`'s wire preparing form the eighth paragraph's refusal answers such a bearer instead.
The browser session is read only from a same-origin JSON post that presents no `Authorization` header and is verified as the dashboard guard verifies its cookie. It is admitted only on an action whose catalog row names both `bearer` and `browser_session` among its clients, every other action refusing it `authentication_required` before any store read. A state-changing action under it past the freshness window WEB-L0-16 states is refused `fresh_authentication_required`. It runs on the `browser` surface, which is answered no credential value (SEC-L0-07). Every other surface, `/mcp` and the data-plane surfaces among them, keeps resolving the `Authorization` header alone. The authority tiers bind per credential (API-L0-06): what a credential may do is its grant, the destructive class is deny-until-granted, and no client kind carries a laxer tier than any other (API-L0-11).
This paragraph names the rules that answer a request presenting a secret grant ahead of the third paragraph's refusal. A browser-only action reads no credential and refuses any bearer `browser_session_required` (MAPI-05). An anonymous read reads none either, and answers as it answers a request that presents no credential (MAPI-11). An action switched off reads the grant and refuses by its switch's name (MAPI-16). None of the three admits the grant to anything.
A secret grant whose act is `provision` is admitted on `rotate_secret` over the wire for its application's two platform-minted names at the development scope, each once (SEC-L0-19). The request names no value and carries no member beyond the name, the application, and the environment. A second re-mint of a name is refused `secret_grant_spent`. `submit_manifest` takes the member `local_run`, which asks for that grant's line: `true` alone, on the MCP surface and over the wire under a bearer credential. Any other value, and the member on a surface that is answered no credential, is refused `invalid_request` with nothing recorded.
This paragraph adds the deploy code to the third paragraph's short-lived grants (PLD-L0-86). A deploy code is admitted at `deploy`'s wire preparing form, once, for the requests its act admits, and on nothing else. At that form an unknown, a spent, and an expired code, and a bearer of a grant's form that resolves to no credential, are refused 403 `deploy_code_refused`, in place of the fourth paragraph's refusal. On every other request a deploy code resolves to no credential and is answered as the fourth paragraph states, unspent.
This paragraph adds the token code to the third paragraph's short-lived grants (MAPI-23), where the token code form is served. A token code is admitted at `mint_token`'s wire exchange form, once, for the one exchange its mint names, and on nothing else. At that form an unknown, a spent, and an expired code, and a bearer of a grant's form that resolves to no credential, are refused 403 `token_code_refused`, in place of the fourth paragraph's refusal. On every other request a token code resolves to no credential and is answered as the fourth paragraph states, unspent. A transfer grant, a secret grant, or a deploy code presented at the exchange form is answered as this statement and PLD-L0-86 state, unspent.
MAPI-04 (decided): Every action carries its tier in the enumeration — observe, reversible, destructive — and the tier governs the call's shape. An observe action changes nothing and may be repeated freely. A reversible action completes in the call that made it or, where its own statement says so — `run_schedule`, `deploy`, `promote`, `roll_back`, `restart_application`, and `purge_synthetic_accounts` —, records the act and answers at once, its outcome read through the observe act that statement names. Of these, `run_schedule` and the four acts the sixth paragraph names answer at once unless the request's `wait_seconds` holds the answer, as that paragraph states. A retried reversible call is a second call of the action, what a repeat does being each action's own statement's to say.
A destructive action accepts a client-supplied request identity, the optional `request_id` member of its request, so a retried request lands on the same pending action once rather than creating a second one, because the callers are AI tools, and retry-on-timeout is how they behave. MAPI-05 states the match.
No reversible request schema in `schemas/action_payloads.json` carries a request identity the plane ignores. The twelve that did — `suspend_account`, `reinstate_account`, `mint_token`, `revoke_token`, `set_egress_mode`, `configure_realm`, `revoke_end_user`, `reinstate_end_user`, `issue_invitation`, `revoke_invitation`, `set_plan`, `set_plan_quota` — lost the member as MAPI-02's second paragraph records, and a call naming it is refused as MAPI-22 states. `run_schedule`'s required `request_id`, which its own code reads, is not within that removal, what its repeat answers being that action's own statement's to say. The optional `request_id` of `seed_synthetic_accounts` and of `purge_synthetic_accounts` is a member of the same kind, read by their code, each repeat answering as MAPI-16 states.
This paragraph qualifies the first paragraph's clause that an act answered at once has its outcome read through an observe act. Two such reads, the status read `read_status` and the schedule read `read_schedules`, take an optional request member `wait_seconds`, an integer from 1 to 45, and hold their answer until nothing they wait for is in flight. For the status read that is any version-history row of the application still `deploying` (PLD-L0-63); SCH-L0-06 names the schedule read's. The payload schema states the range, which the MCP argument layer holds, and the handler refuses a value outside it `invalid_request` itself, because the HTTP route validates no member's value (MAPI-02). A held read reads the store every two seconds and stops polling at `wait_seconds`, counted as the seventh paragraph states. It then answers as the read always does, adding `settled`, true where its last store read found nothing in flight, and `waited_ms`.
This paragraph bounds the held read the paragraph above states. A held read's last store read is the read that composes its answer, which the fourth paragraph's `settled` reads, and each early end below answers `settled` from that read. A read that finds nothing in flight answers at once. A process holds at most one held read per application and fifty in all, and a read beyond either answers at once. The deploy command's progress read holds one place per upload, never an application's, counted in the fifty and stopping at its route's 25 seconds (PLD-L0-86). A held read answers at once when its process begins to shut down, before the listener closes, and ends when the caller's connection closes. An answer of an act of the sixth paragraph that did not settle names the wait in its `detail`, and `run_schedule`'s answer without one names both waits by their actions.
This paragraph extends the fourth paragraph's held read to the four acts that start a version-history row, `deploy` in either of its starting forms, `promote`, `roll_back`, and `restart_application` (PLD-L0-63; PLD-L0-84; PLD-L0-86), and to `run_schedule`. Each takes the same `wait_seconds` and holds its answer until the row it started ends, answering as PLD-L0-63 states, or for `run_schedule` until its run ends (SCH-L0-06). Each hold is a held read of this statement, polling as the fourth paragraph states and bounded as the fifth states. So an act's hold takes its application's one held place, and a concurrent held read of that application on the same process answers at once. An act that finds the place taken answers at once, its `settled` from its own row or run. `deploy`'s line-form and preparing calls start no row: each holds nothing and carries the member into its `next`, 45 where absent.
This paragraph bounds every wait this statement states by the call's own time. A held read or act stops polling once `wait_seconds` have passed since its credential was admitted, so the time an act spends before its hold, a slow artifact read among them, is spent from its wait. A `container` read's wait stops at the earlier of its `wait_seconds` and forty seconds, so a value above 40 is held 40. The hold adds nothing past that point but the final read's own time, so an answer whose work before the hold took less than its wait stays under fifty seconds. On the wire, a value outside 1 to 45 is refused `invalid_request` by the handler, its detail naming 45 as the most the member admits, for the three reads and the held acts alike. Over MCP the argument layer refuses it first, its text naming the same bound.
This paragraph extends the fourth paragraph's held read to the log read `read_logs` on a store source. It takes the same `wait_seconds` and holds its answer while the read with the call's own filters finds no entry, answering from a fresh read with `waited_ms` and no `settled`. Its hold is a held read of this statement, polling, bounded, and placed as the fourth, fifth, and seventh paragraphs state, and an empty answer whose wait found the place taken says so in its `detail`. A `container` read carrying the member holds as the twelfth paragraph states and never polls, because each console read is a query to the provider.
This statement records the twenty-second use of MAPI-02's clause on a member's shape, which MAPI-02 names among its uses. The request member `wait_seconds` of `read_status` and `read_schedules` in `schemas/action_payloads.json` narrows from 1 to 50 to 1 to 45, so a value from 46 to 50 that the reads admitted is refused `invalid_request`. The reads never polled past 45 seconds, so the narrowed range states the bound they honoured. The platform then held one builder account that held seven live applications, the synthetic estate's one account aside, read through list_accounts and read_platform_usage under the operator's session.
This paragraph names the one home of the waits' figures. One set of code constants holds the range, the poll, the polling stop, and the cap for the reads and the held acts, and the `container` wait's stop and its cap on followed consoles beside them. The deploy command's progress read takes its stop from its route (PLD-L0-86).
This paragraph qualifies the sixth paragraph's held acts and the first paragraph's retried call. An answer to one of those acts that is not the platform's own, an edge's error page or a closed connection among them, says nothing about whether the act was made. The server's instructions (MCP-05) and each act's description say so, and send the caller to the act's status read first, `read_status`, or `read_schedules` for `run_schedule`. One of the four acts started only where its environment's `deploy` member names the kind of row the act starts, with a `started_at` later than the call. A deploy's upload that `pending_upload` still names was not started, and its `retry` starts it. Each of the four acts is repeated only where that read shows no start, and `run_schedule` only with the same `request_id`, as its own statement says. What a repeat does stays each act's own statement's to say.
This paragraph extends the eighth paragraph's wait to a `container` read, which holds by following its console instead of polling. Where the operator's `console_live_tail` is 1 (PLD-L0-62), the read takes the application's one held place first. It then follows the console of each running instance of the serving compute and of a deploy's candidate, three at most, or of a pod's newest instance, beside the console store's read on the container grain. It holds its answer until a followed or stored line the call's filters admit, stamped at or after its `since`, is read, or until the seventh paragraph's stop. It answers as a `container` read does, every line its follows read merged in, with `waited_ms` and no `settled`. Where nothing runs, or every follow has closed, it lists the instances once more ten seconds later and follows a newcomer, never listing a third time.
This paragraph bounds the twelfth paragraph's wait. A process holds at most nine followed consoles beside the fifty held reads, and a wait following none counts one. A wait that finds the switch at 0, the place taken, the process's nine follows held, or, on the pod grain, no pod at its one more listing answers at once as an ordinary `container` read, its `detail` naming which. On the container grain, each listing reads the management API's remaining reads from its first answer; below fifty the wait answers at once with the lines read so far, and it lists a second time only where at least one hundred remain. A deploy, a promote, and a roll back do not read that figure, so fifty is what a burst of waits leaves them. The wait ends on the caller's close and at the process's shutdown, and each end closes every follow.
This statement records the sixty-sixth use of MAPI-02's clause on a member's shape. The request member `wait_seconds` of `read_logs` in `schemas/action_payloads.json`, refused on a `container` read, is now admitted there as the twelfth paragraph states. The descriptions in `schemas/action_payloads.json` and `schemas/mcp_surface.json` move with it. The platform then held one builder account that held six live applications, a synthetic account aside, read through list_accounts and read_platform_usage under the operator's session at the change.
This paragraph qualifies the twelfth paragraph's hold on the pod grain. A pod wait whose last follow closes after its one more listing, as when the pod's process exits, answers at once with the lines read so far and no sentence on how it ended, since a pod's console ends with the pod.
This paragraph qualifies the twelfth and thirteenth paragraphs for a `container` read answered from a failed check's kept lines (PLD-L0-59). That read reads the version row, not a console, so it takes no held place and answers at once, its `detail` saying so.
MAPI-05 (decided): The pending action is a resource of this contract: a destructive action's request creates one, and its record carries Turn Zero Cloud's own description of what will be destroyed. The one action that completes it — approval — is callable only by a signed-in person's browser session (WEB-L0-13), a client restriction the enumeration states and the suite refuses violations of. The requesting credential reads the record and its outcome; nothing but the browser approves. The request's `request_id` member is the pending action's request identity (MAPI-04): a string the caller chooses, matched by equality and never interpreted.
A second request carrying the same `request_id`, from the same requesting account, for the same action, while the earlier record is live (approved or executing, or requested and not past its expiry), answers that record, its approval link included, and creates no second one. A record that is no longer live — completed, failed, declined, expired, or requested and past its expiry — matches nothing, so the same `request_id` then starts a new pending action. A request carrying no `request_id` is matched to no earlier request, each such call creating its own pending action.
The match runs after the destructive request has passed the credential gates and its description has been produced, so a request that refuses by name refuses on every repeat and matches nothing. The subject named by a repeat is not compared, the caller's identity being the caller's to keep distinct. The durable store holds the match as one partial unique index over requesting account, action, and request identity on the live states. A test in the platform's suite holds the match, the per-account separation, the release after a decline, the unmatched case, and the lapsed case.
MAPI-06 (decided): Every action writes the append-only operational record — actor, credential, action, subject, outcome, any confirmation, and, on a dispatched call's row, the reference the call's answer carries (API-L0-19) — from the first action of C2 onward. **The credential is recorded as itself and not only as its kind**: its kind always, and its own identity wherever it has one, which an unattended token does and a browser session does not (API-L0-05; MAPI-03). Without that, every act a credential performs is indistinguishable from every other act of the account that minted it, and an automated publish running unattended reads in the record as the person doing it by hand. Telling the two apart is the one thing the record exists to be able to answer.
The record is readable and exportable by no served surface: it exists so that the platform's own operation has a durable account of what was done, not so that a customer or an operator can query one. Three readers inside the platform stand. Two join on the record's reference column under an account and near the call's time, because the reference is not unique across the record's retention (API-L0-19). The third reads a named action's completed calls inside a window of time. No served surface reads the record, and no export carries it.
The daily pass's feedback step answers two bits for a report's quoted reference, whether such a row stands and whether it records a refusal, and never a row, and marks the report at the issue service (PLD-L0-67). A filing's stamp reads the action, the outcome, the build, and the code site of the filer's own call, or of a call of a batch its token seeded (MAPI-18). The same step's exposure read answers each completed call of a fixed issue's action with its account, reference, instant, and build (PLD-L0-67).
Recording is never deferred to a reader's arrival, because a record that begins when a reader arrives is not a record, and it is buffered for at most one second. Every action's record is appended to the plane's meter buffer as the action completes and flushed to the `action_records` table within one second or two hundred rows, after the caller is answered. So a process end loses at most one flush interval of records, and no reader is ever the trigger (CQ-36). The table is monthly range partitions dropped after twenty-five months, every row carrying the environment.
A row the store refuses loses that row alone. A flush statement that fails twice is written again one row to a statement, and the rows the store refuses alone are dropped and reported once for the table in a flush, together with the table and their count. Two cases drop a failed statement's rows whole, reported, with no row written alone. One is a statement whose connection dropped after it was sent, because the store may already hold its rows. The other is a store the plane could not reach across its failover window or within a checkout, because a row-by-row write would wait that out once for each row (PLD-L0-67). A store lost inside the row-by-row write ends it, and the row it failed on and the rows not yet written are dropped and reported together, with their count, in a report apart from the rows refused alone.
The logging feature package (Q-226) owns the operational record once Turn Zero Cloud consumes it and the record writes through — raised in that package's PRD §5 — and this statement is re-parented to it then.
MAPI-07 (decided): A manifest change is the `submit_manifest` action on the application resource: validated against the manifest contract with refusals naming the failing path (MAN-12), applied as one deliberate action, recorded like every action (MAPI-06). Nothing else in the contract widens an application's declared reach, which is what ADM-L0-07's no-side-effect promise means here.
MAPI-08 (decided): The MCP tools are these actions, one to one and name for name: every tool of `schemas/mcp_surface.json` is an action of `schemas/management_api.json` at the same tier. Every action callable by AI clients is a tool — the browser-only actions are the one exception, absent from the tool surface by MAPI-05's restriction. The correspondence covers the call and not only the name: a tool declares the arguments its action accepts, derived from that action's request schema in `schemas/action_payloads.json`, so what a caller can express over the wire it can express as a tool.
One exception, on answers, owned by SEC-L0-07: an application's standing credential value is answered on the wire surface alone. So `submit_manifest` as a tool withholds its two value members and states `credentials: withheld`, and the two development re-mints of `rotate_secret` are refused as a tool, `local_route_required`, and answered on the wire. Those tools declare the same arguments as their actions, save a member marked `x-wire-only`, and the difference is in the answer alone. An exception to the listing rule, owned by MAPI-16: the two rows the enumeration marks `switch: synthetic_estate` are listed as tools while the synthetic estate's posture, the control plane's setting `SYNTHETIC_ESTATE` (MAPI-16), is not `off`. They are unlisted while it is `off`, their wire routes standing and refusing `synthetic_estate_disabled` by name.
An exception to the argument rule, owned by SCRT-L0-02 and CHI-L0-08 for a secret's value, by PLD-L0-86 for `deploy`'s members, and by MAPI-23 for `mint_token`'s: a tool declares no request member the schema marks `x-wire-only`, a member the HTTP action route alone carries. Those members are a secret's value, and three the turnzero-cloud command alone names: `deploy`'s `zip_sha256` and `withdraw`, and `mint_token`'s `code_verifier`. A host may keep a tool call's arguments in its transcript, so `store_secret` and `rotate_secret` mark `value` and take it on the HTTP action route alone, under a bearer credential, a secret grant, or the browser session. Their tools take no value: a tool call naming a name of the caller's own is the preparing form the next paragraph states, save a `store_secret` call naming `generate`, the creating write SEC-L0-20 states, and `rotate_secret`'s platform-minted names keep the answers above.
A `store_secret` or `rotate_secret` call that names a name of the caller's own and no `value`, and on `store_secret` no `generate`, is the preparing form (SEC-L0-19). It is answered through the tool and on the HTTP action route under the caller's own bearer credential, and under the browser session it is refused `invalid_request`. It writes nothing, mints a secret grant for the one write it names, and answers `state` as `awaiting_value`, `expires_at`, and the line that makes that write as `command` and `command_windows` (PLD-L0-94). A rotation's answer carries `next`, the `restart_application` call to make, where MAN-14 names one. The call may name `value_file`, the path the line reads the value from, which the tools declare, and a call naming it beside `value` is refused `invalid_request`. A tool call whose arguments carried a `value` is answered the same form with `note`, which says the platform neither read nor stored that value.
A `store_secret` call naming `generate` is no preparing form: it writes in the call on every surface and answers no value (SEC-L0-20). The `store_secret` tool declares `generate`, which carries no value, and the `rotate_secret` tool declares none. A tool call that carried a `value` and named `generate` is refused as SEC-L0-20 states, not answered the preparing form.
`code_verifier` is the exchange's one member, read on the HTTP action route where the token code form is served (MAPI-23). An MCP call of `mint_token` naming it is refused 409 `local_route_required` with nothing minted, read through the mark as `deploy`'s handler reads its two, and a wire call naming it under any credential but a token code is refused 400 `invalid_request`.
This statement records the thirty-fourth use of MAPI-02's under-one-hundred-accounts clause, because it owns the argument derivation. The `value` member of `store_secret`'s and `rotate_secret`'s requests in `schemas/action_payloads.json`, until then declared by both tools, is marked `x-wire-only` and leaves both tool shapes, the HTTP route keeping it. The platform then held one builder account that held six live applications, synthetic accounts excluded, read through read_platform_usage under the operator's session at the change.
This statement records the forty-sixth use of MAPI-02's under-one-hundred-accounts clause, because it states the preparing form: `store_secret`'s and `rotate_secret`'s requests and responses in `schemas/action_payloads.json`. `store_secret`'s `value` leaves the request's `required` list, and both requests gain `value_file`. Through the tool or on the HTTP route under the caller's own bearer credential, a call naming a name of the caller's own and no `value` writes nothing and answers the preparing form, in place of `local_route_required` and `invalid_request`. Both responses gain `state`, `expires_at`, `command`, `command_windows`, and `note`, and `rotate_secret`'s gains `next`. The response members `stored` and `rotated` widen from the constant true to a boolean, false on the preparing answer. The descriptions in `schemas/action_payloads.json`, `schemas/management_api.json`, `schemas/mcp_surface.json`, `schemas/skills.json`, and `schemas/wire_errors.json` move with it. The platform then held one builder account that held six live applications, a synthetic account aside, read through list_accounts and read_platform_usage under the operator's session at the change.
The rows the enumeration marks `grant: synthetic_estate` (MAPI-09) are the synthetic estate's five (MAPI-16), the operator signal's (MAPI-17), and `record_check` (MAPI-18). Each is listed to a connection whose credential holds that grant or `super_admin`, or is bounded by a grant the row's `admits` mark names, and to no other connection. That listing is MCP-08's derivation from the enumeration's own mark under MAPI-09's rule that `super_admin` admits every grant-marked row. A connection whose token that grant bounds is listed the rows the grant marks, the rows the enumeration marks `admits: ["synthetic_estate"]`, and the rows marked `access: anonymous`, and no other row (MCP-08; MAPI-16). An argument list authored beside that contract is a served form owning content, which CTX-03 forbids.
The suite holds the bijection and the argument derivation with it. So the MCP surface cannot grow a capability this contract lacks, nor this contract an AI-callable action the surface hides. Nor can a tool's action take an argument the tool cannot carry, save a member marked `x-wire-only`, which the wire alone carries.
MAPI-09 (decided): The super-admin's actions are enumeration rows like any other, marked `grant: super_admin`, the grant that exists only in Turn Zero's own accounts (ACB-L0-71), per credential and never by default. A row carries one grant mark. `super_admin` admits every grant-marked row whichever grant marks it: the dispatcher's grant gate admits a credential holding the row's grant or `super_admin`. The gate also admits a credential whose bounding grant the row's `admits` mark names (MAPI-16). A credential holding a narrower grant alone reaches, among the grant-marked rows, those marked with that grant, those whose `admits` mark names it where it bounds the credential, and no other.
The operator set that carries `super_admin` is the control plane's setting `SUPER_ADMIN_IDENTITIES`, comma-separated entries of the form `<provider>:<subject>`. The provider is one of the builder realm's two federated providers, `google` and `github`, and the subject is the provider's stable subject as the realm's identity row stores it, never an address. A process refuses its boot by name on an entry with no provider or no subject, a provider outside the two, or a subject carrying `@`. A release meets that refusal at its readiness step, the prior revision still active (PLD-L0-65).
The grant a session carries is read live and stored on no user or session row. Where a builder session, the dashboard cookie, or the browser action route resolves to a credential, the account's bound identities are read with the realm user's row. The credential carries `super_admin` where one of them is in the set. An entry removed from the setting therefore ends that grant at the next request. A token minted under `super_admin` keeps the grants its minting fixed (MAPI-14) until `revoke_token` ends it. So taking the entry out of the setting leaves the operator tokens the person's sessions minted working until each is revoked. The person's removal ends them in the same sitting, by `revoke_token` under a session of their own account or by `suspend_account` on it where that cannot be done (API-L0-12).
A reader that needs the operator accounts themselves, the catch-all purge (MAPI-16), the schedule-runs condition and the unlimited plan's signals (PLD-L0-83), and `set_unlimited_plan` (ACB-L0-85), resolves each entry to the account its identity has opened at each run. An entry whose identity has opened none resolves to none. The same value stands on every estate the register names (PLD-L0-85). A `google` entry names one person on each, the estates sharing one Google client (CRD-03), and a `github` entry admits only where the estate offers GitHub sign-in (CRD-02).
The inventory marked `grant: super_admin` is sixteen rows. They are enumerating accounts with standing, and reading one account's control-plane record, its standing, meters, and health, never its tenant data (ADM-L0-10). They are suspension with its reinstatement, `revoke_product`, the removal of one product profile from an account on suspension's pattern (API-L0-12; ACB-L0-76), and `set_account_unbilled`, the marking of an account unbilled, the company's own or a complimentary one, on the same pattern (ACB-L0-84). They are `rotate_issue_space_token`, re-minting a disclosed account space token on the same pattern (CRD-24; API-L0-12). They are `set_egress_mode` (EGW-L0-17; API-L0-12 as amended) and `set_unlimited_plan` (ACB-L0-85), the two marked rows whose subject is an application rather than an account. The grant widens the subject an operator credential may name to any account's application, `set_unlimited_plan` admitting an operator account's alone. What each row writes is the platform's own record, the enforcement posture or the plan, never the application's data.
The rows continue with the two control-plane reads of the logging service, `read_control_plane_logs` and `read_control_plane_counters` (LGS-L0-17), whose subject is the control plane's own record and no account. `set_plan_quota` is the company's act on the platform's served plan quantities on `publish_library`'s pattern, naming no customer account (PRC-L0-16; API-L0-12 as amended). `read_platform_usage` is an enumeration across accounts on `list_accounts`'s pattern (ACB-L0-79; API-L0-12 as amended). The operator status record's three rows are `read_platform_status`, the reading of the platform's own status document, `record_incident`, the hand-recorded incident, and `set_status_setting`, the record's served values (PLD-L0-76; PLD-L0-77; API-L0-12 as amended). Those three are the company's act on the platform's own record naming no customer account, on `set_plan_quota`'s pattern.
The synthetic estate's five rows, `seed_synthetic_accounts`, `purge_synthetic_accounts`, `read_synthetic_purge`, `read_synthetic_signin_code`, and `read_synthetic_account_state` (MAPI-16), are the company's act on the company's own test fixtures, naming no customer account (ACB-L0-79). They are marked `grant: synthetic_estate` instead, the third grant beside the destructive class and `super_admin`, given on MAPI-14's terms. The operator signal's row, `record_operator_signal`, the act by which a company test harness reports a run's ending (MAPI-17), carries the same grant. So does `record_check`, the harness's posting of one run of a monitored check into the platform's own space, on the operator signal's pattern (MAPI-18).
Among the grant-marked rows the grant admits those seven alone, and it bounds the token that carries it. A minted token holding `synthetic_estate` and not `super_admin` is admitted to those seven rows, to the rows the enumeration marks `admits: ["synthetic_estate"]`, and to the rows marked `access: anonymous` (MAPI-11), and is refused every other row of the account by name. A token minted with both grants is `super_admin`'s and is bounded by nothing. What the narrow grant reaches within each row, what within them stays `super_admin`'s alone, and the bound with its refusal, MAPI-16 states.
Publishing the system library, `publish_library` (API-L0-14), and publishing the public files, `publish_public_files` (PLD-L0-68), are each the company's own act on the company's own content naming no customer account at all. They are marked `grant: publication` instead, the fourth grant, given on MAPI-14's terms and bounding the token that carries it as MAPI-16 states. So the publisher's token, held on disk for those two acts alone (CRD-01), reaches them and the anonymous rows and no other row, where under `super_admin` it reached every row outside the destructive tier.
`feedback_queue`, the fifth grant, marks no row. It is given on MAPI-14's terms, bounds the token that carries it as MAPI-16 states, and widens two unmarked rows, `read_feedback` and `settle_feedback` (MAPI-18; API-L0-20), which carry it under `admits`, the grant decided at each handler. The settling of the platform's own queue is the company's act on the platform's own record of its friction, naming no customer account and reaching no customer's data. So a token holding the grant and not `super_admin` is admitted to those two rows and to the rows marked `access: anonymous` (MAPI-11). It is refused every other row by name, the grant gate answering first on a row another grant marks (MAPI-14).
Under the queue's grant the queue form, the whole read of any issue by its id, and the settling of an issue of the platform's own space answer, and the read with no member answers the operator account's own submissions (MAPI-18). With `application`, `settle_feedback` settles an issue of the acting account's own application space with no grant read (ITS-L0-03). `issues`, the sixth grant, is a space grant any session of the account gives for one space it holds (MAPI-14); it marks no row and bounds its token to the relay (MAPI-16).
The grant-marked rows are therefore twenty-five in all, a `super_admin` credential reaching all twenty-five, a `synthetic_estate` credential the seven, a `publication` credential the two, and a `feedback_queue` credential none, the grant marking no row. `synthetic_seed_purge`, the seventh grant, marks no row either: a credential it bounds reaches three of the estate's seven by their `admits` mark (MAPI-16).
Deleting a customer's account is not a further marked row. It is the same `delete_account` action through the same pending action (API-L0-07), the grant widening the subject an operator credential may name and nothing else: same API, same tiers, same record, which is API-L0-12's whole claim.
Administering the builder realm is not a further marked row either. `issue_invitation` called with no `application` member, `revoke_invitation`, `application` optional and `invitation` required, called with none, `list_invitations`, `application` optional, called with none, and `configure_realm` called with none address the builder realm (ACS-L0-08; ACS-L0-07). The four rows are unmarked, and that application-less form is admitted to a credential holding `super_admin` alone. It is refused by name to every other credential, and refused `token_scope_refused` to an application-bounded token, the form naming no application the token is bound to (API-L0-17). So the grant widens the subject an operator credential may name on an unmarked row, the builder realm in place of a realm of the caller's own application, exactly as it does on `delete_account`. The action record and the meter name the builder realm as the subject (MAPI-06).
The queue form of `read_feedback`, the read called with `queue` (MAPI-18), is the same pattern on a further unmarked row, the widening grant the queue's own. The form is admitted to a credential holding `feedback_queue` or `super_admin`. It is refused `grant_required` naming `feedback_queue` to every other credential that reaches the handler, and `token_scope_refused` to an application-bounded token, the scope gate answering ahead of the handler in MAPI-14's order. The read without `queue` answers every credential its own submissions. The read with `issue` answers a credential holding either grant any account's submission by its id and every other credential its own alone, another account's answered `not_found`. The `super_admin`-marked rows are sixteen, the `synthetic_estate`-marked rows seven, the `publication`-marked rows two, and no row carries `feedback_queue`, twenty-five grant-marked in all. A test in the platform's suite holds each count: sixteen, seven, two, none, and twenty-five.
MAPI-10 (decided): The wire surface is uniform and derived: every action is an HTTP endpoint at `/api/v1/actions/<action_name>` — POST for every tier, GET additionally for the observe tier — built from the enumeration at server start. A route therefore exists exactly when its action does, which is MAPI-01 enforced on the wire rather than reviewed onto it.
Every response carries the contract version (MAPI-02). Every refusal is the wire error shape at `schemas/wire_error.schema.json`. Its six base members are the version, a machine-readable error slug, the action where one is in question, a human detail, the reference the action dispatcher minted for the call (API-L0-19), and `help`, the address of the refusal's explanation. The reference is admitted and not required, as the action and the detail are, and it is carried by every refusal the action dispatcher answers to a dispatched call.
`help` is admitted and not required. It is carried by every refusal the action dispatcher answers to a dispatched call, and by the `unknown_action`, `method_not_allowed`, and `not_yet_provisioned` refusals the actions routes answer before dispatch. It holds the address of the refusal's row on the refusals page, `<origin>/cloud/reference/refusals/#<refusal name>`, on the estate's configured public origin (MCP-02). Where that origin is a loopback or an `http` one, the address is composed on the production origin instead, so a local run names the page production serves.
Beyond the base members, on the management action surface, a refusal carries exactly the members its row of `schemas/wire_errors.json` names under `members` (MAPI-15). Each is admitted and none is required, so a body that omits one stays valid. A member no row names for that refusal is a defect of the body or of the row. This is MAN-12's named-refusal discipline applied to the plane itself: a caller reads a violated path, a plan's floor, or a conflicting schedule as a typed member and never parses it out of the detail.
A grant is one such member, `grant`, named and described by the row of each refusal that answers it. Under `grant_required` it is the grant the action requires: a grant-marked row's own, `super_admin` (MAPI-09) on the application-less builder-realm form of the four unmarked rows, or `feedback_queue` on the queue form of `read_feedback` (MAPI-18). Under the other refusals it is the grant requested or held.
The schema file's member region, its declarations beyond the base six and its conditionals, is generated from the rows and never written apart from them. The file stays closed, declares every member any row names, and admits each under the refusals whose rows name it and under no other. The platform's suite holds the file equal to its generation from the rows, and holds every refusal the action dispatcher answers under test to the file.
Three rules hold on every surface a customer or a public caller reads, among them the router's and the egress gateway's own refusals, the version row's outcome read through `list_versions`, and a deletion walk's receipts read through `read_pending_action`. A refusal a thrown transport failure produced — Node's `fetch failed`, whose deciding fact rides the error's cause — carries in its detail the message with the cause's code alone beside it, `fetch failed (ENOTFOUND)`. It never carries the cause's message, which can name an address inside the platform's network. A raw socket error is what `http.request` and `https.request` reject with, the router's application leg among them: its code is on the error itself with no cause, and its own message names the address the leg dialled. It carries a fixed sentence with that code alone beside it, `the connection failed (ECONNREFUSED)`, and never its message.
A refusal the provider answered is a status the management plane, a storage account, or the registry returned. Its own message names the platform's subscription, a resource group, a request identifier, the registry's login server, or the provider's vocabulary. On those surfaces it carries a fixed sentence with the status word alone beside it, `refused by the provider (http_403)`, or `failed (error)` where no status rode and no code of the transport's classifies, and never the provider's message. An operator diagnostic — a control-plane record, a run stamp, a command's standard error, the operator's own dashboard — carries the cause's code and message whole, a socket error's message whole, and the provider's message whole. So a lookup a network blocked, a certificate a firewall replaced, and a right the platform's identity lacks each read as what they are and never as an outage.
A thrown error whose transport code stands only along its cause, and whose own message is neither Node's `fetch failed` nor a raw socket error's, is the platform's own wrapper, its message composing an operator's text. On those surfaces it carries the fixed sentence with that code alone, `the connection failed (ECONNRESET)`, and never its message.
A container provision the provider failed because pulling the application's image answered 429 or a 5xx status is a refusal the provider answered, its message naming the registry's storage host and the provider's vocabulary. On those surfaces it carries a fixed sentence naming the busy image registry with that status word alone beside it, `The image registry was busy (http_503)`, and never the provider's message. The sentence says the fault is the platform's and transient, and names the act to call again.
An unknown action refuses as `unknown_action`, never a bare 404 page. A mutating action reached with GET refuses as `method_not_allowed`. An action whose implementation has not arrived refuses as `not_yet_provisioned`. MAPI-05's browser-only restriction is enforced at authentication, never by hiding the route.
This statement records the ninth use of MAPI-02's under-one-hundred-accounts clause, because it owns the wire error shape. The shape, a closed object of five members, the fifth the grant and given to one refusal alone, became the four base members and the members each refusal's row names. Twenty-nine rows named the members the platform already answered under them, and no answer changed. The platform then held two builder accounts that each held a live application: five live applications in all, four on the operator's account and one on the second account, read through list_accounts and read_platform_usage under the operator's session.
This statement records the fourteenth use of that clause. The reference, `reference`, became the fifth base member, admitted and not required, carried by every refusal the action dispatcher answers to a dispatched call. The schema file's base region and the generator's base-member list moved with it, and no row of `schemas/wire_errors.json` changed. The platform then held one builder account that held five live applications (read through list_accounts and read_platform_usage under the operator's session). Every later use of that clause that adds a member to a row, removes one, or changes the typing of a member's fragment (MAPI-15) is recorded here.
This statement records the thirty-second use of that clause. `help` became the sixth base member, admitted and not required, carried by every refusal the action dispatcher answers to a dispatched call and by the three refusals the actions routes answer before dispatch. The schema file's base region and the generator's base-member list moved with it, and no row of `schemas/wire_errors.json` changed. The platform then held one builder account that held six live applications, synthetic accounts excluded, read through list_accounts and read_platform_usage under the operator's session.
This statement records the forty-fourth use of that clause. The row `account_outside_batches` gained the member `grant`, admitted and not required, naming the synthetic grant that bounds the caller (MAPI-16). The purge's refusal carries it under either synthetic grant, so a `synthetic_estate` caller's answer gained the member too. A purge repeating another credential's `request_id` answers the row with `grant` and no `accounts`. The same change widened the `grants` enumeration of the token `mint_token` answers, and of each `list_tokens` row, with `synthetic_seed_purge` (MAPI-14). The platform then held one builder account and no synthetic account, read through list_accounts under the operator's session at the change.
This statement records the seventy-eighth use of that clause. The row `declared_audience_contradicts_route` lost its member `routes` and gained `sign_in_methods`, admitted and not required, the same array of the realm's configured sign-in methods under the realm member's new name (ACS-L0-07; MAPI-02). The refusal keeps its name (MAPI-15), the schema file's member region was generated again from the rows, and no other row's member changed. The platform then held one builder account and no standing synthetic account, read at the change.
MAPI-22: **A call that names a member its action does not declare is refused by name, on every surface: the HTTP route, the tool surface, and the console.** The refusal is `invalid_request`. So a caller that misnames a member is told which member it sent, and is never answered as if it had sent none.
What an action declares is the `properties` of its request in `schemas/action_payloads.json`. A request's root is closed. A nested object whose schema carries `properties`, empty or not, is closed too. A nested object that carries none is a map and admits any member, and an array's items follow the same rule. On the HTTP route a member of the query string counts as a member of the body. A caller's `_origin` is refused, that member being the plane's own.
The detail names what the caller sent and what the action takes. It names each undeclared member, a nested one by its path, and then every member declared at that place. It quotes at most five undeclared names and counts the rest. It quotes a name only where the name has a member's form, letters, digits, and underscores up to 64 characters. It never carries a value.
A member the contract replaced is answered with its successor. A request may carry `x-renamed`, a map from a member the request once declared to the declared member that took its place, and the detail then adds a sentence naming that member. A caller's guess gets no row. The four feedback requests carry the map for `application` and `environment`, which `space` replaced (MAPI-18), and their detail says which space a call naming none addresses.
A member the contract removed, with no member in its place, is answered with the reason. A request may carry `x-retired`, a map from a member the request once declared to a sentence that says why it is gone, and the detail then adds that sentence. `submit_feedback`'s request carries the map for `personal` and `excerpt`: its sentence says that a report has no personal option, and that the caller files again without the member and leaves out what it does not want kept (MAPI-18).
The check stands in the dispatcher, behind its access gates. It runs after the refusal of text the plane cannot hold (PLD-L0-91) and after every access gate: the scope, grant, and bound gates, and the destructive class's (MAPI-12). So an access refusal keeps its name, and a credential the row does not admit is told no member names. It runs before a pending act is described, so a refused call creates none. Each surface hands the dispatcher the caller's member names and no value. A body that is not a JSON object is refused at the same place, in words that name no member. The replay of a stored input is not checked again.
On the tool surface the refusal answers before the argument layer validates the call. A single tool call that carries an undeclared member is handed to the dispatcher as the HTTP route hands a body. So a call that misnames a required member is answered with the member it sent, not with the member it lacks. A batch of calls keeps the argument layer's order, and a request the transport refuses for its headers keeps that refusal. The members the detail lists on this surface are the tool's arguments, a member marked `x-wire-only` left out (MAPI-08). One exception stands: a tool call whose only member outside the tool's arguments is marked `x-wire-only` keeps the answer MAPI-08 gives it. A call that also names an undeclared member is refused by name.
This statement records a use of MAPI-02's shape clause, the fiftieth: a call that named an undeclared member was answered, and is now refused. The platform then held one builder account that held six live applications, synthetic accounts excluded, read through list_accounts and read_platform_usage at the change.
The served-surface suite holds the rule for every action, on each surface that serves it.
MAPI-11: Action rows carry the access marking where MAPI-09 carries the grant marking. An action row marked anonymous answers without a session on the wire surface: the library’s inventory and content reads (LC-02), and the platform context catalog and content reads (CTX-07). Over MCP any connected identity reads it, since MCP-02 challenges a connection presenting none. An unmarked action answers as the connected identity behind the standard challenge (the 401 pointing at the protected-resource metadata, CQ-04's machinery).
The anonymous platform_context observe actions additionally retain a supplied valid, active bearer or minted credential, checking the required OAuth scope where that credential is OAuth-bound, for their credential-filtered view and attribution. On the wire an absent, invalid, suspended or insufficiently scoped credential reads the anonymous view. Over MCP a credential that resolves to an account without acting, suspended or unscoped, reads it, a message requiring an identity refused 403, and an absent or unresolved one draws the challenge (MCP-02). A resolved platform credential, end-user credential or transfer grant retains its named kind refusal. This optional-identity rule does not change the library HTTP routes.
The marking is the enumeration’s own member: the server derives its authentication gate from it, no surface keeps a hand-curated set beside it, and the suite holds every action to a marking-consistent gate (Q-239).
MAPI-12: The destructive class is granted by presence. A session credential minted by a person's own browser sign-in carries the destructive class from its minting — the sign-in is the explicit grant API-L0-06 requires. A minted token (API-L0-05) takes the class only at its own minting, from a session holding it (MAPI-14), and from nothing afterward. The application's platform credential (SEC-L0-07), the end-user credential the accounts service issues, the transfer grant object storage mints, the secret grant (SEC-L0-19), and the egress key (SEC-L0-18) hold no destructive class and can be granted none. A credential kind added later holds none until its own statement says otherwise (API-L0-06). The check runs where a destructive request arrives, before any pending action is created, and its refusal names the missing grant — a refusal distinct from the pending path, so an ungranted caller cannot fill a person's browser with approval requests.
A deploy code (PLD-L0-86) holds no destructive class and can be granted none. A token code (MAPI-23) holds none either and can be granted none; the token its exchange mints takes the class only as a minted token does, at the code's mint, from a session holding it.
MAPI-14: A minted token is created by `mint_token` (reversible tier), callable by the session credential alone — never by another token, the platform credential, or an anonymous caller — but for the fourteenth paragraph's exchange form, where that form is served. Or, for a synthetic account alone, it is minted by `seed_synthetic_accounts` through the same code path under a credential the seed's row admits: a session holding `super_admin`, or a minted token carrying `synthetic_seed_purge`, `synthetic_estate`, or `super_admin` (MAPI-09). So a harness holding a token carrying either synthetic grant mints the fixtures' tokens and no other (MAPI-16). Or it is minted by the code exchange of Turn Zero Blueprint's first-party client (MCP-02): one `issues` token at the `owner` level, for a space the signed-in account holds, under the label the request named.
`mint_token` names its scope (the account, or one application of it), an optional expiry, an optional label, and the grants requested. Where the token code form is served it takes an optional `code_challenge`, under which the call mints a token code in place of the token and answers no value, and an optional boolean `authorized_computer`, each as the fourteenth and sixteenth paragraphs and MAPI-23 state. The destructive class (MAPI-12's explicit grant) and `super_admin` (MAPI-09) are each given only where the minting session holds it and refused by name otherwise.
The five narrow grants are `synthetic_seed_purge`, `synthetic_estate`, `publication`, `feedback_queue`, and `issues`. `synthetic_seed_purge` is the one the seed, the purge, and the purge's read admit (MAPI-16), and `synthetic_estate` the one MAPI-09 marks the synthetic estate's rows with. `publication` is the one it marks the two publish rows with, `feedback_queue` the one `read_feedback` and `settle_feedback` admit (MAPI-18), and `issues` the space grant the next two paragraphs state. Each bounds the token that carries it to the reach MAPI-16 states. The first four are given only where the minting session holds `super_admin` and refused by name otherwise. At most one of the five is given to a token that takes no `super_admin`, a request naming two refused 400 `invalid_request` with nothing minted. None of `super_admin` and the five narrow grants is given to an application-bounded token (API-L0-17).
`issues` is given by any session of the account for one space the account holds, where the account holds the `blueprint` profile, the Blueprint license (ACB-L0-82). The request names the space in `space`, a lower-case UUID `list_issue_spaces` answers, the level in `level`, `report`, `contribute`, or `owner`, and a `label`, each required with the grant and refused `invalid_request` where absent; `space` or `level` without the grant is refused the same. The label names the holder in printable characters, and no unrevoked token of the account carries it for the same space, expired or not, until the daily pass deletes the row (PLD-L0-67). A duplicate or a non-printable label refuses `invalid_request`, and the level is not capped by the space's kind. The relay names the acting actor as the account's identifier qualified by the label (the issue service PRD's relay row).
Without the grant, a `space` naming a space the account does not hold is refused `space_not_owned` ahead of the form, the identifier judged before the form as every identifier is (VER-11).
The exchange's mint records on the token the client it was issued to, which no answer carries. In the same act it revokes each unrevoked token of that account, space, and label that the same client was issued. So a clone's earlier token is replaced, and no other token is. Where another token carries the label in that space, one `mint_token` minted or one another client was issued, the exchange is refused 409 `label_in_use` with nothing minted or revoked, and the confirm page MCP-02 states refuses that space by the same name. `mint_token` keeps refusing a label an unrevoked token of the space carries, whatever minted it. `label_in_use` is this statement's row of `schemas/wire_errors.json` (MAPI-15).
A space the account does not hold is refused 403 `space_not_owned` naming the space, whatever the session holds. That is another account's space, an unknown one, the platform's own space to every account but the one the plane names its owner, and an application's space until a binding records it (the issue service PRD's relay row). `space_not_owned` is this statement's row of `schemas/wire_errors.json` (MAPI-15), answering the mint, the relay, and `create_issue_space` under one name.
The license is read once the owner is judged. An account that lacks the `blueprint` profile is refused 403 `blueprint_required` with nothing minted, whatever the space's kind. The relay reads the same profile on each call, and `create_issue_space` reads it before it creates anything (the issue service PRD's relay and provisioning rows). `blueprint_required` is ACB-L0-82's row of `schemas/wire_errors.json` (MAPI-15).
The answer carries the value exactly once beside the token's identity, but for a mint naming `code_challenge`, which answers no value. Its `token` member then carries the properties the exchange mints with and no identity, and the exchange's answer carries the identity and the value once (MAPI-23). The store holds the value's hash, the scope, the grants, the label, the revocation, and the authorized computer's marker, never the value. It holds the three stamps — the minting, the expiry, and the last use, which the credential seam writes as it resolves a presented value — and a space grant's space and level.
`revoke_token` (reversible) ends one token by its identity, and `list_tokens` (observe) answers identities, scopes, grants, labels, a space grant's space and level, and all three stamps, the last use among them, never values, and `mint_token` answers that same shape for the token it mints. Where the token code form is served, `list_tokens` also answers `authorized_computer`, true on an authorized computer's token and false on every other. `revoke_token` is idempotent: a repeat answers the row with its first revocation stamp. Once the daily pass has deleted the row, after the retention PLD-L0-67 states, `list_tokens` lists it no more and `revoke_token` naming it answers `not_found`.
`mint_token` and `revoke_token` each write one line into the control plane's own diagnostics (system:LGS-L0-16) carrying the token's identity, its scope, its grants, its label, and its expiry, and never the value. The fixtures `seed_synthetic_accounts` mints through the same code path write none, as do the sweeps an application's deletion and an account's erasure run, and the ends of the exchange's tokens MCP-02 states, each being another act's. The exchange's end of a token it minted while the generation moved writes `revoke_token`'s line. The operational record answers no reader (MAPI-06), so that line is where an operator reads what was minted under an account and when it ended. The exchange's mint writes the same line, naming the client and the tokens its act revoked.
A revoked or expired token is refused at once on the management surface and the MCP endpoint, and on the storage, egress, and logging wires at the gateways' next read past their cache interval (PLD-L0-67). A stored token whose grants name one outside the grants the running build serves resolves to no credential, refused `authentication_required` as an absent credential is. So a build that predates a narrow grant never serves that grant's token unbounded. A minted token renews nothing — it is replaced by minting another — and its grants admit nothing its minting session's grants did not admit (MAPI-09). Every action a token performs is recorded under the token's own identity (MAPI-06): a credential identity on the record beside the kind, empty where the credential has none.
Its refusals run in one order, each named and none creating a pending action. The scope comes first (API-L0-17). Then, on a row whose implementation has not arrived, comes `not_yet_provisioned` (MAPI-10). Then comes the grant (MAPI-09), under which a grant-marked row that does not admit the token keeps `grant_required` with the row's own grant. Then comes the bound of a token a narrow grant bounds, `synthetic_seed_purge_bounded`, `synthetic_estate_bounded`, `publication_bounded`, `feedback_queue_bounded`, or `issues_bounded` by the grant (MAPI-16). The destructive class comes last (MAPI-12).
This paragraph states the exchange, the first paragraph's one exception, served only where the plane's environment holds `TOKEN_CODE_FORM` with the value `on`, a name no template declares and no estate holds (MAPI-23). The exchange is `mint_token` on the HTTP action route whose bearer is a token code the session's own call minted and whose body is `code_verifier` alone. It mints the token from the code's row, with every property that call named, and answers the value once. Where the form is not served, a call naming `code_challenge`, `code_verifier`, or `authorized_computer` is refused 400 `invalid_request` naming each as not served on this estate, nothing minted, and every other answer is the one this contract states for a call naming none of them.
The code's mint runs every refusal of this statement's mint before it mints, the label rule read from the account's token rows before anything is written, so a taken label is refused in this statement's words and no code is minted. A state arisen since the mint, an application, a space, or the Blueprint licence no longer held, or the label taken, is answered at the exchange by this statement's own named refusal for it, the code spent and nothing minted (MAPI-23).
`authorized_computer`, an optional boolean of the same form, marks the token of an authorized computer, the one the turnzero-cloud command presents from the computer whose challenge the call names. A marked mint names a challenge, since the token's value is answered to no call, is account-scoped, and lives at most 30 days, 30 where `expires_in_days` is absent. A marked mint naming no challenge, `scope_kind` `application`, or `expires_in_days` above 30 is refused 400 `invalid_request` with nothing minted, the cap a refusal and never a clamp. The exchange writes the marker on the token's row, and `revoke_token` ends the token as it ends any.
Where the token code form is served, a mint naming `code_challenge` writes one line into the control plane's own diagnostics naming the code's identifier, the session's kind, the scope, the grants, the label, the marker, and the code's expiry, and no value. The exchange writes `mint_token`'s line for the token it mints, naming the code's identifier beside the token's (MAPI-23).
MAPI-23: The token code is a one-time grant `mint_token` mints in place of a token where the call names `code_challenge`, admitted once at `mint_token`'s wire exchange form, where the exchange mints the token from the code's row. The plane serves the token code form where its environment holds `TOKEN_CODE_FORM` with the value `on`, a name no template declares and no estate holds. Where it does not, a `mint_token` call naming `code_challenge`, `code_verifier`, or `authorized_computer` is refused 400 `invalid_request` naming each as not served on this estate, nothing minted. Every other answer, `list_tokens`'s among them, is the one this contract states for a call naming none of them.
Whatever the switch, the served descriptions carry the form's three members and `mint_token`'s tool argument list its two, `code_challenge` and `authorized_computer`, each saying it is answered only where the form is served. The served value `token_code_seconds` (PLD-L0-76) and the daily pass's step `token_codes_purged` (PLD-L0-67) are served whatever the switch.
Under a session credential, a call naming `code_challenge`, 43 base64url characters, the S256 challenge of a verifier the caller's turnzero-cloud command holds, runs every refusal of the mint and then mints one code in place of the token (MAPI-14). The space grant's label rule is read from the account's token rows before anything is written, so a taken label is refused in the mint's own words and no code is minted. A challenge of another form is refused 400 `invalid_request`, nothing minted. The call answers 200 with the state `awaiting_command`, `command`, `command_windows`, `expires_at`, the code's, `token`, and `detail`, and no value. `token` carries every property the exchange mints with, `scope_kind`, `application`, `grants`, `label`, `expires_at`, `authorized_computer`, and an `issues` token's `space` and `level`, and no `id` or stamps. The token's expiry is fixed at the mint, from the days the call named.
`command` is one line that pipes the code to the turnzero-cloud command on its standard input, in none of its arguments, in one of two forms: an authorized computer's where the call marked one, and every other mint's. It names the pinned version on the estate's configured origin, never a host a request names, and adds `--origin <origin>` where that origin is not the command's default. `command_windows` carries the line's Windows form (PLD-L0-94). The `detail` says the line is a credential until `expires_at`, to run once, as given, and paste into nothing but the terminal that runs it. It says who runs it: a tool runs the first form, and the person runs the second, in a terminal outside the AI tool and never by a tool.
A token code is a grant of a kind of its own, the fourth beside the transfer grant, the secret grant, and the deploy code, and its value has a grant's form (MAPI-03). Its record kind, on the action record, the authorization matrix, and the credential-surface census, is `token_code`. The plane stores it by its SHA-256 alone, in the control database's `token_codes` table (PLD-L0-67). Its row records the account, the minting session's kind and row key, which no record, answer, or log line carries, the challenge, every property the mint named, and the marker. It also records the token's expiry, the code's creation and expiry, the instant and manner of its end, and the token it minted.
A code lasts the served `token_code_seconds`, 300 seconds by default and held between 30 and 300 (PLD-L0-76), and never past the minting session's row's expiry. A later mint by the same session under the same label ends that session's unspent codes of the label.
The exchange is `mint_token` on the HTTP action route with the code as its bearer and the body `code_verifier` and no other member. There the dispatcher's kind gate looks the code up and spends it by one compare-and-set bounded by its expiry, ahead of every refusal of its own and ahead of the verifier's match. So every presentation there of a code the plane holds unspent spends it, whatever the call then answers, and two presentations of one code are admitted once.
The plane mints the token where the verifier's S256 challenge is the recorded challenge, the account is not suspended, and the minting session's own row stands unrevoked, unexpired, and not behind its account's generation. That one read covers a sign-out everywhere, a `revoke_connection`, a device's sign-out, a passkey change's revert, and the session's expiry. It also reads again what the mint read: an application-scoped code's application, and an `issues` code's space, Blueprint licence, and label. Where the account no longer holds the application, the space, or the licence, or an unrevoked token has taken the label since the mint, the exchange answers the standing mint's refusal, `no_such_application`, `space_not_owned`, `blueprint_required`, or `invalid_request`, the code spent and nothing minted. A fault reading the space is answered as the standing mint answers it, and any other fault is the dispatcher's internal failure.
It mints with the recorded properties and the marker, writes the token's identity on the code's row, and answers 200 with `token`, the identity beside the same shape, and `value`, to that one caller, and no later read shows the value.
One refusal answers every other state: 403 `token_code_refused`, alike in name, status, and detail, each answer carrying its own `reference` (MAPI-10). The states are an unknown, spent, expired, or ended code; a body naming more than the verifier; an unmatched verifier, or one outside its form; and a code of a suspended account or an ended session. So is a bearer of a grant's form that resolves to nothing there. A mismatch, or a verifier outside its form, spends the code, so a copy presented without the verifier mints nothing, and the person's own line is then refused and told to call `mint_token` again. The detail says the code cannot be used, being unknown, expired, or already presented, its verifier unmatched, or its session ended, that nothing was minted, and the remedy. `token_code_refused` is this statement's row of `schemas/wire_errors.json` (MAPI-15).
Every presentation at the exchange form counts in its source's admission window ahead of the lookup, whether or not the plane holds the code (PLD-L0-67), so the gate's 429 `rate_capped` alone precedes the spend and leaves a found code unspent. A transfer grant, a secret grant, or a deploy code presented there is answered as MAPI-03 and PLD-L0-86 state and stays unspent. Elsewhere a code is no credential: on every other management action, on `mint_token`'s other forms, on the MCP surface, and on the storage and egress wires it is answered as a value of a grant's form that resolves to no credential is (MAPI-03), unspent. `code_verifier` is a wire-only member (MAPI-08): an MCP call naming it is refused 409 `local_route_required`, and a wire call naming it under any credential but a token code 400 `invalid_request`, nothing minted. A token code holds no destructive class (MAPI-12).
A code ends with its one presentation, its expiry, a later `mint_token` by the same session under the same label, and the account's `sign_out_everywhere`, a passkey change's revert, and suspension; the account's erasure removes the rows (PLD-L0-66). A `revoke_connection`, a device's sign-out, and the session's expiry write no end on the code: the exchange refuses such a code by its read of the session's row. A reinstatement brings no ended code back. The daily pass's step `token_codes_purged` deletes each code a day past its expiry (PLD-L0-67).
The mint's action record names the session's kind and the code's identifier and holds no part of the answer. The exchange's record is attributed to the owning account with the code's kind and identifier, and names the token minted. A refused presentation of a code the plane holds is recorded against its identifier, and one of a value it does not hold with no value. The mint and the exchange each write one control-plane line, the mint's naming the code's identifier and the exchange's the token's and the code's (MAPI-14). No code, verifier, or token value stands in any record, event, or log line, and no hash of a refused value is logged (system:SCRT-L0-02); the challenge may stand on the code's row, since it is public.
At the launch population (PLD-L0-74) the `token_codes` table holds about a day's mints, tens of thousands of rows, and `minted_tokens` gains one live row per authorized computer and origin, about 900,000 rows inside the thirty-day retention at 300,000 accounts. The marker is one nullable column with no index, read as a token is read today. The pass's delete reads `expires_at`, which no index serves, an index owed at the next order.
MAPI-19: The `connection` resource is a signed-in tool's OAuth 2.1 refresh family (API-L0-21; MCP-10), one per sign-in a registered client completed, and the account grain holds its two actions. `list_connections` (observe) answers the acting account's live connections. Each row is its identity, its client, the instant of the sign-in that opened it, its last renewal or null, and its expiry, and never a credential value or hash. The listing is idempotent and answers GET as every observe row does (MAPI-10). `revoke_connection` (reversible) ends the connection its `id` names: the family's refresh credentials are deleted and its access-token session rows revoked, so the tool is refused at once on the management surface, the MCP endpoint, and the wires alike. It touches no other connection, cookie, or minted token. An `id` no live family of the acting account carries is refused 404 `not_found`, another account's among them.
Both rows are callable by the session credential and by the browser session (MAPI-03; MAPI-05), the Account page's connections section being their one page (WEB-L0-21), and by a minted token as MAPI-03 admits an account act. Neither is grant-marked (MAPI-09). Each end writes one line into the control plane's own diagnostics carrying the account, the client, and the family, never a token (system:LGS-L0-16). The row `sign_out_everywhere` (reversible), on the `account` resource under the same callers and no grant mark, ends every session and every connection of the account at once and answers `sessions_ended`, `refresh_rows_deleted`, and `exchange_tokens_revoked`. The last counts the tokens Turn Zero Blueprint's exchange issued the account that it ended (MCP-02; ACS-L0-18). The site's Sign out ends that browser's session alone.
MAPI-15: The refusal names are enumerated. Every refusal name a surface of the plane answers is listed once in `schemas/wire_errors.json` beside this document. Each row carries the surfaces that answer it, the HTTP status where one status is fixed across every site, and the statement that owns the behaviour. It also carries one clause saying when it is answered and one clause saying what the caller does next, the row's remedy, written by the change that adds the row. The surfaces are the management actions on their routes and through the tools that surface them (MAPI-08), and the MCP server's own challenge. The others are these:
- object storage;
- the egress gateway;
- the push service's send route;
- the accounts service's realm surface;
- the builder sign-in;
- the serving router;
- the deploy command's progress read, the catalogue's `deploy_progress` (PLD-L0-86).
Four more surfaces answer names of the list: the egress tunnel seat (`egress_tunnel`), the logging ingest (`logging`), the runner harness inside every application container (`harness`), and the documentation trees' machine files (`documentation`).
Where the refusal's body on the management action surface carries members beyond the six base members (MAPI-10), the row carries a `members` object giving each member's name a JSON Schema fragment that types and describes it. The published refusals page reads both clauses and the members from the row and derives none of them. Each clause is written in sentences of fewer than 45 words, because the page carries them as table cells under the documentation's prose bound, a member's description held to the same bound for the same reason.
A row's `members` state the body the management action surface answers and nothing of another surface's body under the same name, so a row that does not name that surface carries none. The rows and the schema generated from them state the management action surface's refusal bodies alone. The body another surface answers under a name of this list is that surface's owning statement's to state, in the shape the surface answers, and no row, schema, or description of this catalogue holds it to the management action surface's shape.
The rows are the members' one home. A fragment uses `type`, `items`, `properties`, `pattern`, and `description` alone, through its nested fragments, and never an enumeration, a constant, a format, or a required list. It never uses them because a closed vocabulary in a fragment would make every later value a change of the body's shape and because every member is admitted and none required. A member that may be null says so in its `type`, and a nested object declares the properties the platform answers and stays open.
The list is derived from nothing and reviewed onto nothing. A test in the platform's suite extracts the names from the source by the call forms the surfaces use to put a name on the wire and holds the two sets equal. So a name the source answers that the list lacks, and a row the source no longer answers, each fail the suite. A name absent from the list is a defect in the change that added it, closed by adding the row in the same change, never by excluding a real wire form from extraction. When the implementation introduces another way to carry a refusal name on the wire, the extractor covers that form and the catalogue gains any new names in the same change.
The JSON body shape stays MAPI-10's (`schemas/wire_error.schema.json`), whose member region is generated from the rows' `members`. The suite holds each row's members to this form and each declared member's name to a key the platform source writes at a site that builds that refusal's body. So a member the rows declare and no site of that refusal still writes fails it, as a row the source no longer answers does. This catalogue includes the JSON `error` member's values and standard OAuth `error` parameters in WWW-Authenticate challenge headers and authorization redirects; it does not impose the JSON body shape on those standard protocol fields. This is MAN-12's named-refusal discipline made a check. Within a contract version the list grows and never shrinks: retiring a name is a new contract version (MAPI-02).
One case stands beside that rule while MAPI-02's under-one-hundred-accounts clause stands. A name the source stops answering because its cause has left the platform may leave the list within version 1, recorded as MAPI-02 records a use of that clause, with the account count read at the change.
The members' evolution is MAPI-02's and no rule of this statement's own. While its under-one-hundred-accounts clause stands, a member added to a row, a member removed from one, and a fragment's typing changed, its `type`, `items`, `properties`, or `pattern`, are each a change of the body's shape, recorded by MAPI-10 as a use of that clause. A description's wording is a content change that moves the version and no use. Once it lapses, a member added is a new optional field, and a member removed or a fragment's typing narrowed is a new contract version.
MAPI-13: The running build states its identity on the health read. The artifact carries a build stamp written at bundle time — the source commit, whether the tree was dirty, and the build instant — as a stamp file beside the bundle. `GET /healthz` answers it as `build` beside MAPI-02's `contract_version`. Beside the stamp's three members, `build` carries `bundle_hash`, the SHA-256 of what the process's image copies: the one bundle file for the serving router and the tunnel seat, and for the plane the `dist/` tree its image copies whole. For that tree the hash reads every file under the folder holding the bundle, each relative path joined with `/`, the paths sorted by bytes, each path then its file's bytes fed to one hash, `build.json` and the bundle's source map excluded.
`bundle_hash` is read at the process's boot from the file it runs as `harness_hash` is, and it is null where the process does not run from its image's file. Beside `build`, `/healthz` answers `harness_hash`, the SHA-256 of the runner harness bundle beside the running bundle, the harness the platform bakes into every application image it builds (PLD-L0-63). A source tree with no stamp answers null members, never an invented value, and a process with no harness bundle beside it answers `harness_hash` null the same way.
The identity answers on that one anonymous read rather than riding every exchange. It also answers on two aliases the edge's standing routes carry to the services its default route does not reach: `GET /accounts/v0/healthz` on the accounts mount set and `GET /logging/v0/healthz` on the gateways mount set. Each answers the body `/healthz` answers, read through the edge under the origin lock's check where `/healthz` itself is exempt (PLD-L0-67). So two builds of one contract are distinguishable to any caller at the cost of one call, and a deploy's completion is the served identity changing to the deployed commit (PLD-L0-65; the handshake SVC-L0-11 asks of a customer's backend, kept by the plane itself).
The build also states its readiness on `GET /readyz`: one statement per database pool the process holds. It answers 200 with `ready` true, `pools` naming each pool with `ok`, and `unapplied` 0, or 503 with `ready` false, `pools` naming the pool that failed, `unapplied` counting the migration files the ledger lacks, and `detail`. The answer carries them beside MAPI-02's `contract_version` and `build`, the member `/healthz` answers, so the one readiness read carries the process's identity.
On the accounts mount set the answer also carries `realm_keys`, ready once the realm key-encryption key is unwrapped (SEC-L0-07). On a process mounting the gateways set alone, a control pool whose statement failed while the credential cache holds an entry within its stale ceiling answers 200 with `ready` true, that pool `failed` in `pools`, and `serving_stale` true. The wires answer from the held entries (PLD-L0-67's cache rule), and every other failed statement refuses as stated. A process holding no pool answers ready with an empty `pools`.
On a build that mounts the gateways set, `GET /healthz` also answers `caches`: for each gateway cache, `credential` and `rows` (PLD-L0-67), the positive and negative entries held and the hits, misses, and stale serves counted since the process started, read from the process alone. The health read stays the identity read and touches no store, so a host's liveness probe and its readiness probe ask different questions (PLD-L0-67).
The process binds its listener before it builds its routes. A connection attempted before the bind is refused at the socket. A request accepted after the bind and before startup completes, a liveness or readiness probe included, is held unanswered until the routes are built and the pre-serve work the entry runs for its mount set has completed (PLD-L0-67). That work is the timers' start and, on the management set, the first sweeps; the request is then served by the built application. Where that work fails after the bind, no held request is answered, each held connection is destroyed, the listener closes, and the startup call fails with the error, which ends the executable's entry.
MAPI-16: The synthetic estate is five grant-marked rows of the enumeration under `grant: synthetic_estate` (MAPI-09): `seed_synthetic_accounts` (reversible), `purge_synthetic_accounts` (reversible), `read_synthetic_purge` (observe), `read_synthetic_signin_code` (observe), and `read_synthetic_account_state` (observe). Its grant is a third grant beside the destructive class and `super_admin`, minted on MAPI-14's terms, the grant the compat harness's and the live tests' tokens carry. The estate is the company's own act on the company's own test fixtures, naming no customer account (the synthetic account kind the accounts and billing PRD states; API-L0-12).
The grant bounds the token that carries it, at the platform's two seams. So does `publication`, the fourth grant, which marks the two publish rows, `publish_library` and `publish_public_files` (MAPI-09). It is minted on MAPI-14's terms, the one grant the publisher's token carries (CRD-01). So does `feedback_queue`, the fifth, which marks no row and is the one grant `read_feedback` and `settle_feedback` name under `admits` (MAPI-18), the one grant the feedback queue's triage token carries. So does `issues`, the sixth, a space grant any session of the account gives for one space it holds (MAPI-14), which marks no row and is admitted on `list_tokens` and `relay_issue_act`. So does `synthetic_seed_purge`, the seventh, a staff grant minted on MAPI-14's terms, which marks no row and is named under `admits` on three of the estate's rows. The five are the bounding grants.
A minted token whose grants hold one of them and not `super_admin` is bounded by it exactly as this statement states for `synthetic_estate`. It is admitted the rows its grant marks, the rows the enumeration marks `admits` with its grant's name, and the rows marked `access: anonymous`. It is refused every other row under the grant's own name, `synthetic_seed_purge_bounded` for the hosted trial's, `publication_bounded` for the publisher's, `feedback_queue_bounded` for the triage token's, and `issues_bounded` for a token the space grant bounds, the refusal's members the same.
A mint gives a token that takes no `super_admin` at most one of the bounding grants, and a request naming two is refused 400 `invalid_request` with nothing minted (MAPI-14). So no token carries two bounds. A stored row that did would be bounded by the first of them in the order the predicate reads them, `synthetic_seed_purge`, then `synthetic_estate`, then `publication`, then `feedback_queue`, then `issues`, its reach the narrower for it. `synthetic_seed_purge` stands first because its three rows are among the estate's, so a row naming both meets the three alone. No row of the enumeration marks `admits` with `publication`, so the publisher's token reaches its two rows and the anonymous rows and no other, `list_tokens` and `read_account` among the refused.
The triage token reaches `settle_feedback`, `read_feedback` in every form, and the anonymous rows and no other, `submit_feedback`, `list_tokens`, and `read_account` among the refused. So a report it reads can turn it to no filing and to no act beyond the queue. A token the space grant bounds reaches `relay_issue_act` for the one space its grant names, `list_tokens`, and the anonymous rows and no other, the space and the level judged at the relay's handler (the issue service PRD's relay row). An act above its level is refused `issues_level_refused` naming the level and the acts it admits, so a token a teammate's clone or a build step holds reaches one space of its account at one level and nothing else.
On the management surface, a minted token whose grants hold `synthetic_estate` and not `super_admin` is admitted to those five rows: the purge for the batches the caller's own credential seeded, and the code read and the state read for accounts in those batches. It is admitted to the operator signal's row and to `record_check`, the two other rows the enumeration marks with the grant (MAPI-17; MAPI-18).
It is admitted to the rows the enumeration marks `admits: ["synthetic_estate"]`, two rows, nine rows in all with the seven above. One is `list_tokens`, the observe read under which every consumer of such a token finds its own row's expiry. The other is `submit_feedback`, the filing of a report into the company's own space of the issue service (MAPI-18). That filing names no customer account and reaches no customer's data, the ground the operator signal's row stands on (MAPI-17), so a company harness files its findings under the token it already holds. Such a filing may cite the reference of a call an account of a batch that credential seeded made, the stamp and the daily pass's join reading under that account (MAPI-18; PLD-L0-67).
The token is also admitted to the rows marked `access: anonymous` (MAPI-11), which lie outside the bound and answer a bounded token as they answer every connection, the credential-filtered view where MAPI-11 gives one. Every other row refuses it 403 `synthetic_estate_bounded`, `read_documentation` among them, which carries no anonymous mark. The exception is where a refusal that answers every credential ahead of the bound answers it first. A browser-only row's `browser_session_required` (MAPI-05) and `not_yet_provisioned` on a row whose implementation has not arrived (MAPI-10) are among those refusals. The bound's refusal carries a `grant` member naming the bounding grant. Its `admitted` member names the rows the grant and the `admits` mark admit, the anonymous rows outside the bound and named in the row's clause.
A minted token whose grants hold `synthetic_seed_purge` and not `super_admin` is the hosted trial job's credential. Three rows carry `admits: ["synthetic_seed_purge"]` beside `grant: synthetic_estate`: `seed_synthetic_accounts`, `purge_synthetic_accounts`, and `read_synthetic_purge`. The token is admitted to those three and to the rows marked `access: anonymous`, and to no other row. A grant-marked row that does not admit it answers 403 `grant_required` naming the row's own grant: `read_synthetic_signin_code`, `read_synthetic_account_state`, the operator signal's row, `record_check`, and every row `super_admin` or `publication` marks. Every unmarked row answers 403 `synthetic_seed_purge_bounded`, `list_tokens`, `submit_feedback`, and `read_account` among them, save where a refusal that answers every credential ahead of the bound answers first. So under this token a disclosed copy writes no operator-signal line, posts no check, files no report, reads no sign-in code, no account's state, and no token row, and reaches no customer account.
Under that grant a seed is bounded below every posture: one account for each call, a token of at most one day, and no `products`. A seed past a bound is refused 403 `synthetic_posture_refuses` naming the bound and the grant. A batch seeded under it expires with its account's token, where the posture's lifetime is longer, so the lifetime sweep purges an account a trial left standing after one day. The purge refuses `all: true` and an account outside the caller's own batches, as under `synthetic_estate`. `read_synthetic_purge` answers only a purge every account of which lies in a batch the caller's own credential seeded, and any other identifier as it answers an unknown one.
Under that grant a repeat is answered only where the batch or the purge is the caller's own. A seed repeating another credential's `request_id` is refused 400 `invalid_request`, and a purge doing so 409 `account_outside_batches`. Under `synthetic_estate` the read and both repeats answer every caller, the harness's tokens sharing one operator account. The token's own row stands in its owner's `list_tokens` answer, which the token itself does not read.
The `admits` mark is the enumeration's own member on MAPI-11's pattern, this statement's to own. The bound's gate runs after the grant gate, under which a grant-marked row that does not admit the token keeps `grant_required`, and before the destructive-class gate (MAPI-14). The grant gate admits a token on a grant-marked row where it holds the row's grant or `super_admin`, or where the row's `admits` mark names the grant that bounds it (MAPI-09). One exported predicate over the enumeration's three marks, the grant, the `admits` mark, and the access mark, serves the gate, the MCP listing (MCP-08), and the `admitted` member, no list kept beside the enumeration (MAPI-11). One exported predicate likewise decides the grant gate and the listing's grant rule, reading the token's bound and never another grant it holds.
On the data planes the bounded token reaches no declaration of the account. Object storage refuses it 403 `area_scope_refused` on a route of a declared area and at a minting request the route would otherwise admit. The egress gateway refuses it 403 `upstream_scope_refused` on a call naming a declared upstream. The refusals that answer ahead of each surface's reach rule answer it as they answer any account-wide credential. With those and the two scope refusals, neither surface serves it. The two refusals carry the bodies those surfaces' owning statements state (OST-L0-03; EGW-L0-08). So every consumer of the estate presents the seeded account's own token on the data planes and never the grant-carrying one. The same two refusals answer the hosted trial's token, the publisher's token, the triage token, and a token the space grant bounds, whose acts are management actions alone.
A token minted with a bounding grant and `super_admin` is `super_admin`'s and is bounded by nothing (MAPI-09). And `all: true` on the purge, the purge of a batch another credential seeded, and the code read and the state read for any synthetic account are `super_admin`'s (MAPI-09).
The seed takes `count` (1 to 100), an optional `label_prefix` (`synthetic-` by default), the required `token_expires_in_days` (1 to 3650), an optional `request_id`, refused `invalid_request` where it opens the reserved `first-sign-in:` (below), an optional `sign_in`, and an optional `products`. The last is the product profiles each account holds beside `cloud` on the invitation member's vocabulary (ACB-L0-79; ACB-L0-77), `["cloud"]` where absent. The seed creates `count` synthetic accounts and mints one account-scoped token per account through `mint_token`'s own code path: no grant, the given expiry, the label `<label_prefix><n>`. It answers each token value exactly once, as `mint_token` does (API-L0-05). It writes one action record per created account and per minted token naming the calling credential, the operator's session or the harness's token (MAPI-06). The tokens are ordinary minted tokens, shown by `list_tokens` and ended by `revoke_token`.
Every seed, one without `request_id` too, records a batch under a server-minted identity answered as `batch`. The batch row carries the expiry instant fixed at seeding, `swept_at`, and the nullable `seeding_credential`, a minted token's identity and null for a session seed. The expiry instant is the posture's account lifetime from the seeding instant, so a posture change moves new seeds alone and a stress expiry never turns twenty-one days into three mid-test. With `sign_in: true` the seed binds, per account, the second identity ACB-L0-79 states — the `email` identity at the reserved fixture domain `synthetic.turnzero.ai` — in the seed's own transaction beside the `synthetic` identity, and the answer carries, per account, `email`.
A repeat carrying the same `request_id` from the same operator's account answers the same batch's identity, account ids, labels, and, where the seed carried `sign_in: true`, each account's `email`, without token values. The repeat creates nothing, so a retried call never double-creates, and a batch whose values were lost is purged and seeded again.
The purge takes `accounts` (account ids) or `all: true`, an optional `request_id`, and an optional `drop_metering`. Where any named id is a standing account that is not synthetic, the purge refuses the whole request 409 `account_not_synthetic` and deletes nothing. Under either synthetic grant alone it admits an account only where its batch's `seeding_credential` equals the caller's own identity, refusing the whole request 409 `account_outside_batches` otherwise. That refusal names the grant that bounds the caller, and so does the refusal of `all: true` where the posture admits `all: true`. Under `synthetic_seed_purge` the scoping is read first, so an id outside the caller's batches answers `account_outside_batches` whatever account it names. So an account no batch names, a batch a session seeded, and a batch another credential seeded are purgeable under `super_admin` alone.
Where neither refusal answers, the purge runs, per account, the deletion walk `delete_application` runs after approval for each of the account's applications, and then the account's own removal as `delete_account` runs it, its tokens revoked (ACB-L0-47; PLD-L0-66). The application walk covers compute, databases, realms with their passkeys and invitations, bound areas with every partition, secrets, platform credentials, version rows and images, and logs and schedule rows, and it retires the hostnames. After an account's walk returns, the purge deletes the sign-in codes the emailed-code route holds under the account (ACS-L0-12). The purge is reversible tier and never a pending action, decided here. The accounts are the company's own test fixtures holding no customer data, on `set_plan_quota`'s and `publish_library`'s pattern (MAPI-09). MCP-07 rules out the alternative, a tool that approves a pending action.
The purge takes `deploy`'s shape (MAPI-04): it answers 202 at once with the purge's id, the state `running`, and the accounts. It answers instead the state `completed` at once where the call named nothing to walk, every named account joined to another purge or `all: true` naming no account. `read_synthetic_purge { purge }` answers the purge's state and, per account, the state and the receipts the walk wrote.
A second purge naming an account a running purge already holds joins that purge. The account is walked once and its state read from either purge, the joining purge's own state covering the accounts it walked itself. A unique index over the live account rows holds the join across replicas. A joining purge that asked the metering drop raises the walking purge's own `drop_metering`, which its runner reads again before each walk. So the walking purge drops the metering for every account it walks after the join. An account whose walk was in flight at the join may keep its rows until a repeat purge under `drop_metering: true`.
An account already gone completes with zero removals, so a repeat purge of purged ids is a no-op. A walk that stops at a failing member ends the account `failed` with the error and the receipts written before the failing member (the estate receipts, the application receipts, and the failing member's name). A repeat purge naming that account runs the walk again, every member idempotent.
A purge interrupted by a platform restart ends `failed` with the outcome `interrupted` under the rule deploys follow, and a repeat converges. Under that rule the shutdown handler finishes the runs the process holds. An account whose walk was in flight at the interruption still ends `completed` with its receipts where the walk returns. A sweep on the stale-deploying sweep's cadence finishes a running purge whose heartbeat is older than the deploy's stale bound. A store failure of the runner's own ends the purge `failed` with the outcome `runner_failed`. A repeat carrying the same `request_id` answers the same purge.
With `drop_metering: true` the purge also removes each account's meter rows, so the test leaves no trace in platform usage. The meter rows are its usage events, its storage and egress call rows, and its applications' traffic, verification rollup, and database sample rows. The action records stand, because MAPI-06 makes the operational record append-only. The realm event log's rows stand, because no action removes them (ACS-L0-02).
The estate runs under a posture, one value of the control plane's setting `SYNTHETIC_ESTATE`: `off`, `compat`, or `stress:<YYYY-MM-DD>`. The date is the stress posture's expiry, after which new seeds take `compat`'s cells while the purge and every other ceiling read the value's posture. `on` is an alias of `compat`, and any other value reads as `off`.
The ceilings are constants this statement states and the code holds, never settings rows, so no runtime surface raises them. They are shared: a seed counts against them whichever of the two synthetic grants its credential holds. Each is stated as its `off`, `compat`, and `stress` cells with the refusal it names. Standing synthetic accounts are 0, 25, and 6,000, the seed refusing 409 `synthetic_ceiling_reached`. Standing synthetic applications, and those on a paid plan, are 0 and 0, 50 and 10, and 12,000 and 12,000. They are refused 409 `synthetic_ceiling_reached` at `create_application` and at `set_plan` for a synthetic-owned application. Accounts one seed call creates are none, 25, and 100, the seed refusing 403 `synthetic_posture_refuses`. Token expiry the seed admits, in days, is none, 3, and 30, the seed refusing 403 `synthetic_posture_refuses`.
Account lifetime, in days, fixed at seeding and the sweep purging at its end, is none, 3, and 21, with no refusal, the catch-all's bound under `off` being `compat`'s. Accounts seeded per operator account per UTC day are 0, 1,000, and 6,000, the seed refusing 409 `synthetic_ceiling_reached`. `all: true` on the purge is refused, refused, and admitted to `super_admin` alone, the refusal 403 `synthetic_posture_refuses`, so a purge under `compat` names the accounts it removes. The posture's expiry is none, none, and the date in the value. The seed reads its two ceilings by one call's count under no lock. So seeds admitted concurrently may together pass a ceiling by at most their counts, corrected at the next seed's read and by the lifetime sweep.
The `synthetic_seed_purge` grant has a standing ceiling of its own, a constant the code holds beside the cells. Under it a seed is refused 409 `synthetic_ceiling_reached`, naming the ceiling `standing_accounts_per_credential`, once twelve standing synthetic accounts are ones the calling credential seeded. The count reads the batches that credential seeded against the standing synthetic accounts, ahead of the posture's own ceiling. An account whose purge is still in progress counts until its walk removes it, so the count errs closed. It is read under no lock, so two seeds admitted at once may both pass it. A token minted to replace another starts at zero while the lifetime sweep purges the old one's batches. So a disclosed copy holds at most twelve of the standing accounts. A `synthetic_estate` token and a `super_admin` credential meet no such ceiling.
An account seeded under that grant holds one application, on the Free plan. A paid plan at `create_application` or `set_plan` is refused 409 `synthetic_ceiling_reached` naming the ceiling `paid_applications_per_account`, under every posture, and a second application meets the Free plan's own limit. The account is told by its batch's seeding credential, a token the grant bounds, whether or not that token still stands. So a disclosed copy's accounts take none of the estate's paid-plan places.
The two writes, the seed and the purge, are admitted only while the posture is not `off`. While it is `off` they refuse 403 `synthetic_estate_disabled` before any other check. The dispatcher's switch gate runs ahead of the credential-kind, scope, grant, bound, and destructive-class gates, so a customer's session meets this refusal and not `grant_required`. Their rows, marked `switch: synthetic_estate` in the enumeration, are listed as tools while the posture is not `off` and unlisted while it is. They are listed only to a connection whose credential holds `synthetic_estate` or `super_admin` or is bounded by `synthetic_seed_purge`, both rules MCP-08's. The listing is derived from the enumeration's own marks, the credential, and the setting, and no list is kept beside it (MAPI-11).
`read_synthetic_purge`, `read_synthetic_signin_code`, `read_synthetic_account_state`, and the reads of existing synthetic accounts keep working with the posture `off`. So a stranded estate is inspected, swept at its lifetime by the lifetime sweep this statement states, and, after the posture leaves `off`, purged by hand.
The lifetime sweep is the platform's own locked pass in the management service, every ten minutes on the stale-deploying sweep's cadence, one replica per tick. It runs outside the switch gate, so it meets no posture gate. It starts each expired batch's first purge once, by a compare-and-set of `swept_at` from null in the statement that starts the purge, so a second tick starts nothing. That purge carries `drop_metering: true`, the batch's own requesting account, and a `request_id` of null, never a batch identity. A batch identity would let an operator's earlier purge under the same key answer the sweep's as a repeat and start nothing. The purge also carries an action record whose actor is the requesting account under the credential kind `platform_sweep`, the platform's own act, which holds no grant and no destructive class (MAPI-06; MAPI-12).
A batch whose seeding credential reads revoked or expired is swept at the next tick, so no batch outlives its credential. A batch whose credential is null is swept at its expiry alone.
The pass's catch-all returns what a failed walk left. Each tick, a builder-realm user row carrying the `synthetic` flag is due where it is older than the posture's lifetime by its own creation instant (`compat`'s lifetime under `off`). It is also due where a swept batch whose expiry is past names it. The sweep starts one purge per requesting account for the due rows under a fresh per-tick `request_id`, never a batch identity. The requesting account is the batch's own where a swept batch names the row. Otherwise it is the account opened by the first entry, in the setting's order, of the control plane's operator set `SUPER_ADMIN_IDENTITIES` whose identity has opened one (MAPI-09). So where no entry has, the rows a swept batch names are still purged under the batch's own account, while the rows no batch names are skipped with a marker line once per pass.
A row is excluded while an unswept batch names it or while a purge account row in `pending` or `running` holds it. So a walking account is never walked twice, and one tick's purge is not restarted at the next. A tick that swept a batch or started a catch-all purge writes one info line to the control-plane stream naming the batches it swept, the purges it started, and the count of the catch-all's accounts. A tick that did neither writes none. The console marker line below is apart from that line.
`read_synthetic_signin_code`, request `{ account | address, binding? }`, answers the unspent codes the emailed-code route holds for the account (ACS-L0-12 states the holding and when a start writes it) newest first. Each carries its issued instant, its expiry instant, its binding hash, and the attempts remaining. Where `binding` names one browser's binding hash, the base64url of the SHA-256 of the cookie value, it answers that ticket's code alone. It is admitted for an account in the caller's own batches under `synthetic_estate` and for any synthetic account under `super_admin`.
Under `synthetic_estate` any account outside the caller's reach, a standing customer account among them, refuses 409 `account_outside_batches`, the reach read first; under `super_admin` a standing account that is not synthetic refuses 409 `account_not_synthetic`. An id no account stands for reads as no codes under `super_admin`, and every read lands in the action record (MAPI-06). `read_platform_usage` answers the estate whole under the optional top-level member `synthetic` ACB-L0-79 states.
The codes held under an account are its own sign-in's on the builder realm, and those of fixture end users in the realms of applications it owns. ACS-L0-12 holds a code in an application's realm only where the realm's owning account is synthetic and the address is at the fixture domain. So the read answers such a code by the owning account and the start's binding hash, and answers nothing of a person's sign-in. It answers no code for an account whose record is gone, under either grant, whatever row a start left standing under it until the sweep's delete.
The management service writes a console-log line carrying a marker constant when a seed is refused at a ceiling, when the standing accounts pass half the posture's ceiling, and when the sweep starts a purge over an account that still stands. Such a purge is every catch-all purge, and a batch's purge where an account the batch names outlived its seeder's own purge. The service writes no line for a batch's purge whose accounts are all gone, which completes with zero removals and is started all the same for the metering it drops. It writes none there because the ordinary batch's seeder purged it long before its expiry, and a line there would mail the operator at every seed's expiry. The line's count is the accounts still standing.
A sixth scheduled-query rule in `plane_alerts.bicep` reads the line, counting those three events alone and never the catch-all's skip line, which a standing empty list would raise every pass, one of the alert kinds PLD-L0-67 counts. The wire route `POST /api/v1/actions/seed_synthetic_accounts` under a minted token carrying either synthetic grant is a harness's route, so a token value never passes through an AI transcript.
The twelve refusal names this statement owns are rows of `schemas/wire_errors.json` (MAPI-15). `synthetic_estate_bounded` (403) answers a token the grant bounds on a row outside the bound. `synthetic_seed_purge_bounded` (403) is the same answer for a token the `synthetic_seed_purge` grant bounds, on a row no grant marks. `publication_bounded` (403) is the same answer for a token the `publication` grant bounds, `feedback_queue_bounded` (403) for a token the `feedback_queue` grant bounds, and `issues_bounded` (403) for a token the `issues` grant bounds. `issues_level_refused` (403) answers a relayed act the level of the token's `issues` grant does not admit, naming the level and the acts it admits.
`synthetic_estate_disabled` (403) answers every wire write of the estate while the posture reads `off`. `synthetic_posture_refuses` (403) answers an act the standing posture does not admit, and a seed past the `synthetic_seed_purge` grant's own bounds. `synthetic_ceiling_reached` (409) answers a count the posture bounds, and the `synthetic_seed_purge` grant's own two ceilings. `account_not_synthetic` (409) covers the code read and the state read beside the purge, the two reads under `super_admin` alone. `account_outside_batches` (409) answers the purge, the code read, and the state read under a synthetic grant naming an account outside the caller's batches. The two reads read the reach first, as the purge does under `synthetic_seed_purge`. Under `synthetic_seed_purge` it also answers a purge repeating another credential's `request_id`.
A test in the platform's suite holds the seed with its batch and its `sign_in` option, the purge with its scoping under the narrow grant and its join, the reads, and the posture with its grammar and its alias. It holds each ceiling at its refusal, the grant, and the bound of each bounding grant at the dispatcher's gate, in the listing, and on the two data planes. It holds the `synthetic_seed_purge` grant's three rows, its bounds on a seed, its two ceilings, and its scoping of the purge, the read, and both repeats. It holds the sweep — its once-per-batch mark, its null `request_id`, its credential rule, and its catch-all — the code read, the usage member, the alert line, and the interruption. It holds an application realm's code read, the purge's delete of held codes, and no code for a gone account.
`read_synthetic_signin_code` takes `address` in place of `account`, one of the two required, `binding?` beside either. The address is one in ACB-L0-79's label form at the fixture domain, lowercased. The read resolves the account through the realm store's `email` identity lookup on that address. It answers the codes held under the account where one exists and those held under the address where none, `account` null until the account exists and its id after, and writes nothing (MAPI-04). An address held by an account outside the caller's reach is refused 409 `account_outside_batches`, as the read by id refuses one. An address outside the fixture domain is refused 409 `address_not_synthetic`, the twelfth name this statement owns, and answers nothing, the refusal carrying no address. The typed address reaches no action record, log line, usage row, or refusal detail except as PLD-L0-79's keyed member.
A first sign-in at the fixture domain (ACB-L0-79) writes one batch at its confirmation. Its requesting account is the operator set's first opened account (MAPI-09), its `seeding_credential` null, and its `request_id` `first-sign-in:<lowercased address>:<account id>`. Its expiry is the posture's lifetime from the creation instant, so the lifetime sweep takes an abandoned account by its batch as it takes any expired batch, and the catch-all reads nothing new. A label re-used after its first account's purge writes a second batch, the first untouched. The prefix `first-sign-in:` is reserved to that write: a seed carrying a `request_id` opening with it is refused 400 `invalid_request`, and no seed answers such a batch as a repeat. The form is one exported constant of the estate module, read by the store and by the confirmation.
Under `synthetic_estate` the purge, the code read, the state read, and `read_synthetic_purge` admit, beside the batches the credential itself seeded, every first-sign-in batch and the code held for a first-sign-in address before its account exists. Every such credential's reach widens to those batches within the one operator account the harness's tokens share, so no adoption is written. A disclosed live-pass or journeys-hosted copy then reads the code of, and purges, another run's stranger account and no customer's (CRD-14; CRD-17). `super_admin` reads as today. A token the `synthetic_seed_purge` grant bounds reaches no first-sign-in batch: the code read and the state read are refused it `grant_required`, and the purge and the purge's read answer only what its own credential seeded (CRD-25).
`read_synthetic_account_state`, request `{ account }`, answers a synthetic account's state in six parts, each in its customer row's shape and carrying no secret value. They are the account record as `read_account` answers it, without the caller's credential members, the applications as `list_applications`, and each application's status with its environments as `read_status`, without `tables` and without a wait. They are its versions as `list_versions`, the tokens as `list_tokens`, never a value, a hash, or anything a token could be rebuilt from, and the usage as `read_usage`. The six shapes have one home, the payload file's `shapes`, which this row references by entry; each customer row's inline response equals its entry, a test holding them equal.
Its reach is the code read's, the hosted trial's token refused `grant_required`. Under `synthetic_estate` any account outside the caller's reach refuses 409 `account_outside_batches`, a standing customer account and an id no account stands for among them, the reach read ahead of the not-synthetic check. Under `super_admin` a standing account that is not synthetic refuses 409 `account_not_synthetic` and an id no account stands for 404 `not_found`.
MAPI-17: The operator signal is one grant-marked row of the enumeration, `record_operator_signal`, by which a company test harness reports a run's ending, or its result, to the operator under a source name. The row is `resource` `account`, reversible tier, marked `grant: synthetic_estate` (MAPI-09). So the dispatcher's grant gate admits a credential holding `synthetic_estate` or `super_admin` and refuses every other credential `grant_required`, a customer's session among them, save where a refusal that answers a credential ahead of the grant gate answers it first (MAPI-14). A token the `synthetic_estate` grant bounds is admitted to it as it is to the synthetic estate's five rows (MAPI-16). The row is no row of the synthetic estate, which stays the five rows MAPI-16 names: the act touches no test fixture and names no account.
It carries no `switch` mark, so it is listed and answers whatever the `SYNTHETIC_ESTATE` posture reads. It carries no `request_id`, each call being one report, and no `clients` member. Its annotations are `readOnlyHint` false, `destructiveHint` false, and `openWorldHint` false, with no `idempotentHint` member, each call writing another counted line (MCP-11). The request names `event`, `source`, and an optional `detail`. `event` is one word of a closed vocabulary of two: `ok`, a run that ended clean, and `failed`, a run that did not end clean or a result that failed. The words are generic, and the name of what is reported is carried in `source`, which matches `^[a-z0-9_.-]{1,64}$`.
`detail` is a string of at most 200 characters, a null refused as any other non-string, counted on the wire in code points as a JSON Schema `maxLength` counts them. The MCP tool's derived validator counts UTF-16 units and so refuses, ahead of the platform, a detail of characters outside the Basic Multilingual Plane that the wire admits. `detail` is scrubbed before it is written: the value of a minted token, of an end user's session, and of a transfer grant, an address, and a URL are each replaced by a marker.
A `source` or a `detail` that contains `control_plane_`, in any letter case, is refused. It is refused because that prefix begins every marker the platform's own log lines carry and the platform's marker rules match a marker over a whole line (PLD-L0-67), so a free member naming a marker would satisfy another rule. A `source` that contains the prefix of one of those three credential values is refused too, a `source` being written to the line as given. A request outside these shapes answers 400 `invalid_request` with the member named in the detail, and the action adds no refusal name (MAPI-15).
This paragraph qualifies "three credential values" in the scrub and in the refused `source` with the egress key (SEC-L0-18). A value of its shape in `detail` is replaced by a marker as the other three are, and a `source` that contains its prefix, `turnzero_cloud_egk_`, is refused.
The act writes one line to the management service's standard output, a JSON object of exactly the members `marker`, `event`, `source`, `detail`, and `credential` in that order. `marker` is the constant `control_plane_operator_signal`, and `detail` is the scrubbed text or null. `credential` is the calling credential's identity, the value the action record names (MAPI-06), a minted token's id and null for a session, which carries none, so a line a token wrote is attributable from the log store alone. The act writes nothing of its own beyond the line, no table, no setting, and no fixture, and the dispatcher records and meters the call as it does every action's (MAPI-06). The answer is `recorded: true` with the event and the source as given.
The tier is reversible and not observe because the line can notify the operator. PLD-L0-67 owns the two alert rules that read it, the failure rule that counts `failed` lines split by a bounded source and the heartbeat rule that reads the newest `ok` line of one named source. This statement owns the row, the vocabulary, the bounds, the scrub, and the line. The action has no rate bound and no refusal name of its own: a harness makes a few calls a run. For any other holder of the grant, the platform's admission window per source address (PLD-L0-67), inside the edge's own limit on the management path, bounds the lines one address can write.
Every holder of the grant is admitted to the row, so a disclosed copy of any token carrying it can write a line under any source name. Among those lines are a `failed` line that notifies the operator and an `ok` line under the source the heartbeat rule reads, which keeps that rule from firing. The line names its credential, and the credential register's rows state that reach (CRD-14; CRD-17).
The event words and the wire call have one home beside the platform's other operator clients. A client script exports the two words and makes the one call, and it loads the operator client inside the call alone, so that importing the words runs nothing. The platform's suite holds the script's words, the platform module's words, and the payload schema's `enum` equal. It also holds the request as the client sends it, the client's refusals ahead of a call, and a refusal's status and code passed on as the wire call threw them.
MAPI-18: The five feedback actions, `submit_feedback`, `read_feedback`, `rate_experience`, `settle_feedback`, and `record_check`, are rows of the enumeration on the `account` resource (API-L0-20; the AI tool interface's feedback scenario). Beside them stand the relay `relay_issue_act` and the two space rows `create_issue_space` and `list_issue_spaces`, whose forms the issue service PRD's relay and provisioning rows state and whose bounds and refusals this statement states. Each is registered while the control plane's setting `ISSUE_SERVICE_ORIGIN` names the issue service, and unlisted, refusing `not_yet_provisioned`, while it is empty (MCP-08; MAPI-10).
On every call to the platform's own space the plane presents the space's `operator` token the setting `ISSUE_SERVICE_TOKEN` carries by secret reference (CRD-19), on the package's 0.3.0 wire, the recovered mark alone on the 0.2.0 wire. On a call naming `space` it presents that space's own token, read from the plane's vault or, for a standing pair's space, from custody, and on the relay the named space's own token. On a provisioning act and on an account space's creation it presents the provisioning credential the register's issue service provisioning credential row states. The platform space's owning account is the setting `ISSUE_SERVICE_PLATFORM_ACCOUNT`, empty where unset (the issue service PRD's relay row).
Each of the four feedback rows takes `space` beside its own members (the issue service PRD's actions row); `record_check` takes none. `space` names, as a lower-case UUID, a space the acting account holds, which the call then addresses under that space's own token: a space of the account's own, an application's own space, or one space of a standing pair. An identifier matching none refuses 404 `not_found` before any token is read; a token that does not answer refuses 503 `issue_service_unreachable`. A request naming `application` or `environment` refuses `invalid_request` naming `space`. The bounds below are judged before the space is resolved.
With `space`, `read_feedback` reads the space whole in every form and `settle_feedback` settles an issue of it, no grant read. The scope gate refuses a token bounded to an application on the four rows `token_scope_refused`, the form naming no application (API-L0-17). The removal of `application` and `environment` from the four rows is MAPI-02's thirty-eighth use of its within-version allowance, made while the platform held one builder account and six live applications, a synthetic account aside. The paragraphs below state each row on the platform's own space.
`submit_feedback` is reversible tier, unmarked, carrying `admits: ["synthetic_estate"]` (MAPI-16), so any bearer, any account-scoped minted token, and a token the synthetic-estate grant bounds file into the platform's own space. The request names `source`, the actor's kind, `person`, `agent`, or `system`, with `provider` and `session` on an agent's, both or neither. It names `kind`, one of the record's seven, `bug`, `gap`, `docs`, `friction`, `question`, `task`, and `praise`, or the 0.2.0 words `missing_capability`, `documentation_gap`, `refusal_not_understood`, and `usability`, read as the record's (the package's XIT-01), and `title`, 1 to 200 characters. A `question` or a `task` is refused `invalid_request` from a filing the plane gives the `field` origin, ahead of any call.
Its optional members are `text` (or `body`), of at most 20,000 characters, `impact` (or `severity`, read as an impact), and `workaround` and `proposed_resolution`, each of at most 4,000 characters. They are also `labels`, `evidence`, `restricted`, `problem_key` (or `key`), and `repeat_of`; two names of one member are refused together. `evidence` holds `action`, `refusal`, `reference`, and `code_site`, each 1 to 200 printable characters, the 0.2.0 `environment` and `version`, which the plane reads as one build the report saw, and a `context` of at most 20 short named strings.
The request declares neither `personal` nor `excerpt`, and a call that names either is refused as MAPI-22 states. The `report` the answer carries holds no `personal` member.
The plane gives each report its origin and no filer names one (the package's XIT-04). On the platform's space a `system` filing under a credential holding the `synthetic_estate` grant is `beta`, the AI beta run's, and every other filing `field`; on a space the request names a person's filing is `person`, an agent's `workspace`, and a program's `test`. On a space the request names, a confirmation is relayed as given under that space's own token, and the service then judges it, and a filing's link by evidence, by the report's origin (the package's XIT-05).
`problem_key` names the problem among the caller's own reports: a same-key repeat with the same evidence answers `retried`, and one with new evidence files a second report linked to the same issue, `linked`. With `key`, `recovered: true`, and no member of a filing, the call is the 0.2.0 recovered mark, relayed on the 0.2.0 wire, which settles the open filing the key names among the caller's own as recovered. The service settles it only where the caller's own filing under that key opened the issue and every report on it is the caller's; otherwise it refuses the mark, and the call answers 404 `not_found` (the package's XIT-01).
The answer carries the caller's own report, the issue through the projection, the outcome, `filed`, `linked`, `retried`, or `noted`, up to three `candidates` it may repeat, `masked`, the credential forms the service's scanner hid, and `stamped`. The plane answers each candidate as the service answers it. Its title is the issue's or null by the package's rule, so a candidate carries no title that a report of an origin other than `workspace` or `platform` gave (the package's XIT-05). `repeat_of` beside a filing confirms a candidate after the filing, and `report` with `repeat_of` and no member of a filing confirms one alone, the contract's `follow` (the package's XIT-05); a filing that confirms counts two calls in the bound.
On the platform's own space, for a credential that does not read the queue, the plane reads the issue a confirmation names before it relays the `follow`, the read counted once in the read bound. A confirmation that names a restricted issue is answered 404 `not_found` exactly as one that names no issue is, and links nothing. A credential holding `feedback_queue` or `super_admin`, which reads the queue, has its confirmation relayed as given, with no read. The service then judges it: it confirms a report of the origin `field` or `beta` onto no restricted issue under any token, and refuses the `follow` as one naming no issue (the package's XIT-05). So that credential is answered 404 `not_found` too, and nothing is linked. The plane's reading stands as a second check: it judges the record's own `restricted` member, and answers a record that carries none as a restricted one.
On that space, a filing whose answered issue is restricted, or carries no `restricted` member, answers a credential that does not read the queue its own report, the outcome as given, and a null `issue`, no member naming the issue, whatever linked the report. A `repeat_of` naming that issue is answered as one naming no issue is. The report stays filed. The service itself links a report of the origin `field` or `beta` to no restricted issue by its evidence, so such a filing is answered the unrestricted issue it joined or opened (the package's XIT-05). A filing that asks the mark itself, and a repeat under the filer's own key onto a restricted issue, answer that credential the null `issue`. The plane's withholding stands as a second check, judged from the record's own mark.
On the platform's space, for a credential that does not read the queue, the plane relays the recovered mark only where the filer's filing under that key opened the issue it lands on, and that issue is unrestricted and holds that filer's reports alone. Otherwise the plane refuses it 404 `not_found` before any write. A key under which the filer holds no report is refused by the plane as the service refuses it, relaying nothing, and a read the service could not answer is refused as any unanswered call is. A relayed mark answers the issue's `id`, `status`, and `disposition` alone, and the plane's two reads ahead of the mark count in the read bound.
Where the evidence quotes a reference, the plane reads the newest row of the action record carrying it under the acting account within the twenty-five days before the filing, once more after the record's one-second flush where the first read finds none (MAPI-06). Under a credential holding the `synthetic_estate` grant it reads the accounts of the batches that credential seeded too, the synthetic-batch clause (MAPI-16).
Where a row joins, the evidence carries the row's `action` and the context the filer gave. Where the row's outcome is a refusal and the filing's kind is `bug`, the evidence carries that `refusal` and the row's `code_site` too and is stamped, and the request goes to the service with `evidence_basis: stamped`. Where the call completed or waits for approval, or the filing is of another kind, the request names no basis, no refusal, and no code site, and the report stands `claimed`. An answered action names no problem, and a report of another kind names a problem other than the refusal it cites, where the service joins stamped reports on their action, refusal, and component whatever their kind (the package's XIT-05).
The `seen_in` of a report whose row joins names the build that answered the call: its version the build's source commit, and its environment the plane's, `development` where the estate's apex opens `dev.` and `production` otherwise. Its line is `cloud.plane` where the platform's space declares that line and null otherwise (the package's XIT-14). Where no row joins, the filer's evidence stands `claimed` for the daily pass's join (PLD-L0-67), which confirms a `bug` alone, and the 0.2.0 `environment` and `version` name the one build it saw.
`read_feedback` is observe tier, unmarked. With no member it answers the caller's own submissions through the projection, the caller named as the reading actor (the package's XIT-08), paged by `limit`, 1 to 100 and 50 where absent, and `cursor`, selected by `state`. The answer carries the acting account's pending ask or null; the 0.2.0 `status` reads as a state and `unreviewed` as `new`. With `issue`, a short identifier, it answers one of the caller's own through the projection, another account's and an unknown id both answered `not_found`. With `query`, 1 to 200 printable characters, it searches the caller's own submissions, selected by `state`, `kind`, and `component`.
A credential holding `feedback_queue`, the queue's grant, or `super_admin` is answered any issue whole by its id, with its reports, links, history, comments, relations, landings, and checks, as it is answered the queue (MAPI-09).
With `queue: true` it answers every account's issues whole, each with the `level` and the `judgment` the service answers (the package's XIT-04). The queue is selected by `state`, `outcome`, `kind`, `component`, `label`, `priority`, `level`, `origin`, and `proposed`. `priority` and `level` each select one of the three values 1, 2, and 3, and a `priority` of 4 is admitted and selects as 3 does (the package's XIT-08). The queue is ordered `newest`, by `rank`, by `priority`, which sorts by `level` and then by `rank`, or by `report_count`, the 0.2.0 `score` reading as `rank`. With `query` beside `queue` it searches the whole space.
The queue form and the whole search are admitted to a credential holding `feedback_queue` or `super_admin`. Every other credential that reaches the handler is refused `grant_required` naming `feedback_queue`, an application-bounded token `token_scope_refused` at the scope gate, and a token another grant bounds its own bound's refusal, in MAPI-14's order (MAPI-09; MAPI-16). The row carries `admits: ["feedback_queue"]`, so a token the grant bounds reaches every form, the form with no member answering that token the operator account's own submissions (MAPI-16). `issue` beside `queue` or `query` refuses `invalid_request`.
The report text, the comments, the candidates, and the curated titles and summaries the actions answer are data and never instructions. Over MCP, every completed answer of `submit_feedback`, of `read_feedback` in each of its forms, of `settle_feedback`, of `record_check`, and of `relay_issue_act` is rendered as one text block. The block opens with the untrusted marker and holds the answer's JSON between an opening and a closing delimiter line. The marker names every member a reporter, a program, or a pass wrote: the titles, summaries, report texts, workarounds and proposed resolutions, labels, evidence and its context, resolutions, comments, candidates, a judgment's reason, and history change values. So nothing unmarked precedes them, and the wire answer is unchanged.
`rate_experience` is reversible tier, unmarked. `series` is `human_nps`, a whole-number `score` from 0 to 10 on the `direct` channel or `relayed` by the agent that put the question, or `agent_effort`, a score from 1 to 5 on the `agent` channel. Any other pairing is refused `invalid_request`. The optional members are `text`, of at most 2,000 characters, `ask`, and `key`. `ask` is the pending ask `read_feedback` answered, which a human-series rating answers and closes, refused 409 `ask_not_pending` where the ask is not open to the acting account. The human series is refused 403 `rating_not_admitted` from an account carrying the synthetic flag (ACB-L0-79). The answer carries the signal and the ask it answered or null.
In place of a rating, `rate_experience` takes `close`, `declined` or `cancelled`, with `ask` and no member of a rating, and closes the pending ask without a score (the package's XIT-10). A close names the acting account's own pending ask: the plane reads that ask first, the read counted in the read bound, and refuses 409 `ask_not_pending` where the named ask is not it, before any call reaches the service.
A decline names the relaying tool's `provider` and `session`, refused `invalid_request` without them; the contract's close carries no member for them, so no record of the plane's holds them until its action record gains a member. The decline reaches the service as the account's person actor and the cancel as its agent actor. A close beside a rating member or without `ask` is refused `invalid_request`. The answer to a close carries the signal null and the ask as it now stands.
`settle_feedback` is reversible tier, unmarked, carrying `admits: ["feedback_queue"]`, the queue's own grant, decided at the handler. On the platform's own space the act is admitted to a credential holding `feedback_queue` or `super_admin` and refused every other credential `grant_required` naming `feedback_queue`; with `space` it settles an issue of a space the acting account holds with no grant read (ITS-L0-03). A token holding the grant and not `super_admin` is bounded by it as MAPI-16 states: refused `feedback_queue_bounded` on every other row no earlier gate answers, a row another grant marks keeping `grant_required` (MAPI-14; MAPI-16). It is minted on MAPI-14's terms from a session holding `super_admin`. So a session that triages the queue from an AI client holds no credential a planted instruction could turn to a filing or to any act beyond the queue.
The act names `issue` and `act`, one of `settle`, `merge`, `wait`, `reopen`, and `unmerge`, with an optional `key`. `settle` names an `outcome`, one of the record's eight, and, where the outcome is `duplicate`, `target`, the master. A `resolution` of 1 to 4,000 characters is required for every outcome but `noted` and `duplicate`, and the 0.2.0 `disposition` reads as its outcome (the package's XIT-01). `merge` names its `target` and closes the issue `duplicate`; `wait` names its `resolution`; `reopen` and `unmerge` take neither. `approve` and `decline` are retired and refused `invalid_request` by name: no person approves or declines a duplicate, which the service's passes merge where they agree on stamped or confirmed evidence (the package's XIT-07). An act the issue's state excludes refuses `invalid_request` naming the service's refusal, and the answer carries the issue as it now stands.
`record_check` is reversible tier, marked `grant: synthetic_estate` on MAPI-17's pattern (MAPI-09): the dispatcher's grant gate admits a credential holding `synthetic_estate` or `super_admin` and refuses every other credential `grant_required`. A token the grant bounds is admitted to it as to the synthetic estate's rows (MAPI-16). The request names `check`, the run's stable key of 1 to 200 printable characters, and `result`, `green` or `red`. Its optional members are `covers`, the components and actions the run exercised, `builds`, at most 20 builds it ran, `cause`, `harness`, `estate`, or null, `component`, `evidence` naming no build, `key`, and `source`, `system` where absent, with an agent's `provider` and `session`.
The plane posts the check into the platform's own space naming the acting actor, so the service judges the key among that actor's checks, and answers `{ check, issue, outcome }` (the package's XIT-17). The filing bound counts the call.
To a credential that does not read the queue, `record_check` answers `issue` as a filing's answer does: through the projection with no report, or null where the issue is restricted or its record carries no `restricted` member. Its `check` then carries no `lease` and no `held_by` member, and the `issue` member of that `check` is null unless it names the issue the answer carries. The plane judges this from the check's own answer and makes no further call. A credential that reads the queue is answered both whole.
A refusal the dispatcher answers, and an internal failure, carries after its `detail` the known-issue line where the plane's copy of the known-issue table names the action and the refusal (PLD-L0-67). The line names the issue's identifier and its trusted workaround where one stands, and, once a fix has shipped, the build that carries it and a request to file again naming `repeat_of`. The line is read from the process's copy, loaded at boot and every minute, never from the store or the service at the call. The dispatcher also writes on every action record row the build that answered the call and, on a refusal the handler threw, the code site, `<file>:<line>` (MAPI-06).
The plane bounds the calls it relays in fixed windows of one minute. Each count is taken before the call as the service counts its own, a refused call counted with the rest, and each past its figure is refused 429 `feedback_rate_limited` with a cause word of its own. The filings, ratings, closes, and checks are at most 20 from one account and at most 100 from every account together. The reads of `read_feedback` are counted once per service call the form makes: two for the read with no member, its list and its ask read, and one for the other forms. They are at most 20 from one account and at most 50 from every account together.
Each relayed call counts once in the window of the credential that made it, at most 60 a minute for one token by its identity, a session's account where it has none (MAPI-06). It counts once more in its target space's aggregate, at most 150 a minute for an account's own space. A relayed call counts once more there for each call the platform may make beside it (ITS-L0-05). The platform's own space counts its relayed calls in the two aggregates above, a read act among the reads and every other act among the filings. An account creates at most 5 spaces a minute through `create_issue_space`. The relay's figures and the overshoot stay at or under two-thirds of a space's own rate, so a space's other callers keep their third.
An account holds at most 50 spaces of its own. At 50, a creation naming a space it does not hold is refused 403 `space_creation_ceiling` with nothing created, and a repeat naming a space it holds answers `created: false`. The license is read ahead of the minute's bound and this ceiling. A creation by an account lacking the `blueprint` profile, a repeat naming a space it holds among them, is refused 403 `blueprint_required` and does not count toward the minute's 5 (ACB-L0-82).
The figures are constants the code holds. They are sized so that the relayed total, the read aggregate, and the replica overshoot together stay at or under two-thirds of the service's space rate of 300 calls a minute, one count across the permission levels (the package's XIT-12). The other third is headroom for the platform's own calls: the erasure, the export's pages, the asks it opens and reads, and the daily pass. The export itself is not bounded, being one of the calls the headroom protects.
The pending ask's read the MCP layer makes beside a completed `read_status` or `list_versions` result is one of those calls, and so is the live-fixed read beside it, the account's `fixed` issues through the projection (CHI-L0-14). Each is made at most once a minute for the account and both count in the 30 a minute from every account together, each read under a two-second bound, the aggregate carrying the same replica overshoot. A read past a figure or the bound leaves the result without its block and refuses nothing. The relayed share, the ask reads' figure, their overshoot, and a reserve of 25 calls a minute for the rest together stay at or under the space rate, the sum the suite holds.
The overshoot is what the management replicas together can admit past a figure before a flushed row shows every replica's hits, each replica reading a window as its last flushed row plus its own unflushed hits and flushing every second. It is at most the plane's replica ceiling of nine times five calls a replica in one interval, a design figure the suite holds beside the sum and the template's replica count. The service's own rate refusal answers under the same name.
A call the service could not answer answers 503 `issue_service_unreachable` with the cause word in the detail. The causes are the transport failing, the call passing the plane's bound of ten seconds, a fault of the service's own, the router's quota refusal on it, and a refusal of the platform's own credential. A refusal of the platform's credential is also written once per interval to the control plane's record as a warn line naming the cause, so a lost, revoked, or unset token is read there rather than found at a customer's deletion (CRD-19). The service's not-found refusals answer 404 `not_found`, and every other refusal of the service, a lease's among them, answers `invalid_request` with its name in the detail.
On the relay a refusal of the service by the act's content, the issue's state, a lease, or a record that does not stand answers `issue_refused` with the service's own status and its name in `refusal`. The five refusal names this statement owns, `feedback_rate_limited`, `issue_service_unreachable`, `rating_not_admitted`, `ask_not_pending`, and `issue_refused`, are rows of `schemas/wire_errors.json` (MAPI-15), the last carrying the service's status and a `refusal` member and the rest no member beyond the base six.
A test in the platform's suite holds, over the package's test double, the eight rows, the words against the package's, the bound gate's admission of the bounded tokens, and each refusal at its gate. It holds each cause a service out of reach answers, the stamp with the synthetic-batch clause, `record_check`, and the known-issue line. It holds the queue grant's mint, its reach in every form of the read and on the settle, its refusal of every other row, and its refusal on both data planes. It also holds the plane's bounds with their figures' sum, the relay's bounds, the export's member, the deletion walk's member with its failure, its retry, and its form for an account already gone, and the MCP layer's rendering and blocks.
MAPI-21: The application-grain data archive is three rows of the enumeration on the `application` resource (API-L0-23). The fifth paragraph states the third, `mint_download_grant`. `request_export` is reversible tier and takes `application`, required, and `environment`, optional. It answers 202 on `deploy`'s shape (MAPI-04) with the export's identifier, the state `running`, the export area's name, the export's folder, and `repeated`. `repeated` is true where the request answered an export already running for the application and environment. `read_export` is observe tier and takes `application` and `export`. It answers the state, `running`, `completed`, or `failed`, the outcome of a failed export, the progress counts, and the instants. Once the export has ended it answers the manifest, and null where the manifest file is gone.
The outcomes are `interrupted`, `table_bound_exceeded`, `database_failed`, `files_failed`, `area_unavailable`, and `runner_failed`. A token bounded to one application reaches the three rows for that application (API-L0-17). An application the acting account does not hold refuses 404 `no_such_application`. An export the named application does not hold refuses 404 `not_found`. A missing member, or an environment outside the platform's two, refuses 400 `invalid_request`.
The export's row is the act's operational record: its state, its counts, and its instants, and no table or file name. The names are the manifest's, a file of the export area, which ends with the area. A running row whose heartbeat is older than the deploy's stale bound is ended `failed interrupted` by the read that meets it, `read_export`'s or `request_export`'s, and no timer sweeps the rows. A pass whose application is deleted stops at its next heartbeat and ends `interrupted`, writing nothing more into the export area the teardown removed. A test in the platform's suite holds the pass over an engine and the storage double, and the two rows over the routes.
Before its pass writes, `request_export` removes the folders of the pair's earlier ended exports from the export area, so one folder stands per application and environment (API-L0-23). The replaced export's row stands, and its `read_export` answers the manifest null. The suite's test holds the removal over the storage double.
`mint_download_grant` is reversible tier and takes `application` and `export`, required, and `local_path`, optional. It answers the export, the application, the environment, `expires_at`, and one line as `command` and `command_windows` (PLD-L0-94). The grant appears inside the two line members and in no other. The row is admitted to the credentials `read_export` admits for the application (OST-L0-08). `local_path` is held to the class `deploy`'s `local_path` admits, and a path outside it refuses 400 `invalid_request` (PLD-L0-86). An export that is not completed refuses 409 `export_not_completed`, and a completed one whose manifest file is gone refuses 404 `not_found`. Each refusal mints nothing. A test in the platform's suite holds the mint, its refusals, and the line run against the suite's own plane.
MAPI-20: `restart_application` is one row of the enumeration on the `environment` resource at the reversible tier (API-L0-22). Its request carries `application` and `environment`, the environment one of the platform's two (PLD-L0-40). Its answer, status 202, carries the contract version, the application, the environment, the version the environment serves, the state `deploying`, and the environment's hostname under the current label. It also carries `health_path`, the recorded manifest's health path as the health gate will probe it, cut at 256 characters (PLD-L0-63). The action record holds the outcome `deploying` (MAPI-06), and its refusals are the platform redeploy's, each a row of `schemas/wire_errors.json` (PLD-L0-84; MAPI-15).