Interactive architecture
Request lifecycle
How does an application request become domain work?
- Overview
- Production graph
- Professional network
- Resources
- Time and operations
- Workflows
- System architecture
- Security and trust
- Clients
- Publishing
- Collaboration spaces
- Today and Attention
- Request lifecycle
Explicit transport reaches the request boundary, identity and scoped authority checks precede domain work, and the response is an authorized projection.
- 1Web Client
- 2API Transport
- 3Cloudflare Edge
- 4Request Boundary
- 5Firebase Auth
- 6Permission / Capability
- 7Domain Service
- 8Firestore
- 9Response projection
- 10Web Client
Architecture in words
- Firestore supplies scoped source data for Response projection
- Domain Service returns an authorized Response projection
- Functions / Jobs attempts effects through External Provider
- 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
- 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
Connections in words
- Firestore supplies scoped source data for Response projection
- Domain Service returns an authorized Response projection
- Functions / Jobs attempts effects through External Provider
- 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
- 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
- Web ClientThe React and Next.js product experience.
- API TransportThe explicit client contract for making an application request.
- Request BoundaryAdmission, routing and request policy before domain execution.
- App CheckApplication attestation at protected request boundaries.
- Firebase AuthThe application identity provider.
- Permission / CapabilityExplicit authority to perform an action in a scope.
- External ProviderA boundary for third-party services and integrations.
- Domain ServiceServer-owned commands and queries for a bounded domain.
- FirestoreCanonical application records and scoped persistence.
- StoragePrivate and public file storage behind appropriate domain policies.
- Functions / JobsBackground execution of admitted domain effects.
- Response projectionThe minimum authorized output returned by a domain query or command.
- Canonical
- Transitional
- Planned
- Projection
- External
- Current selection
All architecture nodes
- Person
- Profile
- Roster relationship
- Space
- Production
- Production Membership
- Production Assignment
- Production Group
- Role
- Department
- Availability
- Staffing
- Production Day
- Schedule
- Call Sheet
- Acknowledgement
- Presence
- Production Resource
- Resource Version
- Scene
- Shot
- Task
- Workflow Definition
- Workflow
- Workflow Stage
- Review
- Approval
- Audit Event
- Audience
- Permission / Capability
- Message
- Update
- Attention
- Today
- Team
- Organization
- Networking Community
- Website
- Publication
- Web Client
- iOS Client
- Desktop Client
- MCP Client
- Cloudflare Edge
- Next.js Origin
- Domain Service
- Firebase Auth
- Firestore
- Storage
- Functions / Jobs
- External Provider
- App Check
- API Transport
- Request Boundary
- Final reference
- Response projection
Primitive
Person
A persistent professional identity across changing work contexts.
See this concept connect visually →
Why it exists
A person should not be recreated each time they work on a production.
Example
One person participates in two productions with different work assignments.
Connects to
- Person has presentation Profile
- Person participates through Membership
- Membership identifies Person
- Person responds with Availability
- Person may retain a reviewed Roster relationship
- Resource has person context Person
Implementation notes
Identity persists; access is evaluated in the current collaboration context.
Public evidence: Production membership and work assignments are separate records.
Related workflows
Related decisions
Technical details
Identity persists; access is evaluated in the current collaboration context.
Conceptual explanation; private implementation details are omitted.
Projection
Profile
An editable presentation of a person.
See this concept connect visually →
Why it exists
Public biography and contact presentation change independently of identity.
Example
A public profile highlights selected credits while production contact details stay scoped.
Connects to
Implementation notes
A profile is a projection, not membership or access authority.
Public evidence: Websites publish selected projections of canonical contexts.
Related workflows
No curated journey in this edition.
Related decisions
Technical details
A profile is a projection, not membership or access authority.
Conceptual explanation; private implementation details are omitted.
Domain
Roster relationship
A personal professional relationship retained beyond a production.
See this concept connect visually →
Why it exists
Temporary participation should not become an automatic permanent contact record.
Example
Save a coworker to My Roster after reviewing the contact information you may retain.
Connects to
- Person may retain a reviewed Roster relationship
- Roster relationship supports future work in Production
Implementation notes
Personal Roster records and Production People remain distinct.
Public evidence: Websites publish selected projections of canonical contexts.
Related workflows
Related decisions
See the system-wide decisions.
Technical details
Personal Roster records and Production People remain distinct.
Conceptual explanation; private implementation details are omitted.
Primitive
Space
A conceptual collaboration context with its own lifecycle and authority.
Why it exists
Similar collaboration experiences need a shared vocabulary without erasing domain boundaries.
Example
Production, Team, Organization and Community are contexts, not interchangeable permissions.
Connects to
- Space includes the concept of Production
- Space includes the concept of Team
- Space includes the concept of Organization
- Space includes the concept of Networking Community
Implementation notes
Space is explanatory vocabulary; it does not claim one universal storage object.
Related workflows
No curated journey in this edition.
Related decisions
Technical details
Space is explanatory vocabulary; it does not claim one universal storage object.
Conceptual explanation; private implementation details are omitted.
Domain
Production
The operational context in which people coordinate production work.
See this concept connect visually →
Why it exists
Identity alone cannot describe who belongs to a specific production and what happens there.
Example
A production organizes crew, work, days, resources and communication.
Connects to
- Membership belongs to Production
- Production includes participation Membership
- Production organizes work in Group
- Production owns operational Day
- Roster relationship supports future work in Production
- Production owns Resource
- Production scopes Message
- Production has public projection Website
- Space includes the concept of Production
Implementation notes
Canonical Production direction retains existing compatible application records.
Related workflows
- Add a person to Production
- Issue a call sheet
- Check in on set
- Save a Production coworker to Personal Roster
- Publish a website
Related decisions
Technical details
Canonical Production direction retains existing compatible application records.
Conceptual explanation; private implementation details are omitted.
Domain
Production Membership
A person’s participation in one production.
See this concept connect visually →
Why it exists
Belonging to a production and performing a particular job have different lifecycles.
Example
A crew member stays in the production while a camera assignment changes.
Connects to
- Person participates through Membership
- Membership belongs to Production
- Production includes participation Membership
- Membership identifies Person
- Membership performs work through Assignment
- Assignment retains participation Membership
- Staffing leads to participation through Membership
Implementation notes
Membership is stable participation; source-backed preparation is not an application release claim.
Public evidence: Production membership and work assignments are separate records.
Related workflows
- Add a person to Production
- Book a crew member
- Assign a crew member to a group
- Replace an assignment
- Save a Production coworker to Personal Roster
Related decisions
Technical details
Membership is stable participation; source-backed preparation is not an application release claim.
Conceptual explanation; private implementation details are omitted.
Domain
Production Assignment
A descriptive record of the work a production member performs.
See this concept connect visually →
Why it exists
A person can perform several jobs without duplicating identity or membership.
Example
One member has a camera assignment and a later second-unit assignment.
Connects to
- Membership performs work through Assignment
- Assignment retains participation Membership
- Assignment describes work as Role
- Assignment classifies work in Department
- Assignment belongs to / leads Group
- Assignment is called for work on Day
- Resource has work context Assignment
- Assignment contributes work to Today
Implementation notes
Work assignments may describe role, department, groups, dates and reporting relationships.
Public evidence: Production membership and work assignments are separate records.
Related workflows
Related decisions
Technical details
Reports-to, shadowing and replacement describe relationships between assignments within one Production. They preserve participation and history and do not grant software authority.
Conceptual explanation; private implementation details are omitted.
Domain
Production Group
Flexible operational organization inside a production.
See this concept connect visually →
Why it exists
Units, departments and working teams should not require separate group architectures.
Example
A Unit and a lighting working group organize assignments.
Connects to
- Assignment belongs to / leads Group
- Production organizes work in Group
- Group can select eligible people for Audience
- Group provides context for Resource
Implementation notes
Parent groups, leadership and group membership do not automatically confer authority.
Public evidence: Production membership and work assignments are separate records.
Related workflows
Related decisions
Technical details
Parent groups, leadership and group membership do not automatically confer authority.
Conceptual explanation; private implementation details are omitted.
Domain
Role
A human-readable description of production work.
See this concept connect visually →
Why it exists
A job title should communicate work without silently granting software access.
Example
A gaffer leads lighting work; a casting director finds performers; an actor performs a part. Each still needs explicit permission to edit or approve.
Connects to
- Assignment describes work as Role
Implementation notes
Role labels and permissions remain independent.
Public evidence: Production membership and work assignments are separate records.
Related workflows
No curated journey in this edition.
Related decisions
Technical details
Role labels and permissions remain independent.
Conceptual explanation; private implementation details are omitted.
Domain
Department
A classification of work within the production.
Why it exists
Department context supports organization and targeting without becoming a permission shortcut.
Example
A gaffer works in lighting. Casting organizes auditions and performers. Departments help people find relevant work; they do not grant permissions.
Connects to
- Assignment classifies work in Department
Implementation notes
Department labels are descriptive; they do not grant access by themselves.
Public evidence: Production membership and work assignments are separate records.
Related workflows
No curated journey in this edition.
Related decisions
Technical details
Department labels are descriptive; they do not grant access by themselves.
Conceptual explanation; private implementation details are omitted.
Domain
Availability
A person’s response about whether they can work in a proposed period.
Why it exists
Availability is evidence for planning, not a booking or proof of arrival.
Example
Available, unavailable, conditional, or alternative dates describe possible work.
Connects to
- Person responds with Availability
- Availability informs Staffing
- Availability contributes eligible requests to Today
Implementation notes
Availability and staffing retain their own source records.
Public evidence: Production Days connect schedules, issued call sheets and presence.
Related workflows
Related decisions
See the system-wide decisions.
Technical details
Availability and staffing retain their own source records.
Conceptual explanation; private implementation details are omitted.
Domain
Staffing
The process that turns a candidate and scheduling evidence into intended work.
Why it exists
Interest, availability and booking commitments have different meanings.
Example
A coordinator checks availability before booking a crew member.
Connects to
- Availability informs Staffing
- Staffing leads to participation through Membership
Implementation notes
Existing staffing identifiers are not silently reinterpreted as Production Assignment identifiers.
Public evidence: Production Days connect schedules, issued call sheets and presence.
Related workflows
Related decisions
See the system-wide decisions.
Technical details
Existing staffing identifiers are not silently reinterpreted as Production Assignment identifiers.
Conceptual explanation; private implementation details are omitted.
Domain
Production Day
An operational work day inside a production.
See this concept connect visually →
Why it exists
A calendar event alone does not define a production’s calls, publication and attendance.
Example
Tomorrow’s production day ties a schedule to people, assignments and an issued call sheet.
Connects to
- Assignment is called for work on Day
- Production owns operational Day
- Day plans work through Schedule
- Day publishes Call Sheet
- Day records Presence
- Resource has operational context Day
Implementation notes
Meetings and holds do not automatically become Production Days.
Public evidence: Production Days connect schedules, issued call sheets and presence.
Related workflows
Related decisions
Technical details
Meetings and holds do not automatically become Production Days.
Conceptual explanation; private implementation details are omitted.
Domain
Schedule
The planned sequence and timing of work.
See this concept connect visually →
Why it exists
Planning must remain distinguishable from publication and actual attendance.
Example
A day’s schedule orders scenes, calls and locations.
Connects to
- Day plans work through Schedule
- Schedule is frozen into Call Sheet
- Schedule contributes planned time to Today
Implementation notes
Date-only periods and time-zone-aware instants are different concepts.
Public evidence: Production Days connect schedules, issued call sheets and presence.
Related workflows
Related decisions
See the system-wide decisions.
Technical details
Date-only periods and time-zone-aware instants are different concepts.
Conceptual explanation; private implementation details are omitted.
Projection
Call Sheet
An issued operational projection of a production day.
See this concept connect visually →
Why it exists
People need a stable version of the plan they were actually called against.
Example
An issued sheet freezes the reviewed schedule and recipient context.
Connects to
- Schedule is frozen into Call Sheet
- Day publishes Call Sheet
- Call Sheet targets eligible recipients through Audience
- Call Sheet receives version-specific Acknowledgement
- Call Sheet projects recipient obligations into Attention
Implementation notes
Publication, delivery, viewing and acknowledgement have separate meanings.
Public evidence: Production Days connect schedules, issued call sheets and presence.
Related workflows
Related decisions
See the system-wide decisions.
Technical details
Publication, delivery, viewing and acknowledgement have separate meanings.
Conceptual explanation; private implementation details are omitted.
Domain
Acknowledgement
A recipient’s response to an issued call-sheet version.
See this concept connect visually →
Why it exists
Opening a page or admitting delivery does not establish a crew member’s acknowledgement.
Example
A member acknowledges the exact issued call sheet.
Connects to
- Call Sheet receives version-specific Acknowledgement
- Acknowledgement is distinct from recorded Presence
Implementation notes
Acknowledgement is version-specific and distinct from arrival.
Public evidence: Production Days connect schedules, issued call sheets and presence.
Related workflows
Related decisions
See the system-wide decisions.
Technical details
Acknowledgement is version-specific and distinct from arrival.
Conceptual explanation; private implementation details are omitted.
Domain
Presence
Recorded participation and arrival state on a production day.
See this concept connect visually →
Why it exists
Planned work and actual on-set participation should never be inferred from each other.
Example
Called, acknowledged, checked in, late, absent, wrapped and replaced are conceptual distinctions.
Connects to
- Acknowledgement is distinct from recorded Presence
- Day records Presence
Implementation notes
State vocabulary illustrates operations; it is not a published internal enum or complete state machine.
Public evidence: Production Days connect schedules, issued call sheets and presence.
Related workflows
Related decisions
See the system-wide decisions.
Technical details
State vocabulary illustrates operations; it is not a published internal enum or complete state machine.
Conceptual explanation; private implementation details are omitted.
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.
Domain
Resource Version
An immutable snapshot of a resource’s submitted content.
See this concept connect visually →
Why it exists
Approval is meaningful only when it identifies what was reviewed.
Example
A new storyboard upload starts a new review without inheriting old approvals.
Connects to
Implementation notes
Current, approved and final versions are separate pointers.
Public evidence: Resources have immutable versions and exact-version review.
Related workflows
Related decisions
Technical details
Current, approved and final versions are separate pointers.
Conceptual explanation; private implementation details are omitted.
Domain
Scene
Narrative context for production work and resources.
Why it exists
Resources need to relate to the work they explain, not only to a folder.
Example
A wardrobe reference is associated with a scene.
Connects to
- Resource has narrative context Scene
Implementation notes
Scene and shot links provide context; they do not confer access.
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
Scene and shot links provide context; they do not confer access.
Conceptual explanation; private implementation details are omitted.
Domain
Shot
A specific planned camera or creative unit of work.
Why it exists
Shot-level context connects visual references with schedules and production work.
Example
A storyboard panel and shot-list entry describe the same planned shot.
Connects to
- Resource has shot context Shot
Implementation notes
A shot is a resource context, not an approval engine.
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
A shot is a resource context, not an approval engine.
Conceptual explanation; private implementation details are omitted.
Domain
Task
An actionable to-do obligation.
Why it exists
A job assignment should not be confused with a thing that must be completed.
Example
A review note produces a correction task linked to the exact resource version.
Connects to
- Review may create corrections as Task
Implementation notes
Approval, upload and task completion remain separate actions.
Public evidence: Supported domains use shared workflow transitions and audit mechanics.
Related workflows
No curated journey in this edition.
Related decisions
Technical details
Approval, upload and task completion remain separate actions.
Conceptual explanation; private implementation details are omitted.
Domain
Workflow Definition
Configuration describing a review’s stages and reviewer audiences.
Why it exists
Reusable process structure should be captured without hard-coding a separate engine for each artifact.
Example
A storyboard template includes director and cinematography review.
Connects to
- Workflow Definition configures a submitted Workflow
Implementation notes
Submission freezes the applicable definition; later edits affect future submissions.
Public evidence: Supported domains use shared workflow transitions and audit mechanics.
Related workflows
No curated journey in this edition.
Related decisions
Technical details
Submission freezes the applicable definition; later edits affect future submissions.
Conceptual explanation; private implementation details are omitted.
Service
Workflow
The review and transition lifecycle of a specific subject.
See this concept connect visually →
Why it exists
Financial documents, creative assets and call-sheet review need common transition and audit mechanics.
Example
A resource version moves through configured review stages.
Connects to
- Resource Version is reviewed through Workflow
- Workflow Definition configures a submitted Workflow
- Workflow orders Workflow Stage
- Workflow projects current obligations into Attention
Implementation notes
The common engine has subject adapters; coverage is stated per integration.
Public evidence: Supported domains use shared workflow transitions and audit mechanics.
Related workflows
Related decisions
Technical details
The common engine has subject adapters; coverage is stated per integration.
Conceptual explanation; private implementation details are omitted.
Domain
Workflow Stage
An ordered part of a submitted review process.
See this concept connect visually →
Why it exists
Sequential review responsibilities need explicit state rather than ambiguous flags.
Example
A VFX stage precedes a client review stage.
Connects to
- Workflow orders Workflow Stage
- Workflow Stage requests eligible Review
- Workflow Stage selects reviewers through Audience
Implementation notes
ANY means one eligible approval; ALL means every required reviewer approves.
Public evidence: Supported domains use shared workflow transitions and audit mechanics.
Related workflows
Related decisions
Technical details
ANY means one eligible approval; ALL means every required reviewer approves.
Conceptual explanation; private implementation details are omitted.
Domain
Review
Evaluation of an exact submitted version by eligible reviewers.
See this concept connect visually →
Why it exists
A familiar job title does not establish that someone can inspect or decide on this subject.
Example
A reviewer opens the submitted storyboard version and records feedback.
Connects to
- Workflow Stage requests eligible Review
- Review records a version-specific Approval
- Permission / Capability authorizes eligible Review
- Review may create corrections as Task
Implementation notes
Reviewer audience and current authority are distinct checks.
Public evidence: Supported domains use shared workflow transitions and audit mechanics.
Related workflows
Related decisions
See the system-wide decisions.
Technical details
Reviewer audience and current authority are distinct checks.
Conceptual explanation; private implementation details are omitted.
Domain
Approval
A recorded decision concerning the reviewed subject and version.
See this concept connect visually →
Why it exists
Approval cannot float independently of content identity and process state.
Example
An approved storyboard version remains historical after a later upload.
Connects to
- Approval supports explicit selection of Final reference
- Review records a version-specific Approval
- Approval produces transition history in Audit Event
Implementation notes
Approval is not finalization; a final reference is selected explicitly.
Public evidence: Supported domains use shared workflow transitions and audit mechanics.
Related workflows
Related decisions
See the system-wide decisions.
Technical details
Approval is not finalization; a final reference is selected explicitly.
Conceptual explanation; private implementation details are omitted.
Domain
Audit Event
A historical record of an accepted transition.
Why it exists
Current state alone cannot explain how a workflow reached that state.
Example
A review decision records a transition without rewriting earlier history.
Connects to
- Approval produces transition history in Audit Event
Implementation notes
Public examples describe accountability without exposing operational audit records.
Public evidence: Supported domains use shared workflow transitions and audit mechanics.
Related workflows
No curated journey in this edition.
Related decisions
See the system-wide decisions.
Technical details
Public examples describe accountability without exposing operational audit records.
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.
Domain
Message
A conversation contribution with participant and context boundaries.
Why it exists
Operational communication needs a persistent thread without making every observer a participant.
Example
Crew discuss tomorrow’s work in a scoped conversation.
Connects to
- Production scopes Message
- Message may create eligible Attention
Implementation notes
Private conversation visibility is distinct from optional activity following.
Public evidence: Today composes authorized source work rather than owning it.
Related workflows
No curated journey in this edition.
Related decisions
See the system-wide decisions.
Technical details
Private conversation visibility is distinct from optional activity following.
Conceptual explanation; private implementation details are omitted.
Domain
Update
A production announcement targeted at an eligible audience.
See this concept connect visually →
Why it exists
One operational message should reach the right current recipients without broad data exposure.
Example
Publish an update for everyone called on a production day.
Connects to
- Audience targets Update
- Update admits delivery intent to Functions / Jobs
Implementation notes
Delivery admission and successful provider delivery are separate states.
Public evidence: Today composes authorized source work rather than owning it.
Related workflows
Related decisions
See the system-wide decisions.
Technical details
Delivery admission and successful provider delivery are separate states.
Conceptual explanation; private implementation details are omitted.
Projection
Attention
A projection of currently actionable source obligations.
See this concept connect visually →
Why it exists
A notification history is not a reliable ledger of unfinished work.
Example
A pending acknowledgement or review appears as attention while still eligible.
Connects to
- Message may create eligible Attention
- Workflow projects current obligations into Attention
- Call Sheet projects recipient obligations into Attention
- Attention contributes actionable work to Today
Implementation notes
Source records own completion; projection coverage can be partial.
Public evidence: Today composes authorized source work rather than owning it.
Related workflows
No curated journey in this edition.
Related decisions
Technical details
Source records own completion; projection coverage can be partial.
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.
Domain
Team
A persistent shared operational collaboration context.
Why it exists
Long-lived shared state has different ownership from a temporary production.
Example
A team owns shared membership and its public presentation.
Connects to
Implementation notes
Team and Production authority remain separate.
Public evidence: Websites publish selected projections of canonical contexts.
Related workflows
No curated journey in this edition.
Related decisions
Technical details
Team and Production authority remain separate.
Conceptual explanation; private implementation details are omitted.
Domain
Organization
An organizational collaboration and publishing context.
Why it exists
An organization’s identity should not be confused with every production it supports.
Example
An organization presents its people and selected public activity.
Connects to
Implementation notes
This public draft does not assess complete Organization feature coverage or release.
Related workflows
No curated journey in this edition.
Related decisions
See the system-wide decisions.
Technical details
This public draft does not assess complete Organization feature coverage or release.
Conceptual explanation; private implementation details are omitted.
Domain
Networking Community
A professional community with its own membership and interaction lifecycle.
Why it exists
Networking participation is different from operational production membership.
Example
Professionals discuss shared interests in a community.
Connects to
- Networking Community has public projection Website
- Space includes the concept of Networking Community
Implementation notes
Shared interaction components do not imply shared domain authority.
Related workflows
No curated journey in this edition.
Related decisions
Technical details
Shared interaction components do not imply shared domain authority.
Conceptual explanation; private implementation details are omitted.
Projection
Website
A configured public projection of an eligible canonical context.
See this concept connect visually →
Why it exists
Publishing should reuse identity and content without exposing private application records.
Example
A production website presents approved public information.
Connects to
- Production has public projection Website
- Profile has public projection Website
- Team has public projection Website
- Organization has public projection Website
- Networking Community has public projection Website
- Website is configured for Publication
Implementation notes
Public projection, configuration and publication have distinct responsibilities.
Public evidence: Websites publish selected projections of canonical contexts.
Related workflows
Related decisions
Technical details
Public projection, configuration and publication have distinct responsibilities.
Conceptual explanation; private implementation details are omitted.
Service
Publication
The deliberate selection and release of public presentation.
See this concept connect visually →
Why it exists
Public visibility must be an explicit boundary rather than a side effect of membership.
Example
Publish a reviewed website configuration to a public domain.
Connects to
- Website is configured for Publication
- Publication is delivered through Cloudflare Edge
Implementation notes
The public presentation differs from canonical private records.
Public evidence: Websites publish selected projections of canonical contexts.
Related workflows
Related decisions
Technical details
The public presentation differs from canonical private records.
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.
Client
iOS Client
Native UI participating in a SwiftUI migration.
Why it exists
Device experiences need their own UI while respecting shared server identity and authority.
Example
A native production screen uses common server contracts.
Connects to
- iOS Client requests application access through Cloudflare Edge
- iOS Client uses shared server contracts through API Transport
Implementation notes
Native coverage is incremental; supported existing shell experiences coexist during migration.
Public evidence: Clients share domain contracts while retaining distinct interfaces.
Related workflows
No curated journey in this edition.
Related decisions
Technical details
Native coverage is incremental; supported existing shell experiences coexist during migration.
Conceptual explanation; private implementation details are omitted.
Client
Desktop Client
A Tauri macOS shell around the hosted web application.
Why it exists
Local device capabilities can augment the hosted product without running another backend.
Example
A desktop window opens the hosted Filmclusive experience.
Connects to
- Desktop Client hosts the experience of Web Client
Implementation notes
Desktop does not imply offline parity or an independent local Next.js server.
Public evidence: Clients share domain contracts while retaining distinct interfaces.
Related workflows
No curated journey in this edition.
Related decisions
Technical details
Desktop does not imply offline parity or an independent local Next.js server.
Conceptual explanation; private implementation details are omitted.
Client
MCP Client
A stateless integration surface with its own authentication boundary.
Why it exists
Tool clients need explicitly scoped access rather than private data-plane credentials.
Example
An authorized MCP tool calls the public application API.
Connects to
- MCP Client accesses public APIs through Cloudflare Edge
Implementation notes
The service is stateless and does not hold Firebase credentials.
Public evidence: Clients share domain contracts while retaining distinct interfaces.
Related workflows
No curated journey in this edition.
Related decisions
Technical details
The service is stateless and does not hold Firebase credentials.
Conceptual explanation; private implementation details are omitted.
Infrastructure
Cloudflare Edge
The edge and control plane surrounding application workloads.
See this concept connect visually →
Why it exists
Ingress, static delivery and coordination have different responsibilities from canonical domain data.
Example
The edge delivers assets and forwards admitted application requests.
Connects to
- Publication is delivered through Cloudflare Edge
- Web Client requests application access through Cloudflare Edge
- iOS Client requests application access through Cloudflare Edge
- MCP Client accesses public APIs through Cloudflare Edge
- Cloudflare Edge forwards admitted requests to Next.js Origin
Implementation notes
Public disclosure is limited to provider roles, not private gateways or recovery mechanisms.
Public evidence: Cloudflare edge and Google Cloud application workloads have separate roles.
Related workflows
Related decisions
Technical details
Public disclosure is limited to provider roles, not private gateways or recovery mechanisms.
Conceptual explanation; private implementation details are omitted.
Infrastructure
Next.js Origin
The Node-capable web runtime hosted on Google Cloud Run.
See this concept connect visually →
Why it exists
Server-side application and provider workloads need a suitable runtime behind the edge.
Example
The origin executes authorized domain commands and queries.
Connects to
- Cloudflare Edge forwards admitted requests to Next.js Origin
- Next.js Origin runs Domain Service
Implementation notes
Cloudflare owns ingress; Google Cloud Run hosts the Next.js runtime.
Public evidence: Cloudflare edge and Google Cloud application workloads have separate roles.
Related workflows
No curated journey in this edition.
Related decisions
Technical details
Cloudflare owns ingress; Google Cloud Run hosts the Next.js 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.
Service
Functions / Jobs
Background execution of admitted domain effects.
Why it exists
Slow or retried effects need durable processing outside an interactive request.
Example
Process notification intent after the domain change is committed.
Connects to
- Update admits delivery intent to Functions / Jobs
- Functions / Jobs attempts effects through External Provider
- Domain Service admits background work to Functions / Jobs
Implementation notes
Queue admission is not successful delivery.
Public evidence: Cloudflare edge and Google Cloud application workloads have separate roles.
Related workflows
Related decisions
See the system-wide decisions.
Technical details
Queue admission is not successful delivery.
Conceptual explanation; private implementation details are omitted.
Provider
External Provider
A boundary for third-party services and integrations.
Why it exists
Provider behavior and delivery are distinct from application state.
Example
An external communication provider processes an admitted delivery.
Connects to
- Functions / Jobs attempts effects through External Provider
- Domain Service uses scoped adapters for External Provider
Implementation notes
Public provider descriptions do not promise every integration is released.
Related workflows
Related decisions
See the system-wide decisions.
Technical details
Public provider descriptions do not promise every integration is released.
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.
Domain
Final reference
The explicitly selected final version of a production resource.
See this concept connect visually →
Why it exists
Approved, current and final versions answer different questions.
Example
A later upload does not replace the previously selected final storyboard version.
Connects to
- Approval supports explicit selection of Final reference
- Resource has a separately selected Final reference
Implementation notes
Finalization is explicit and requires the relevant approved version; it is not upload success.
Related workflows
No curated journey in this edition.
Related decisions
See the system-wide decisions.
Technical details
Finalization is explicit and requires the relevant approved version; it is not upload success.
Conceptual explanation; private implementation details are omitted.
Projection
Response projection
The minimum authorized output returned by a domain query or command.
See this concept connect visually →
Why it exists
Clients need useful presentation data without receiving private canonical records wholesale.
Example
A response describes the permitted work fields for the current actor.
Connects to
- Firestore supplies scoped source data for Response projection
- Domain Service returns an authorized Response projection
Implementation notes
A response projection does not become permission truth or replace canonical source ownership.
Related workflows
No curated journey in this edition.
Related decisions
See the system-wide decisions.
Technical details
A response projection does not become permission truth or replace canonical source ownership.
Conceptual explanation; private implementation details are omitted.