ProjectX Operator

Replay one agent run’s full trace, including authorization decisions

Every step in order — the reasoning, the tool, the PDP decision and the outcome — so what an agent did and whether it was allowed to is read from the record rather than reconstructed.

Returns

AgentRunTrace

The cross-tenant agent registry with tools, scopes, budgets and blast radius

Every agent on the platform, each with its live kill state folded in. The one place a platform admin sees every tenant’s automation at once — a view no single tenant should have and the operator must.

Returns

AgentRegistry

Kill-switch engagements

Returns

KillEngagements

Engage the kill switch at agent, tenant or global scope

Global stops every agent everywhere — the break-glass, and a platform-admin action because stopping every customer’s automation at once is exactly the power that must not rest with one support engineer. Records which runtimes acknowledged; the five-second guarantee is the runtime checking the switch on the hot path of every step.

Body

EngageKillSwitchRequest

The live effect of a kill: reached, acknowledged, and any that did not

The count that turns "we pulled the switch" into a claim with evidence. A reached runtime with no acknowledgement past the five-second window is reported as outstanding — not assumed stopped, not assumed fine.

Returns

KillEffect

Restore service after a kill — a separate, deliberate act

A kill does not time out and does not lift itself; the failure mode of an auto-lifting switch is the incident resuming the moment everyone looks away. Restoring needs a reason and tells the runtimes to resume.

Body

LiftKillSwitchRequest

Search audit events across tenants

Omit `tenant` to search every chain at once. Doing so is itself audited, and a search naming one tenant is disclosed into that tenant’s chain: staff cannot read a customer’s log without the log recording it.

Returns

AuditSearchResult

Export audit events for an auditor or a SIEM

The same search as `/v1/operator/audit`, rendered as CSV, OCSF or CEF. A single-tenant JSON export carries the chain verdict; a cross-tenant one does not, because each chain verifies separately and one verdict over five chains would be a claim nobody can check.

What staff did to customers, to whom, when, and approved by whom

Cross-checks the platform chain against the customer chains, and each action against the grant or bulk action it was exercised under. `undisclosed` and `unapproved` are lists rather than counts, because a gap in either control is something to investigate rather than to trend. Disclosure is counted per customer, so one bulk action owes as many disclosures as it reached tenants.

Tenants that have written at least one audit event

Verify a hash chain

One tenant, or every tenant when `tenant` is omitted. Verification is always per chain — a mixed result set has no chain to verify, and a green tick over a meaningless check is worse than none.

Body

ChainVerifyRequest

One compliance report over a customer’s window

`kind` is `access_review`, `privileged_action` or `data_access`. The three that make up an evidence pack, available singly for the reviewer who wants one of them.

The five canaries with current state, history and last failure

The current pillar health (a red canary declares its pillar degraded regardless of any other dashboard), the recent run history, and the last failure per canary.

Returns

CanaryReport

A customer’s Article 30 record of processing activities

Generated live from the catalog rather than stored, so it cannot drift from what is actually being processed. The customer’s chain records that we produced it.

The DPIA support pack for one of a customer’s resources

What is processed, where, why, for how long, and who has actually touched it — kept apart from who *could*, because the gap between the two is the finding.

Seal an evidence pack for a customer’s audit window

Bundles chain verification, the three compliance reports, the Article 30 record and the legal holds in force, sealed with a digest the recipient can check. The digest is recorded in the customer’s chain, so which pack left is evidence and not just that one did.

Body

TenantEvidenceWindow

Search every company’s users by name or email

At least three characters. Disclosed to each company that returned a match. Companies whose directory could not be read are listed, so an empty answer is never mistaken for a complete one.

One company’s users, as metadata

One customer user, with the kinds of factor they have enrolled

Suspend, reactivate or sign out a customer user, or require a new passkey

The reason is required and lands in the customer’s own audit chain and in the notification they are sent. Read-only staff are refused.

Body

CustomerUserActionRequest

What every service is running, and whether it is ready to serve

Asks each service’s readiness endpoint live rather than reading a cached inventory: the reason to open this page is a suspicion that what is running is not what you think, and a cache is the same suspicion one layer down. A service that does not answer is reported as unreachable rather than dropped from the list.

Returns

FleetReport

Every scheduled job across every tenant, worst first

Ordered by whether somebody needs to look: jobs whose last run would not start, then jobs past due with nothing having started them. Both are invisible from a list of operations, which in this failure simply has fewer rows in it than it should.

Returns

ScheduleBoard

Each pillar’s health, from the canaries and nothing else

