basis-console v0.1.1

basis-console v0.1.1
Overview

This release introduces Operator Mode and Training Mode, allowing the same console to serve both day-to-day operations and educational or demonstration scenarios without changing application behavior.

The console remains a gateway-first, human-facing interface for the BASIS ecosystem and continues to avoid ownership of authentication, authorization, audit storage, or protocol-specific functionality.

Highlights
Operator Mode
Streamlined operational interface
Focused on day-to-day usage
Reduced explanatory content
Optimized for operators and administrators
Training Mode
Architecture explanations integrated throughout the UI
Educational callouts describing request flow
Additional context around gateway, identity, and authorization concepts
Intended for demonstrations, onboarding, and learning
Architectural Integrity

The addition of multiple presentation modes does not change application behavior.

Both modes:

Submit the same requests
Consume the same gateway APIs
Display the same runtime data
Preserve all existing architectural boundaries

The difference is presentation only.

Quality
Documentation updated
Tests expanded
Ruff checks pass
Formatting checks pass
Mypy passes
Manual operator and training mode verification completed

basis-control v0.1.0

Release Notes — v0.1.0 (Release Candidate)

basis-console v0.1.0 is the first public release candidate of the
human-facing operational interface for the BASIS ecosystem.

Release readiness is not production readiness. A v0.1.0 release means the
console's interaction patterns, architectural boundaries, documentation, and
quality gates are coherent and stable enough for early adopters to evaluate and
build against. It does not mean the console has been audited or hardened for
deployment in live operational technology environments. No production-readiness
claims are made anywhere in this repository.

Purpose

The console makes the BASIS authorization system legible and operable for
humans. It gives operators a single place to:

• see whether the enforcement boundary (basis-gateway) is configured, reachable,
  and ready;
• understand how identity, resources, actions, and decisions fit together;
• construct a well-formed authorization request and — when configured — submit it
  to the gateway and read the decision verbatim;
• inspect decision/audit evidence and the gateway's composition of canonical
  actions and resource identifiers.

It does this gateway-first: the console reaches the BASIS system only through
basis-gateway, never through basis-core.

Included Capabilities

Area	Route	Data
Home / status	GET /	Live gateway connection state
Operator Workspace / Overview	GET /workspace	Live gateway snapshot + orientation
Policy viewer	GET /policies	Sample
Decision Simulator	GET/POST /simulate, GET /simulate/examples	Preview (always) + live evaluation (when configured)
Audit Explorer	GET /audit	Sample + link to live evaluation evidence
Identity & Access Explorer	GET /identity	Sample
Resource Explorer	GET /resources	Sample
Gateway Diagnostics	GET /gateway	Live gateway health/readiness
Liveness / readiness	GET /health, GET /ready	Live

The README includes screenshots of the v0.1.0 release-candidate interface
(Home, Operator Workspace, Gateway Diagnostics, Decision Simulator, Audit
Explorer, Identity & Access Explorer, Resource Explorer, and Policy Viewer),
captured in sample-only mode.

Run modes:

• Sample-only mode — no gateway configured. Every page loads; data-bearing
  pages are clearly labelled as sample/explanatory. Gateway status is
  not_configured.
• Gateway mode — GATEWAY_BASE_URL set. Gateway Diagnostics, the home page,
  and the workspace reflect live gateway health/readiness.
• Live evaluation mode — GATEWAY_BASE_URL and GATEWAY_BEARER_TOKEN set.
  The simulator can additionally submit to POST /v1/evaluate and display the
  gateway's decision.

Non-Goals

The console deliberately does not, in this release or by design:

• evaluate authorization decisions or run any policy/role/condition logic;
• call or import basis-core;
• authenticate users, manage sessions, verify tokens, or implement any identity
  protocol (OIDC/OAuth/SAML/SCIM) — it is not an identity provider;
• parse or emit field protocols (BACnet, Modbus, MQTT, OPC UA, …);
• produce, store, or reinterpret canonical audit records, or define an audit
  schema;
• own a resource inventory or perform device discovery;
• bypass the gateway to reach the kernel directly.

Known Limitations

• Sample-backed views. Policy, Audit, Identity, and Resource pages render
  clearly-labelled sample data. basis-gateway does not yet expose console-facing
  policy, audit-history, identity-diagnostic, or resource-catalog endpoints, so
  the console invents none. Live decision + composition evidence is reachable today
  only via the Decision Simulator.
• Provisional vocabulary bridge. basis_console.vocabulary is a console-local
  mirror of the action verbs / resource types, not the authority for them. It is
  expected to be replaced by a future basis-schemas package.
• No bundled token issuance. basis-gateway verifies tokens against a real
  OIDC issuer; there is no built-in dev token. A GATEWAY_BEARER_TOKEN must be
  obtained out-of-band for live evaluation.
• No packaging/deployment tooling. No Docker, systemd, or Kubernetes artifacts
  ship in this release; the console is structured to make that straightforward
  later.
• No console authentication. The console authenticates no one; deployments
  beyond a trusted operator must be fronted by appropriate access controls (see
  SECURITY.md).

Gateway Integration Expectations

• Set GATEWAY_BASE_URL to a reachable basis-gateway instance to enable live
  health/readiness across the home page, workspace, and Gateway Diagnostics.
• The console probes only the gateway's real operational endpoints (GET /health,
  GET /ready) for connectivity, and POST /v1/evaluate for live evaluation. It
  invents no endpoints.
• Live evaluation requires GATEWAY_BEARER_TOKEN in addition to
  GATEWAY_BASE_URL, because the gateway requires a verified Authorization: Bearer token on /v1/evaluate and derives the subject identity from it. When
  the token is absent, the simulator stays preview-only and says so.
• When the gateway is unreachable, the console reports the outage and surfaces no
  live state — it never falls back to local authorization logic or cached
  decisions.
• Gateway Diagnostics surfaces per-probe response latency, the last successful
  check, a connection-state glossary, and a concrete next step. The connection
  state (not_configured / unreachable / error / reachable / ready) is
  labelled consistently across the home page, the Operator Workspace, and Gateway
  Diagnostics, and timeouts are distinguished from other unreachable causes. The
  Decision Simulator explains each evaluation outcome category (allow, deny/not
  applicable, unauthorized, validation error, unavailable/timeout, gateway error)
  and states plainly when the gateway returns no correlation ID or policy version.

Sample-Data Disclaimer

Pages marked sample/explanatory render local, illustrative data — including
obviously-sample identifiers and correlation IDs — purely to demonstrate the
interaction model and the shape of data live integrations will eventually
provide. Sample data is never presented as authoritative system state, and the
console never produces an allow/deny decision of its own.

Future Phases

Beyond v0.1.0, expected directions (each owned at the appropriate boundary,
not invented by the console):

• live gateway-backed policy, audit-history, and resource-catalog views once the
  gateway exposes console-facing endpoints;
• a future basis-schemas package owning the action vocabulary and
  request/response/audit contracts, replacing basis_console.vocabulary;
• a future basis-identity service for OIDC/JWKS/JWT/SAML/SCIM inspection, which
  the console will display, never implement;
• deployment packaging (container, systemd, Kubernetes) without altering any
  authorization behavior.

See docs/architecture.md for the full boundary set and
phase-by-phase notes.