Engineering
Security
Separate verified identity, scoped access, recipient targeting and public disclosure.
Drag to move · Hover to trace. Select to read more. Keyboard: Alt + arrow keys to move.
- Web Client
- API Transport
- Request Boundary
- App Check
- Firebase Auth
- Permission / Capability
- Audience
- Domain Service
- Resource
- Today
- Firestore
- Storage
Drag a card to rearrange it. Select it to learn more.
Connections in words
- Permission / Capability controls current access to Resource.
- Domain Service persists canonical records in Firestore.
- Domain Service accesses admitted files in Storage.
- Domain Service checks identity using Firebase Auth.
- Web Client calls explicit API Transport.
- API Transport submits requests to Request Boundary.
- Request Boundary establishes identity through Firebase Auth.
- Firebase Auth precedes evaluation of Permission / Capability.
- Permission / Capability admits scoped commands to Domain Service.
- App Check attests application context at Request Boundary.
- Firestore supplies authorized source records for Today.
Authentication ≠ Authorization. UI visibility ≠ Authorization. Audience membership ≠ Resource access.
Evaluate on the server
The server verifies identity and the relevant context, then checks current capabilities and subject access. Hiding a button or trusting a client-side role is insufficient.
Keep contexts distinct
Production, Team and personal relationships have different ownership. A permission in one context is not assumed in another. Private contact fields require their own visibility and consent decisions.
Public is a separate boundary
Public profiles, websites and recipient projections expose selected fields. Private records must not leak through serialized responses, metadata, structured data or errors.
Proof has scope
Focused positive and negative authorization checks support a particular boundary. Source review and local tests do not establish complete security or production acceptance. Evidence states what was actually assessed.
Go deeper
Conceptual architecture. Implementation and release status are assessed separately.
Domain
Production Resource
A creative or operational artifact with production context.
See this concept connect visually →
Why it exists
Assets should share version and review mechanisms rather than separate approval silos.
Example
A storyboard, wardrobe look or VFX version connects to people, scenes, shots and days.
Connects to
- Resource has a separately selected Final reference
- Production owns Resource
- Resource has immutable Resource Version
- Permission / Capability controls current access to Resource
- Resource has person context Person
- Resource has work context Assignment
- Resource has narrative context Scene
- Resource has shot context Shot
- Resource has operational context Day
- Group provides context for Resource
Implementation notes
Resources are implemented locally; hosted acceptance and production release remain pending.
Public evidence: Resources have immutable versions and exact-version review.
Related workflows
Related decisions
Technical details
Resources are implemented locally; hosted acceptance and production release remain pending.
Conceptual explanation; private implementation details are omitted.
Primitive
Audience
A selector describing intended recipients or reviewers.
See this concept connect visually →
Why it exists
Targeting the right people is different from granting access to their data.
Example
Send an update to eligible assignments in A Unit called today.
Connects to
- Group can select eligible people for Audience
- Call Sheet targets eligible recipients through Audience
- Workflow Stage selects reviewers through Audience
- Audience targets Update
Implementation notes
Audience membership never grants resource access.
Public evidence: Role and audience selection are separate from scoped authority.
Related workflows
Related decisions
Technical details
Audience membership never grants resource access.
Conceptual explanation; private implementation details are omitted.
Service
Permission / Capability
Explicit authority to perform an action in a scope.
See this concept connect visually →
Why it exists
Software authority must be evaluated independently of job labels and UI presentation.
Example
A person may view a resource without having permission to approve it.
Connects to
- Permission / Capability authorizes eligible Review
- Permission / Capability controls current access to Resource
- Firebase Auth precedes evaluation of Permission / Capability
- Permission / Capability admits scoped commands to Domain Service
Implementation notes
Authentication establishes identity; authorization evaluates current scoped authority.
Public evidence: Role and audience selection are separate from scoped authority.
Related workflows
No curated journey in this edition.
Related decisions
Technical details
Authentication establishes identity; authorization evaluates current scoped authority.
Conceptual explanation; private implementation details are omitted.
Projection
Today
An authorized read model composing work across contexts.
See this concept connect visually →
Why it exists
People need one understandable view of their work without creating another source of truth.
Example
Today combines upcoming calls, assignments, activity and attention.
Connects to
- Attention contributes actionable work to Today
- Assignment contributes work to Today
- Schedule contributes planned time to Today
- Availability contributes eligible requests to Today
- Firestore supplies authorized source records for Today
Implementation notes
Today does not own canonical work, complete actions, or grant permission.
Public evidence: Today composes authorized source work rather than owning it.
Related workflows
No curated journey in this edition.
Related decisions
Technical details
Today does not own canonical work, complete actions, or grant permission.
Conceptual explanation; private implementation details are omitted.
Client
Web Client
The React and Next.js product experience.
See this concept connect visually →
Why it exists
The operational application needs interaction and authenticated domain access.
Example
The web crew directory and production workspaces share server contracts.
Connects to
- Web Client requests application access through Cloudflare Edge
- Desktop Client hosts the experience of Web Client
- Web Client calls explicit API Transport
Implementation notes
This engineering site is a separate static project and does not use the application runtime.
Public evidence: Clients share domain contracts while retaining distinct interfaces.
Related workflows
No curated journey in this edition.
Related decisions
Technical details
This engineering site is a separate static project and does not use the application runtime.
Conceptual explanation; private implementation details are omitted.
Service
Domain Service
Server-owned commands and queries for a bounded domain.
See this concept connect visually →
Why it exists
UI state should not decide privileged transitions or storage authority.
Example
A production command validates context before committing work.
Connects to
- Domain Service returns an authorized Response projection
- Next.js Origin runs Domain Service
- Domain Service persists canonical records in Firestore
- Domain Service accesses admitted files in Storage
- Domain Service checks identity using Firebase Auth
- Domain Service admits background work to Functions / Jobs
- Domain Service uses scoped adapters for External Provider
- Permission / Capability admits scoped commands to Domain Service
Implementation notes
Commands own transitions; queries return bounded authorized projections.
Public evidence: Cloudflare edge and Google Cloud application workloads have separate roles.
Related workflows
No curated journey in this edition.
Related decisions
See the system-wide decisions.
Technical details
Commands own transitions; queries return bounded authorized projections.
Conceptual explanation; private implementation details are omitted.
Provider
Firebase Auth
The application identity provider.
See this concept connect visually →
Why it exists
Identity verification needs a dedicated provider, separate from domain permission decisions.
Example
Sign-in identifies a user before production access is evaluated.
Connects to
- Domain Service checks identity using Firebase Auth
- Request Boundary establishes identity through Firebase Auth
- Firebase Auth precedes evaluation of Permission / Capability
Implementation notes
Authentication is not authorization.
Public evidence: Cloudflare edge and Google Cloud application workloads have separate roles.
Related workflows
No curated journey in this edition.
Related decisions
Technical details
Authentication is not authorization.
Conceptual explanation; private implementation details are omitted.
Provider
Firestore
Canonical application records and scoped persistence.
See this concept connect visually →
Why it exists
Durable records need transactional ownership rather than being reconstructed from the UI.
Example
Membership and production work records retain their own owners.
Connects to
- Firestore supplies scoped source data for Response projection
- Domain Service persists canonical records in Firestore
- Firestore supplies authorized source records for Today
Implementation notes
Public diagrams do not expose collection inventories or production identifiers.
Public evidence: Cloudflare edge and Google Cloud application workloads have separate roles.
Related workflows
No curated journey in this edition.
Related decisions
Technical details
Public diagrams do not expose collection inventories or production identifiers.
Conceptual explanation; private implementation details are omitted.
Provider
Storage
Private and public file storage behind appropriate domain policies.
Why it exists
Knowing a file location must not be equivalent to permission to retrieve it.
Example
A private resource representation is served only after current access is checked.
Connects to
- Domain Service accesses admitted files in Storage
Implementation notes
Resource bytes and website public media have different exposure policies.
Public evidence: Resources have immutable versions and exact-version review.
Related workflows
No curated journey in this edition.
Related decisions
See the system-wide decisions.
Technical details
Resource bytes and website public media have different exposure policies.
Conceptual explanation; private implementation details are omitted.
Provider
App Check
Application attestation at protected request boundaries.
Why it exists
Identity and application attestation address different request concerns.
Example
A protected request carries application attestation in addition to user identity.
Connects to
- App Check attests application context at Request Boundary
Implementation notes
Attestation complements authentication and scoped authorization.
Public evidence: Cloudflare edge and Google Cloud application workloads have separate roles.
Related workflows
No curated journey in this edition.
Related decisions
See the system-wide decisions.
Technical details
Attestation complements authentication and scoped authorization.
Conceptual explanation; private implementation details are omitted.
Service
API Transport
The explicit client contract for making an application request.
Why it exists
Callers should be clear about which identity and request context they carry.
Example
A client submits a domain command using its declared transport.
Connects to
- Web Client calls explicit API Transport
- iOS Client uses shared server contracts through API Transport
- API Transport submits requests to Request Boundary
Implementation notes
This public example omits internal transport headers and private endpoint details.
Public evidence: Cloudflare edge and Google Cloud application workloads have separate roles.
Related workflows
No curated journey in this edition.
Related decisions
See the system-wide decisions.
Technical details
This public example omits internal transport headers and private endpoint details.
Conceptual explanation; private implementation details are omitted.
Service
Request Boundary
Admission, routing and request policy before domain execution.
Why it exists
Privileged requests must reach a checked server boundary before performing work.
Example
A consolidated dispatcher routes an admitted command to a domain handler.
Connects to
- API Transport submits requests to Request Boundary
- Request Boundary establishes identity through Firebase Auth
- App Check attests application context at Request Boundary
Implementation notes
The diagram describes responsibilities, not exact security-control configuration.
Public evidence: Role and audience selection are separate from scoped authority.
Related workflows
No curated journey in this edition.
Related decisions
See the system-wide decisions.
Technical details
The diagram describes responsibilities, not exact security-control configuration.
Conceptual explanation; private implementation details are omitted.