The Status_Page. It reads only the canaries’ last recorded results and the clock, so it keeps answering when the observability stack that would otherwise report health is itself the broken thing. A pillar is degraded when its canary last failed, or when the canary has not reported for two intervals — the second is called out as `absent` rather than `failed`, because a silent canary is not knowledge of a failure, it is the absence of knowledge.

Returns

CanaryStatusPage

The regulator-ready view of every face-recognition enablement

Every tenant with the module, its lawful-basis declaration, its named accountable owner and its state — the document a regulator asks for first.

Returns

FaceRecognitionRegulatorView

Disable face recognition and purge the biometric data

Destroys the watchlists and face templates and issues a sealed certificate saying so, which the customer can hand to their own regulator. Refused if no purger is configured — disabling blind would leave the biometric data on disk.

Body

DisableFaceRecognitionRequest

One tenant’s face-recognition enablement record

Request face recognition for a tenant

Refused unless all three declarations are present — a signed contract addendum, a structured lawful basis with its detail and retention, and a named verified accountable owner. Two of the three is not nearly there; it is a refusal that names what is missing. Produces a pending request; two approvals from two different jobs are still needed.

Body

RequestFaceRecognitionRequest

Approve a pending face-recognition request

Two seats must both approve — a compliance operator and a platform admin — and the approver must actually hold the role. When both seats are in, the tenant is notified and face-match auditing is locked on and cannot be turned off.

Body

ApproveFaceRecognitionRequest

Feature flags at every scope

Set a feature flag at a scope, with a reason on the flip

Global, plan or tenant scope, most specific wins. Every flip carries a reason and lands in the audit trail — a flag flipped without a why is a change nobody can account for. A tenant-scoped flip is disclosed into that tenant’s chain.

Body

SetFeatureFlagRequest

Live impersonation state for the caller

Every live grant, not one. An operator holding two at once is exactly when a single-grant banner understates how much access is open.

Impersonation grants, filtered

Ask to enter a customer tenant

Creates a pending request. Two distinct approvers are required before it activates, and the customer is notified at request time rather than at activation — a refused request is information they are entitled to as well.

Body

ImpersonationRequest

End a session and disclose it

Returns the summary sent to the customer: scope, approvals, duration, and every resource touched. Sent whether the session read anything or not.

One impersonation grant, including every disclosed read

Approve a break-glass request

The requester cannot approve their own. When the target tenant operates its own substrate, one approval must carry `on_behalf_of_customer`.

Body

ImpersonationApproval

Check and record one read under a grant

Permission and disclosure in a single call. Splitting them would leave a second call somebody can forget, and the read log is what the customer’s end-of-session disclosure is built from.

Body

DisclosedRead

Refuse a break-glass request

Body

ImpersonationRejection

The approval queue, with what each request is still waiting for

Incidents, newest first

Returns

IncidentList

Declare an incident with severity, commander and impact scope

An incident names one accountable commander — not a channel — and its impact by tenant, region and pillar. It opens with a timeline that every subsequent action appends to.

Body

DeclareIncidentRequest

One incident with its full timeline

Set the customer impact scope by tenant, region and pillar

Body

IncidentImpactRequest

File the post-incident review — a required artifact

What happened, why, what was done, and at least one change that will stop it recurring. Filing it is what lets the incident be closed.

Body

PostIncidentReviewRequest

Publish a status-page update from inside the incident

The update is recorded on the incident, so the public page and the incident record cannot tell two different stories — the page is a projection of what the incident said.

Body

PublishStatusRequest

Add a correlated entry to the incident timeline

Body

IncidentTimelineRequest

Move an incident along its lifecycle

declared, mitigated, resolved, closed. An incident cannot be closed until its post-incident review is filed.

Body

IncidentTransitionRequest

The status page: pillar health plus the current word on each open incident

Pillar health comes from the canaries — a red canary declares its pillar degraded in one place — and each open incident shows its latest published update. This is the projection the public status page renders; the operator reads the same assembled view.

Returns

StatusPage

Knowledge base articles

Each carries whether it is overdue for review, computed from the clock rather than stamped by a job, so an article that went stale while nobody was running the reminder reads as stale the moment it is opened.

Write or replace an article

An article is internal unless it says otherwise. A runbook that reads "restart the shard and blame the CDN" is not a document to hand somebody, and the way that gets sent by accident is a knowledge base with no such distinction.

Body

ArticleRequest

Canned responses, with how well each has actually worked

Each carries its send count and how many of those tickets were escalated afterwards. A template sent four hundred times that precedes an escalation three times in four is not a time-saver, it is a way to fail faster, and nobody finds that out from a folder of files.

