Evaluation rooms, one gated view of an evaluated system

Implements: PRD 0001

Problem

PRD 0001 (InOrbit Atlas) ends every evaluation in one place: "a private site for the customer: the map, the documents, the risks found, what InOrbit's agents would do first and how, and the exact steps to install and run them." Nothing on the platform does that today.

• The RFCs product shows one space at a time to the people who can read it. A space has no front page, no order for a reader who has never seen it, and nothing that is not a document: no map, no install steps.
• Sharing a space means giving someone a level in it. In a customer's account the platform's roles open nothing (RFC 0065), so a customer cannot show an evaluation to an InOrbit partner, or our staff to a prospect, without making them a member.
• Staff and partners preparing a room for a prospect (PRD 0001, phase 3) would build it by hand on the site, outside every gate we have: the redaction check, the NDA (RFC 0056), the partner role (RFC 0057) and the audit trail.

The owner decided where the room lives (PRD 0001, open question 5): a gated area on the console, reusing existing access; a custom host per customer later, on Enterprise.

Proposal

What a room is

A room is a named, read-only view over one evaluated system's space. One space per evaluated system is RFC 0081's model (Atlas A1); a room points at that space and adds nothing a document should hold. It shows five sections, in this order:

A document's lines carry their evidence state (inferred, confirmed, measured) when the document has one. The room shows the state as the document holds it and never adds one. A section with nothing in it says so plainly; a room never fills a gap with an example.

A diagram is drawn here in the RFCs product; this page does not show diagrams yet.

The room record

Who gets in, and how much they see

The edge requires a signed-in person on every room route. Behind it the labs service decides, per reader, with one function:

1. The account's own people (members, owners, admins) read the room as they read the space: their clearance from RFC 0065, unchanged.

2. Anyone else needs a grant that matches them. A grant names an audience and a level:

   Audience	Matches	Highest level it may give
   public	Anyone	public
   signed_in	Any signed-in person	public
   role:<name>	A person holding that platform role (preview, partner, admin, sales, investor)	team
   member	The account's members (the default every room starts with)	their own clearance
   person:<subject>	One named person	team

   Their room clearance is the highest level among the grants that match them. internal is never granted: it stays with the account's managers.

3. In our own accounts a grant only admits: the reader's level is still the one their platform role gives them (RFC 0065), so a partner admitted to our room reads at partner, never higher, whatever the grant says. In a customer's account the grant is the customer's decision about their own documents, up to team.

4. No matching grant, an expired room, or a room that does not exist answer the same NOT_FOUND. A matching grant without the NDA a room asks for answers FAILED_PRECONDITION with nda_required, so the console can send the reader to sign.

Everything the room shows goes through RFC 0065's read rules at the room clearance:

• a document whose level is above it is not listed and cannot be opened;
• a document's text leaves through text_for, so a classified span above the clearance is a bar with its reason, exactly as in the RFCs product;
• the room's own section text follows the same grammar and the same cut, so a risk can carry a classified span too.

Narrowing per section and per document

Each section and each document may carry a visibility, using the same audiences as the grants. An empty visibility means everyone admitted to the room. A reader sees a section or a document only when they are admitted to the room and match its visibility. The account's own managers see everything, with each item's visibility shown.

A visibility narrows; it never widens. A public section in a room granted only to partners is seen by partners. Moving anything to the public audience, as a grant or a visibility, is a deliberate act: the call must say confirm_public, the section texts and documents that would become readable to anyone pass the redaction and strict checks first (any finding refuses the change by rule and line), and the change is logged with both values.

Plans

Rooms follow the plan table in PRD 0001: private to the owner on Free and Personal, shared by role on Team, shared by role with a custom host on Enterprise. The labs service asks the accounts service's HasFeature (RFC 0061) and owns no plan logic:

Without rooms.share, a room keeps its member grant and nothing else, and adding any other grant answers FAILED_PRECONDITION naming the feature. Our own accounts have every feature (RFC 0061). If the accounts service cannot be reached, sharing fails closed; rooms already shared keep working. The final numbers and plan names belong to the pricing work (Atlas A7); this RFC depends only on the two feature names.

