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.
Server contracts and request enforcement
Illustrative, not frozen (architecture rev 3 p. 8).
| Operation | Illustrative contract | Required guard |
|---|---|---|
| Company context | GET /v1/me/company | Resolve exactly one active membership; never trust a client-supplied tenant id |
| Draft and publication | POST /v1/opportunities; PATCH /v1/opportunities/{id}; POST /v1/opportunities/{id}/publish | Schema validation, owning-company role/assignment, expected version, approval binding |
| Discovery | GET /v1/opportunities; GET /v1/recommendations | Audience and active-status filtering before search, ranking, snippets, counts and pagination |
| Private question / interest | POST /v1/opportunities/{id}/questions or /expressions | Authorised opportunity, no self-interest, meaningful fields, approved contributor submission, version reference, idempotency key |
| Accept discussion | POST /v1/expressions/{id}/accept | Owner-side authority, current response state, no duplicate discussion, state and notification event committed together |
| Messages / actions | GET/POST /v1/conversations/{id}/messages; POST /{id}/actions | Participant-company access plus role/assignment; assignee eligibility; safe due date and completion transition |
| Team / administration | Scoped invitation, membership and recovery endpoints | Company admin versus DG authority; MFA for DG; one-company restriction; audit sensitive changes |
flowchart LR A[Authenticate<br/>valid session] --> B[Resolve membership<br/>active / one company] --> C[Authorise record<br/>role + assignment] --> D[Validate version / transition<br/>commit mutation + event]
Failure behaviour: consistent denial that never reveals whether an inaccessible record exists; actionable validation; safe stale-write conflict; rate-limited abuse and retryable requests. Security controls: secure session cookies, CSRF protection where applicable, input sanitisation, pagination, server-side secrets; database constraints and (if adopted) row policies as defence in depth.
Build step: Step-03-Policy-Pipeline-and-Isolation-Harness.