One-Way Doors

In the Company OS architecture, four foundational decisions are designated as “one-way doors”: once made, they are not easily reversible without significant cost or migration effort. These decisions establish core invariants that must be upheld from the first line of code and are enforced through technical mechanisms. Acceptance by the product owner (Robbie) transitions each from pending-owner-acceptance to Accepted.

1. Tenant Isolation (THE-6)

Enforcement: Row-Level Security (RLS) in Postgres combined with a mandatory tenant_id column in every table of the os schema and in any application schema containing tenant data. A TenantContext Effect-service scopes every database connection via SET LOCAL app.tenant_id. Queries lacking a TenantContext fail to compile.

Why it’s a one-way door: Merely adding a tenant_id column without RLS would leave the system vulnerable to data leaks from application bugs. Schema-per-tenant or database-per-tenant alternatives were not selected, but migration paths must be documented for customers requiring stronger isolation.

Acceptance test: A principal from tenant A attempts to read a row belonging to tenant B via a deliberately incorrect application query; RLS must reject the access.

Evidence: The proposal is detailed in ADR-0001 §3.1, referencing THE-6 [[repo://docs/adr/ADR-0001-company-os-multi-tenant-metered.md#L87-L94]].

2. Principal Identity Over Channels (THE-7)

Enforcement: From day one, the OS stores:

principal (id, tenant_id, class: user|agent|factory, responsible_principal_id)
principal_identity (principal_id, provider, external_id)
agent_credential (principal_id, …)

A WhatsApp number, Teams user, or Better Auth session must resolve to an existing principal; the OS never creates a principal implicitly. Only a tenant-admin may link identities.

Why it’s a one-way door: Without this binding, the same human or agent could appear as multiple principals across channels, breaking auditability and policy enforcement. Retroactively merging split identities after launch would be complex and error-prone.

Acceptance test: Not explicitly defined in the ADR, but the mechanism ensures that any channel-specific identifier maps to exactly one principal, and unknown channel identities are rejected.

Evidence: The proposal is detailed in ADR-0001 §3.2, referencing THE-7 [[repo://docs/adr/ADR-0001-company-os-multi-tenant-metered.md#L95-L98]].

3. Metering Per Action (THE-8)

Enforcement: The capability-invoke is the billable line item. Each invoke generates a Receipt with:

tenant_id, principal_id, correlation_id, parent_receipt_id
capability, side_effect_class, target
cost_model_cents, cost_infra_cents, tokens_in, tokens_out, langfuse_trace_id
outcome (pending | success | failed | denied | uncertain)
created_at, settled_at

Tool-calls and model costs appear as child receipts (parent_receipt_id) under the invoke; a task is an aggregation over correlation-ID, not a storage unit.

Why it’s a one-way door: Metering must be a primitive, not a retrospective report. Billing per tool-call is too noisy for customers; per-task aggregation hides failed attempts. The invoke aligns with the existing capability registry.

Acceptance test: Every invoke must produce exactly one Receipt with the above fields; tests must detect duplicate or missing Receipts under parallel invocation.

Evidence: The proposal is detailed in ADR-0001 §3.3, referencing THE-8 [[repo://docs/adr/ADR-0001-company-os-multi-tenant-metered.md#L100-L115]].

4. Factory Principal Restrictions (THE-9)

Enforcement: Principals of class factory are granted only capabilities with target: dev-tooling (e.g., Linear, GitHub, CI, deploy). The registry permission check rejects any attempt by a factory principal to invoke a capability with target: tenant-app; this rejection occurs in the registry, not via prompt engineering.

Why it’s a one-way door: Factory agents must operate strictly within developer tooling boundaries and never access tenant data or tenant-facing capabilities. Allowing such access would violate the inner/outer agent separation and require a fundamental redesign.

Acceptance test: A factory principal invoking search_aanvragen (a tenant-app capability) must receive a denied outcome accompanied by a Receipt.

Evidence: The proposal is detailed in ADR-0001 §3.4, referencing THE-9 [[repo://docs/adr/ADR-0001-company-os-multi-tenant-metered.md#L116-L119]].