The console

• Rooms (/rooms/): the rooms the reader manages and the rooms shared with them, each with its system, audience summary, expiry and when it was last opened.
• A room (/rooms/<slug>): a header with the title, the system and who can see it; the five sections in order; a document opens in the room's reading view at the room's cut. Sections the reader may not see are left out, not greyed.
• Sharing (a dialog on the room, for its managers): the grants as rows (audience, level), the NDA switch, the expiry, and each section's and document's visibility. A change to public shows what becomes readable to anyone before it is saved.
• English and Croatian, light and dark, a phone layout. Visible in the console to the admin and partners only until the owner opens it, like every new product; the service serves every role from the first day.

The API

A second service in the RFCs product's package, iohr.rfcs.v1.RoomsService, served by the labs service beside RfcsService, so rooms read spaces and documents through the same store and the same read function. REST under /v1/rfcs/rooms:

{room} is the slug. The data lives in the labs schema: rooms, room_grants, room_sections and room_documents, removed with their space and with their account's erasure. Limits: 50 rooms per account, 50 grants per room, 64 KiB per section text, 2,000 chosen documents.

Rooms are not MCP tools and no API key scope opens them in this RFC: a room is a place a person reads. A scope comes with its own change when an integration needs one.

Custom hosts, later

On Enterprise a room can be served at a customer's own host. The room and its rules stay the same; the host maps to a slug at the edge, sign-in stays the platform's (or the customer's own, RFC 0083), and the host is verified as the account's domain first. Built when the first Enterprise customer asks, with its own RFC part.

Out of scope

• Building the map, the documents or the risks. Rooms show what Atlas A1, A4 and A6 produce; until then they show empty states.
• Reading a room without signing in. The public audience is stored and honoured by the service, and the edge keeps the routes behind sign-in until an open read path is decided, as RFC 0065 did for documents.
• Comments, reviews and approvals inside a room: those stay in the RFCs product, where the people who decide work.
• Any change to the customer's systems. A room only shows.

Controls

• Access control. The edge requires sign-in on every route; the labs service decides per reader with one function, default deny, NOT_FOUND for anything unreadable. A room never shows more than the reader's level, and in our own accounts never more than the platform role gives.
• Classified text. Every text a room returns, documents and its own sections, leaves through RFC 0065's cut.
• Public is deliberate. confirm_public, the redaction and strict checks, and an audit line with both values.
• Audit. One line per open: who, the room, the outcome. One line per change: who, the room, what changed by name (grant audiences and levels, section names), never text.
• Data. Room texts are customer data: never in a log, a span, a metric label, an event or an error. Erased with the account; exported with the person who wrote them.
• Availability. Bounded sizes and pages; the room page reads at most the first 200 documents.

The compliance registry gains the rooms as a sharing path under access control.

Alternatives considered

• A host per room from the start. Closest to "a private site", but every room would need a certificate, a DNS record and its own sign-in path, and the owner chose the console. The custom host stays as the Enterprise option.
• Reuse document levels only, no grants. Simple, and RFC 0065 already has the ladder. But a customer's documents are never read through a platform role, so a customer could not show a room to an InOrbit partner without making them a member. Grants give exactly that, per room, and nothing else.
• A separate rooms service. Clean ownership, but it would need its own copy of the space, document and level rules, or a call per document to the labs service. Rooms read through the same function as everything else in the RFCs product, so they live there.
• Put the rooms RPCs into RfcsService. One fewer service name, but RfcsService is still an alias of the deprecated LabsService for one release, and every new method would need an old twin.

Decision

Open. The owner decided the place (PRD 0001, question 5): a gated area on the console, reusing existing access, a custom host per customer later.

Publication

The RFCs reference gains RoomsService. The console gains Rooms. The PRD's evaluation room line links here.

Status log

• 2026-10-07: opened for Atlas A8. Delivery: the RFC; the store, service and API with an access-matrix test; the edge route; the console pages; the phase 0 room over our own Platform space once RFC 0081's one space per system is in place.