Write or replace a canned response

The body may use {{tenant}}, {{reference}}, {{subject}} and {{assignee}}. The send and escalation counts survive an edit, so a template cannot escape its own record by having a typo fixed.

Body

CannedResponseRequest

Articles and canned responses that might help

Matched on tag overlap, deliberately. A relevance model that is usually right teaches an engineer to stop reading the suggestions, and the day it is wrong is the day one gets sent to a customer unread.

Licence grants, optionally for one tenant

Grant a module licence to a tenant

A licence names the contract it is sold under and, optionally, a term. Licensing a module is not the same as enabling it — face recognition is licensed here and enabled through the gate.

Body

GrantLicenseRequest

Revoke a tenant’s module licence

Body

RevokeLicenseRequest

Long-running operations across tenants

Cancel a running operation

Cancellation runs the workflow’s compensations. A reason is required because the customer sees this in their own chain.

Body

OperationCancelRequest

One operation, with every step and its retries

Run a customer’s failed operation again from where it stopped

Continues rather than restarts: only the failed and rolled-back steps run again, and the engine decides which idempotency keys carry over. A reason is required because the customer reads this in their own chain, where “a staff member re-ran work on your account” without a why is the sentence that generates the next ticket.

Body

OperationRetryRequest

Send a named signal to a customer’s running operation

Read by steps that look for it, at the next step boundary or by a step that polls. It does not interrupt work already in flight, and a signal nothing picks up stays visible as unread rather than being reported as delivered.

Body

OperationSignalRequest

Pause or resume a customer’s scheduled job

Stops the job firing without editing it, so an operator halting a misbehaving nightly export at 3am does not have to retype its cron expression correctly first. Resuming does not backfill the runs missed while it was off.

Body

ScheduleEnabledRequest

Search tenants, staff, substrates and URNs — metadata only

Never returns payload. A hit carries enough to recognize a thing and navigate to it; the contents are behind the drawer’s payload tabs, which prompt for break-glass. A search box returning the same text without a grant, a reason and an entry in the customer’s chain would be a way around break-glass with autocomplete. Sources that would not answer are named, because “nothing matched” and “nothing matched anywhere we could look” are different answers.

Returns

SearchResults

Which sources this deployment can search

The console shows these in the empty state, so an operator knows what the box covers before they conclude a thing does not exist.

The SLO dashboard with error budgets and burn rate

Every objective, platform-wide and per tenant, with the error budget it implies and how much of it the observed failure has spent. A burn rate above 1 means the budget will be gone before the window closes.

Returns

SloDashboard

Define or update an SLO

The objective is a fraction (0.999 for three nines) over a rolling window; the error budget is one minus the objective. A per-tenant SLO names the tenant.

Body

SetSloRequest

The seven platform SLOs of the system definition with their alert state

Each SLO with its target and its alert rule — burn rate for the availability objectives, a sustained-latency threshold for the p95/p99 and freshness ones. An SLO with no live measurement reports pending rather than a fabricated ok: the real figure needs sustained load in a deployed environment, and claiming health without it is the false green this exists to prevent.

Returns

PlatformSloCatalog

The ProjectX staff directory

Onboard a staff principal

Refused when the requested roles violate separation of duties. The refusal names the control, not just the pair, so the person asking can decide whether to split the work or challenge the rule.

Body

StaffOnboardRequest

Every staff access review campaign

Newest first. A campaign is the certification record of one review round: who held what when it opened, what the reviewer decided, and what closing it revoked.

Open a staff access review campaign

Snapshots every role active staff hold right now. The named reviewer decides each item; anything left undecided at close is revoked, because an access review whose silence keeps access is not a review.

Body

StaffReviewLaunch

One staff access review campaign

Close a campaign and strip every revoked role

The write-back is the point of the exercise: closing removes each revoked role from the directory in the same step, with the campaign URN as the recorded reason. Undecided items close as revocations.

Decide one item of a campaign

Only the named reviewer may decide, and never their own roles. A closed campaign refuses further decisions — the certification is final once issued.

Body

StaffReviewDecision

The certification record an auditor is handed

One flat list: every role held at launch, who decided it, what they decided, and the counts. This is the artifact SOC 2 asks an access review for.

Separation-of-duties violations across the directory

Reports what exists now rather than only refusing what is new, so a conflict pair added to the rules after the fact is still found.

Offboard a staff principal

Keeps the URN resolvable. It is the principal on audit events that outlive the employment, and a log that reads "unknown principal" is not a log.

