Managed service mode

A provider organization can run factories for customer organizations. The relationship is a grant the customer gives and either side can revoke, and it is an authorization fact CodeBook keeps next to the SSO identifiers it names. SSO has no concept of one organization acting for another, so CodeBook stores no people, memberships or roles for this: the provider's people are whoever SSO lists in the provider organization at the moment of each request.

Open Organization → Managed service for four tabs: Access, Audit log, SLA and Branding. A provider also gets the console.

Grants

A customer owner or administrator grants access by naming the provider organization by its SSO ID or public ID, with a scope of read or operate and a note. Only one grant can be active per provider and customer, and a scope change is checked against the grant's revision. The customer's owner or administrator can revoke at any time; so can the provider's, so a provider can walk away. Both sides list the grant.

The grant is read fresh on every request, so a revocation applies to the very next one. It is consulted only by routes that ask for managed access. No other route in the product does: a provider can never open a customer's card, workspace or factory page through the ordinary permission check, and a test asserts this.

On the provider side, the provider organization's owners, administrators and members are operators and get the scope the customer granted; its viewers are observers and can only read.

Audit

Every provider act is recorded as done or failed, and a refusal caused by scope is recorded as refused by the guard itself. Every change to a grant is recorded. Opening the console is recorded once an hour per person and customer. The customer sees all of it; the provider sees its own acts.

The provider console

The console shows every factory the person's grants cover, paginated over customer and factory pairs with a filter by customer: running, queued, waiting and blocked work, holds, runs waiting for approval, open escalations, failures in the last 24 hours, SLA alerts, and tokens today against the budget. Each factory is checked against the grant again before it is read.

With operate scope, and checked again on the server: pause and resume a factory, approve or reject a run held for approval, and answer an escalation. Approval follows the operations center's own rules, so a station staffed by a person is never decided by someone else. Answering an escalation claims the decision and posts the answer on the card. The console opens each customer's SLA report and branding in a dialog.

SLA targets and reports

Four kinds of target, each measured from the table that already records it: station stay from station visits, workflow cycle from card outcomes, time until a person answers an escalation from supervisor decisions, and completion rate (done ÷ ended) from card outcomes.

Periods are calendar weeks starting Monday and calendar months, in UTC. An item still open counts as a breach in the period in which it crossed its target; exactly at the target is met, and anything over is a breach. A period with nothing measured reports no data, which is neither a pass nor a breach. The report lists breaches and exports as CSV. Both sides can read it; a customer administrator or a provider with operate scope can edit targets.

White-label branding

Branding sets a product display name, a primary colour, a support email and link, and a logo. The colour must be six-digit hex; the support link https only with no credentials; the email a single address; the name up to 40 printable characters with no angle brackets; the logo PNG, JPEG or WebP up to 256 KB, checked by its magic bytes against the declared type. SVG is refused. The logo is stored at SSO and served back with the type checked at upload and no-sniff headers.

A customer administrator sets branding; a provider with operate scope can manage it for that customer, audited. With no branding row or an unset field, everything stays exactly as before.

Branding appears in the app shell (name, logo, primary colour with a readable foreground, and a Get support menu item), in the station notification email's subject, body and support footer, and as variables sent with the card-assigned and workspace-added emails.

What needs an SSO change

• Bell notifications are not branded. CodeBook sends notifications to SSO's shared inbox with only a recipient, type, title, body and link; SSO names the app itself.
• SSO email templates receive product_name, support_email, support_url and brand_color, but a template at SSO must reference them before they show up. The station notification email renders its own text, so it is fully branded today.
• Billing emails stay unbranded on purpose: they come from the platform about its own plan.
• Deployment packaging and provider/customer billing are out of scope. Operational model spending can still be estimated from recorded usage and SSO model prices.