Status. Proposed design only. Nothing in this vault is DG client approval. No application, service or test has been executed; every scenario is Not executed. Fees and dates are open.
Company isolation
Purpose
The most important rule of the product, stated once for engineers.
Source notes
Permissions-and-Confidentiality, Step-03-Policy-Pipeline-and-Isolation-Harness, Acceptance-Gates-A01-A11 (A03, A06, A09).
Rule
Access is scoped by company and by participant pair. In an engagement between A and B, and another between A and C: B cannot reach A-C, C cannot reach A-B. Company A’s admins can read A’s own records, and A discloses that to participants. DG administrators see scoped metadata only.
Enforcement (Proposed)
- Primary control: the policy pipeline in Request-Pipeline, applied to every read, mutation, search, count, export and job.
- Audience and status filters run before search, ranking, snippets, counts and pagination (T06).
- Defence in depth: PostgreSQL row-level policies keyed on company and participant (ADR-0003-RLS-Defence-in-Depth).
- Notification recipients are re-resolved at delivery (Outbox-and-Worker).
Test harness (Step 03)
A three-company fixture with a canary string in each private engagement, a race-injection harness for approval, accept and revocation races, and a route inventory so that every enabled route is covered. Scenarios: Company-Isolation-Scenarios.
Open decisions
Blocked by Q07 (revocation boundary), Q08 (denial shape, metadata), Q09 (session policy).
Known limitations
Company-to-company exclusion and multi-company switching are outside Balanced; gate A06 records them Unavailable, not Passed.
Change history
| Date | Change |
|---|---|
| 2026-10-20 | Created (bootstrap Phase 2) |