OPERATOR HANDBOOK · CONTROL PLANE
Operate regional data infrastructure with explicit controls.
This handbook explains the service model, authenticated workflows, operational resources, reliability practices, governance controls, and API behavior available through NBS. It is intended for platform operations, reliability, security assurance, and read-only review roles.
1. Service overview
NBS is the management surface for a distributed data plane. The control plane coordinates regional capacity, logical data spaces, continuous pipelines, asynchronous transfers, reliability response, access reviews, and recorded operational changes. Bulk object payloads do not pass through the interactive browser session or the control API.
The service separates observation from mutation. Operational dashboards and audit records are available to assigned read-only roles, while actions that change state require an authorized role, a valid server-side session, and request verification. This separation allows reviewers to inspect production posture without receiving change authority.
Observe the data plane
Review regional health, storage utilization, pipeline lag, transfer progress, capacity forecasts, and service objectives.
Coordinate response
Acknowledge signals, inspect incident timelines, and review scheduled changes against active operating conditions.
Enforce accountability
Resolve role assignments, start access reviews, inspect immutable audit events, and export evidence for review.
Register dependencies
Expose connector aliases and operating metadata without revealing tenant identifiers, credentials, or secret material in the browser.
The console represents requested and observed state. Regional workers execute approved data movement independently, using service identities and private transport paths.
2. Accessing the control plane
Assigned credentials
Authentication begins with an assigned username and password. Privileged roles receive a second verification challenge before a session is created. The service does not accept public registration, social identity providers, or unconfigured security-key options on the sign-in surface.
- Open the NBS sign-in page over HTTPS.
- Enter the assigned username and password.
- Complete the six-digit verification challenge when required.
- Confirm the resolved identity and role in the profile menu before performing an operation.
Session behavior
Sessions use opaque cookies marked Secure, HttpOnly, and SameSite=Strict. The browser cannot read the session token. Standard sessions expire after twelve hours; an explicitly remembered session may remain valid for up to thirty days. Server-side revocation or expiration immediately invalidates the cookie.
Account recovery
The recovery workflow records a case reference and returns the same response whether or not a supplied username exists. This prevents the recovery surface from being used to enumerate identities. Recovery requests must be continued through the registered support channel associated with the account.
Do not include passwords, verification codes, session cookies, connector secrets, or private tenant identifiers in incident notes, screenshots, exports, or support requests.
3. Resource model
Resource identifiers are generated by the control API. Names use lowercase letters, numbers, and hyphens and are validated before persistence. The displayed lifecycle state describes control-plane processing and does not imply that downstream data movement has completed.
4. Operational workflows
Create a data space
Specify a unique name, owning group, storage class, and retention policy. An accepted request is persisted with a provisioning state and recorded in the audit log. Capacity allocation, policy validation, and regional placement occur outside the browser request.
Create a pipeline
Define the owning group and source and target regions. Source and target must differ. The control plane stores the definition as a draft; it does not automatically begin high-volume movement. Validation, approval, and scheduling remain separate lifecycle events.
Start a transfer
Select a data space, distinct source and target regions, and a transfer limit. The request enters a queued state. Transfer progress represents acknowledged worker state and may pause when anomaly protection, maintenance controls, or an active incident requires intervention.
Pause or resume execution
Pipeline state changes are authenticated mutations. The requested action is submitted with the resource identifier, CSRF token, actor identity, and a unique request identifier. The interface changes state only after the server accepts the operation.
| Workflow | Initial state | Primary control | Audit action |
|---|---|---|---|
| Data space request | Provisioning | Ownership and retention validation | data_space.create |
| Pipeline definition | Draft | Route and policy validation | pipeline.create |
| Regional transfer | Queued | Distinct regions and transfer limit | transfer.create |
| Access certification | Open | Scope and due date | access_review.create |
5. Reliability operations
The Overview page combines current request rate, ingress, logical data, global availability objective, regional health, and control API objectives. These views support triage; they do not replace regional telemetry or an incident command record.
Alerts
The Open filter shows actionable signals. The All filter also includes acknowledged and resolved records. Acknowledgement records actor intent and removes the alert from the Open view; it does not resolve the underlying condition.
Incidents
Incident pages identify severity, commander, affected services, lifecycle state, and a structured event timeline. Timeline entries distinguish detection, diagnosis, mitigation, decisions, monitoring, and resolution. Material decisions should reference the corresponding change or control request.
Changes
Scheduled operational work includes risk, requester, execution window, and approval state. High-risk work may be blocked by the maintenance guard or require two-person approval. Approval authorizes the defined change window; it is not permission to expand scope.
When escalating an error, record the visible request ID, resource ID, UTC timestamp, operation, and observed outcome. These fields allow the API response, audit event, and service logs to be correlated without sharing credentials.
6. Governance and audit
Roles are resolved on the server. A read-only identity can inspect operating views and export permitted evidence but cannot create resources, acknowledge alerts, decide changes, or modify safeguards. Disabling a browser control is a usability measure; the API independently enforces the role.
| Role | Typical scope | Mutation authority |
|---|---|---|
| Platform Administrator | Platform controls, approvals, and identity governance | Broad, subject to safeguards |
| Platform SRE | Reliability response, pipelines, transfers, and regional operations | Operational |
| Data Operations | Data spaces, pipelines, transfer execution | Resource-scoped |
| Security Auditor | Access posture, audit evidence, review workflows | Governance-scoped |
| Read Only | Observation and approved evidence export | None |
Audit events record time, actor, action, resource, outcome, request ID, and a keyed one-way digest of the source address. The digest supports abuse correlation without storing the clear source address in the audit table. Exported CSV files should inherit the handling requirements of the underlying operational record.
7. API conventions
The Control API uses JSON responses and same-origin authenticated sessions. Every API response carries an X-Request-ID. Errors use a stable object containing code, message, and request_id. Authenticated mutations require a session-bound X-CSRF-Token.
{
"error": {
"code": "read_only_role",
"message": "This role cannot change operational state.",
"request_id": "req_7d2a08b2c68d4f0f9d1e"
}
}| Status | Meaning | Operator action |
|---|---|---|
| 200 | Request completed | Use returned state |
| 201 / 202 | Resource created or operation accepted | Track returned ID and lifecycle state |
| 400 | Request failed validation | Correct the submitted fields |
| 401 | Session absent or expired | Authenticate again |
| 403 | Role, origin, or CSRF check failed | Verify identity and assigned authority |
| 404 | Route or resource not found | Confirm version and identifier |
| 409 | Requested state conflicts with policy or current state | Review the conflict and retry only after correction |
| 429 | Bounded attempt window exceeded | Wait before retrying |
The machine-readable API description is available at /api/openapi.json. Health and operating status are published at /api/v1/health and /api/v1/status.
8. Support and escalation
Use the registered support channel associated with the assigned account. Include only the minimum information required to investigate the request:
- request ID and resource ID;
- UTC timestamp and operation name;
- expected behavior and observed outcome;
- affected region or service component;
- whether the condition is ongoing, intermittent, or resolved.
Security vulnerabilities should follow the process in the Security Center and security.txt. Active service impact should be correlated with the public status page before a duplicate escalation is opened.