Every route, named in the code.

What it is for

The NovusLens screens call two sets of HTTP interfaces. The reasoning service answers questions about the twinTwinNovusLens’s model of one organisation, built from records about its teams, services and how they rely on one another. It is only as current as those records.. It handles operations that propose and commit organisation structure, plus the audit, evidence, federationFederationSharing selected signed facts and summaries between separate regional twins, while their detailed records stay in their own regions. and remitRemitA written list of an agent’s allowed actions, resources and destinations for information. The list states whether it is complete. routes. The UI is a Next.jsNext.jsThe web framework used to build and run the NovusLens interface. It provides pages, server code and request handlers. application. Its /api route handlers sit in front of the service. They work out who is signed in and pass that identity on, so the service never trusts a name typed by the browser. This page lists every route the code declares, and the rule that applies to each.

How access works

The rules below apply across the tables. Each row says which of them applies to that route.

• Service tokenService tokenA secret value sent with requests between NovusLens services. The receiving service refuses requests with a missing or wrong value.. In the customer profileDeployment profileA setting that selects customer or development behaviour. Customer mode refuses development credentials and uses the signed-in session as the identity. (CONWAY_PROFILE=customer), every request to the reasoning service must carry the header X-Conway-Service-Token, set to the value of CONWAY_SERVICE_TOKEN. The only exceptions are /health and /ready. A missing or wrong token returns 401. The token comparison takes the same time whether or not the values match. The dev profile does not check the token.
• Viewer. Most routes name the caller as a viewer, in the body or the query. The service looks that handle up in the account table (guards.resolve_viewer). An unknown viewer returns 403. Through the UI, the viewer is never taken from the request. The UI replaces it with the signed-in session.
• Org binding. guards.require_org lets an actor act only inside their own organisation. The operator can work across organisations.
• Writer. guards.require_writer refuses the board role on routes that require a writer. The board can read the organisation’s picture and save a copy of an assessment through /car/archive.
• Named roles. Some routes name a role in their row: operator (the role that works across organisations), cxo (the Executive role for the organisation), board, or the owner of a cellCellA box on the map that stands for a team, service, supplier or AI agent. It is a unit you can inspect, not necessarily a department or a person..
• Body size. The service refuses a request whose declared body is larger than 4 MiBKiB and MiBBinary size units: one KiB is 1,024 bytes; one MiB is 1,048,576 bytes. Evidence limits use these units., with 413.
• Listening address. The service defaults to 127.0.0.1; --host selects another address. Compose sets 0.0.0.0 inside Docker and keeps the reasoning port private.

Reasoning service routes

The paths below are paths on the service. A browser does not call them directly. It calls the UI proxyProxyA service that receives a request and forwards it to another service. The NovusLens web proxy adds the signed-in identity and service token. at /api/reasoning/ followed by the same path (see the UI routes). The proxy forwards any path, so the service’s own route table decides what exists.

Questions and tools

Health and discovery

Composition

Operations

Capture

Capture sessions are live conversations with a contributor. The service holds each session in memory until it is committed or discarded.

Meaning and stewardship

Notifications and assurance

Federation and groups

Component assessments (Complexity, Agility and Recoverability)

C/A/RC/A/RThree separate scores for a team or service: Complexity, Agility and Recoverability. Each uses current evidence and the customer’s stated scoring rules. is the Complexity, Agility and RecoverabilityRecoverabilityThe R in C/A/R: how well a team or service restores acceptable service after a failure. Recovery times and tested alternatives can supply evidence. assessment of current structure. These routes read and publish it. The viewer and organisation are checked in the module each route calls. The role rule for each route lives in that module.

When the storage behind these routes is unavailable, they return 503 and say that no new assessment is available.

Remits and catalogues

A remit is a declared scope of what a subject may do. A catalogue is a reviewed list. Both are authored by people and approved by people. Every route below takes viewer and org, and the viewer is checked in remit_authoring or catalogue.

Agent evidence and findings

Agent evidence is the signed record of what customer agents did, as their systems report it. The routes below store it, read it and report on it. They do not decide what those agents may do.

UI routes

The UI’s /api routes are Next.js route handlers. The directory path gives the URL. Each one works out the signed-in viewer before it does anything else.

Profile rules

These rules come from the code. They describe what the customer profile does, and nothing more.

• The customer profile is selected by CONWAY_PROFILE=customer.
• The reasoning service refuses to start without CONWAY_SERVICE_TOKEN and MYCELIUM_GATEWAY_TOKEN set to values that are not the development values.
• The UI refuses to sign sessions when CONWAY_SESSION_SECRET is unset, is the public development value, or is shorter than 24 characters.
• In the customer profile the viewer query parameter is ignored. The session is the only identity.
• Without a session, the UI refuses: the reasoning proxy, the record check and the Guide all return 401.
• Every reasoning request except /health and /ready needs the service token.