Operational

RELEASE NOTES · CONTROL PLANE

Material changes, documented by release.

The changelog records changes to authentication, APIs, data handling, operating workflows, security controls, public documentation, and recovery behavior. It does not include routine content corrections that do not change meaning.

Current release
1.2.0
Release channel
Production
Published
05 Aug 2026
Compatibility
Backward compatible

1.2.0 · Documentation and control transparency

Published 05 Aug 2026

Documentation

  • Replaced short Help, Privacy, and Security pages with full operator, privacy, and security documents.
  • Added document owners, versions, effective dates, review cycles, table of contents, evidence boundaries, and related-document navigation.
  • Expanded System Architecture with request flow, persistence, deployment topology, dependency registry, failure isolation, capacity signals, and architecture decisions.
  • Expanded the Trust Center with service commitments, control IDs, evidence classes, shared responsibility, continuity, and explicit assurance limitations.
  • Published consolidated Acceptable Use, Access Control, Data Handling, Retention, Change Management, Incident Reporting, and Integration Governance standards.
  • Expanded System Status with component scope, machine-readable endpoints, status definitions, maintenance policy, and public incident-history rules.

Accuracy and assurance

  • Clarified that connector registrations and provider documentation links do not imply affiliation, sponsorship, certification, or independent audit.
  • Separated service objectives from historical measurements and limited current status statements to the published control-plane scope.
  • Aligned privacy and retention descriptions with the implemented database schema, session behavior, recovery workflow, and audit fields.

Compatibility

No authenticated API route or existing console workflow was removed. Static documentation paths remain stable. The Control API version was advanced to 1.2.0 to match the published document set.

1.1.0 · Complete interactive workflows

Published 05 Aug 2026

  • Completed account recovery with tracked, non-enumerating case references.
  • Added persistent server-side requests for data spaces, pipelines, transfers, and access reviews.
  • Added schema validation, conservative resource naming, resource identifiers, and lifecycle states.
  • Enabled working alert filters, alert acknowledgement, incident timelines, settings persistence, CSV exports, and integration configuration views.
  • Connected authentication footer links to public documentation, privacy, security, and status pages.
  • Added official provider documentation links without exposing connector credentials or private tenant data.
  • Added backend integration tests for recovery, resource persistence, and settings persistence.

The release preserved the existing network gateway services, public transport ownership, private NBS listeners, interfaces, and canonical firewall and NAT rules.

1.0.0 · Initial production release

Published 05 Aug 2026

  • Introduced the global operations console and regional health views.
  • Added server-side password verification, privileged MFA challenges, role enforcement, and authentication rate limits.
  • Added opaque server-side sessions with Secure, HttpOnly, SameSite=Strict cookies and session-bound CSRF validation.
  • Published structured API errors, request identifiers, health, readiness, status, audit, and OpenAPI endpoints.
  • Introduced Security Center, Trust Center, architecture, privacy, policy, status, changelog, robots, sitemap, web manifest, and RFC 9116 security.txt surfaces.
  • Enabled persistent authenticated action auditing with one-way source-address digests.
  • Published the application behind the existing HTTPS gateway without adding a public application port.

Versioning and compatibility policy

NBS uses a three-part release number:

Major
Breaking API, authentication, resource, or operating-model change requiring coordinated adoption.
Minor
Backward-compatible capability, control, workflow, or material documentation expansion.
Patch
Backward-compatible defect correction, hardening change, or non-material content correction.

Deprecations are documented before removal when security or integrity does not require immediate action. Emergency security changes may shorten ordinary notice where maintaining the previous behavior creates unacceptable risk.

Release process

  1. Build the complete static and API release.
  2. Run frontend packaging and backend integration tests.
  3. Create a consistent SQLite database backup and archive the prior application and origin configuration.
  4. Install the application and verify local API health before reloading the HTTPS origin.
  5. Verify public pages, structured API responses, authentication, and representative console workflows.
  6. Confirm existing gateway service state, port ownership, interfaces, unit hashes, and canonical firewall rules.
  7. Tag the exact validated source and publish the corresponding release notes.