Administration
Govern attention, access, delivery, and operations for a Backend.
The Backend landing is the Control Room for members with operation.read. A Backend without recorded Operations offers Connect an agent app or, after an Organization connection is available, Copy starter request. The request names the exact Backend and Environment and asks for unpublished draft work. Needs attention contains decisions, failures, expiring proposals, and unavailable or degraded delivery evidence. Running work appears under Active Operations and completed requests under Recent work, with recorded resource names and Draft status. Your agent apps distinguishes Organization authorization from successful agent work recorded in the selected Environment; optional Agent Auth identities do not determine OAuth connection readiness.
The Changes area also requires operation.read. Needs review contains valid proposals and current Approval waits. Running work appears under In progress; expired, invalid, and terminal proposals appear under History. Choose a request to open its focused detail, then use All changes to return. Up to three changed resources appear directly under Requested changes. Larger proposals provide grouped counts and a searchable resource browser. Readable values include Field requirements and available parent context; expand Exact JSON and identifiers for the complete comparison. Candidate identity, policy inputs, impact, and quota remain under Technical evidence. Copy review link preserves the exact request and Environment. A human needs operation.approve plus the policy’s approver permission to decide a waiting Candidate. A requester or delegating human cannot approve when a different person is required, but may reject when authorized; rejection requires a reason. Every decision binds the exact Candidate digest and is rechecked on the server. Preview handoff issuance remains an agent task.
The Operations area requires operation.read. Search the loaded list by task, recorded result name, or ID, or filter by status. Choose an Operation to open its detail and use All Operations to return. Needs attention contains waiting, recovering, cancelling, and failed work; queued/running work appears under In progress, and remaining terminal work under History. Results are grouped by resource type. Open one item to read its recorded fields, dates, and state; later work may have changed that resource. A single result shows its values directly. Use Failed only when failures are recorded and Load more results for another batch. Search and type counts cover loaded results. Execution timing, resource reservations, transitions, identifiers, and raw data expand under Technical details. View request, or Review request while awaiting Approval, opens the exact Candidate. operation.cancel requests cooperative cancellation at the next safe point. operation.retry is available only for a recorded retryable failure. Publication rollback requires operation.rollback, the current Published manifest, and retained history. A successful Draft manifest alone never makes an Operation rollback-eligible.
The Delivery area requires backend.read for the selected Environment. Enter a published Data Type key to prepare a copyable example request with explicit Backend and Environment headers and a credential placeholder. The page explains the REST, OpenAPI, API reference, and Context MCP endpoints; links to credentials when apiKey.read is available; and shows publication readiness, locales, traffic for the reported window, and the publishing Operation when permitted. Exact manifests, hashes, schema revision counts, routing, webhook evidence, and storage remain under Technical delivery evidence. This area observes delivery and cannot edit Content.
The Audit area requires audit.read and follows the same Environment selector. It traces each durable Operation version across principal and credential, delegation, Candidate digest, policy, Approval, revisions, outcome, resulting manifest, and delivery impact. Argument and outcome values stay redacted behind durable digests and field names; exact resources link back to Changes and Operations.
Members without operation.read land on the first governance area their scoped role permits. Jetrepo checks every action on the server; a hidden menu item is only a navigation hint, not an authorization decision.
Choose a task
Candidate values are immutable proposal evidence. Field ownership and policy comparisons may use values captured in the Candidate or read from its exact retained base. These reads do not rewrite the original Candidate or substitute current live values for historical ones. If the necessary evidence is unavailable, the view says so. Resources with the same display name remain distinct in counts.
| Governance area | Tasks |
|---|---|
| Control Room | Triage decisions and failures, follow active work, and inspect Environment readiness. |
| Changes | Understand grouped changes, compare readable resource values, and consult exact evidence before a decision. |
| Operations | Follow active or failed work, inspect paginated item results and transitions, then use only the currently eligible cancellation, retry, or recovery control. |
| Connections and access | Assign scoped Organization roles, govern OAuth MCP apps and Agent Auth identities, or manage Organization keys. |
| Delivery | Inspect Published provenance and health, then use the endpoint map or REST/OpenAPI reference. |
| Audit | Trace transactional provenance from principal and Candidate through policy, revisions, outcome, and delivery impact. |
| Settings | Govern publication policy, identity authorities, quota, and retention for the selected Environment. |
There is no single administration permission. Each linked page names the fixed permission for its action and the scope it must match.