Body

StaffOffboardRequest

One staff principal

Put a staff member in read-only mode, or take them out of it

New accounts start read-only. Lifting it is a separate decision from granting roles, so an over-generous onboarding form cannot by itself let anybody do anything.

Body

StaffReadOnlyRequest

Replace a staff member’s roles

The whole set at once. Separation of duties is a property of the set, and an incremental add would make the check depend on request ordering.

Body

StaffRolesRequest

Bulk actions requested, approved, executed or rejected

Request a bulk action

Parks for a second approver whenever dual control applies, which is anything destructive and anything at or above the configured tenant threshold. Rate-limited by tenants touched rather than by requests made.

Body

BulkActionRequest

Returns

BulkAction

One bulk action, its plan and its approvals

Approve a bulk action

The requester cannot approve their own, and nobody may approve twice.

Body

BulkActionApproval

Execute an approved bulk action

Recounts first and refuses if the fleet has changed shape since approval — an approval is consent to a described outcome, not to the query that produced it. Reports a per-tenant result; partial failure is reported as failed.

Returns

BulkAction

Reject a pending bulk action

Body

BulkActionRejection

What may be done in bulk

A closed list. Deletion is absent on purpose: it has no undo, it already has a per-tenant path with a census and a certificate, and a bulk form of it would be one request that destroys a business.

What a bulk action would do, without doing any of it

Counts per tenant, names the ones that would change nothing, and reports any tenant that would not answer. An unreadable tenant makes the plan incomplete, and an incomplete plan cannot be requested.

Body

BulkActionPreviewRequest

Returns

BulkActionPlan

Lifecycle, Verify and Workplace operations across customers

Allow-listed counts, states, usage and provider health. Unreadable customers are explicit gaps; no customer content or verification payloads are returned.

Every tenant, with live impersonations and audit volume

Returns

TenantList

Create a tenant

Isolation is required rather than defaulted. Changing it afterwards means moving the tenant’s data, so the choice is only cheap at this moment and should be visibly made.

Body

TenantCreateRequest

Delete a terminating tenant and issue the certificate

Recomputes the blast radius rather than trusting the one the operator saw, refuses while any legal hold stands, and seals a certificate whose digest the customer can recompute.

Body

TenantDeleteRequest

One tenant

What deleting this tenant would destroy

Counts by pillar and kind, legal holds that block the deletion, and the substrates ProjectX does not operate and therefore cannot wipe.

Returns

DeletionBlastRadius

The tenant’s configuration, for support or migration

Suspend, resume or terminate a tenant

The reason is mandatory and lands in the customer’s own audit chain. Suspending an account without saying why is how a support escalation becomes a dispute nobody can reconstruct.

Body

TenantLifecycleRequest

The support queue, ordered by what is closest to breaching

Sorted by time to breach rather than by age, and a ticket whose clock is stopped waiting on the customer sinks below every ticket whose clock is running. Sorting by age puts the tickets we are not currently failing at the top, which is how a desk stays busy and still misses its targets.

Raise a ticket on a customer’s behalf

For the call that came in by phone. The customer is recorded as having raised it, because a ticket attributed to the engineer who typed it is a ticket the customer cannot find.

Body

TicketRequest

One ticket, its whole thread and where it stands against the SLA

Assign a ticket, or hand it back to the queue

An empty assignee unassigns. The staff member is checked, because a ticket assigned to a typo has an owner in the grid and nobody in the world.

Body

TicketAssigneeRequest

What has been happening to this customer, without their data

Their state, what ProjectX staff did to them lately, what the platform refused them, and what is running. Every field is metadata: the support desk is the most plausible route to a customer’s payload, because the person asking has a sympathetic reason and the person deciding is trying to help. What the platform cannot yet see — plan, spend — is named as a gap rather than shown as a zero.

Escalate to another staff member, with a reason

Appended rather than set. "Escalated twice and nobody picked it up" is the sentence a review needs, and a boolean cannot say it. The canned response last sent is charged against its own record at the same time, which is how a template that does not answer the question gets found.

Body

TicketEscalationRequest

Reply, or add an internal note

A reply may name a canned response instead of a body, in which case the template is filled from the ticket and refused rather than sent if a placeholder has nothing behind it. An internal note does not start the response clock, because it is not a response.

Body

TicketMessageRequest

Move a ticket through its states

Entering pending_customer stops the SLA clock and leaving it banks the time waited, so a desk is never measured on how fast its customers reply. Closed is final; resolved is not, because a customer replying to a resolved ticket reopens it.

Body

TicketStateRequest