Domain Model

The domain model should represent reusable project structure, branchable continuity, and narrative presentation.

The current implementation uses Project as the root lore object and Continuity as the continuity branch. Story and Campaign remain useful product concepts, but they are presentations or workflows over continuities rather than the storage root.

Main Types

Account
Workspace
Project
Continuity
Story
Campaign
Publication
Entity
Relationship
Fact
Knowledge
Disclosure
Event
Chronology
Mutation
Permission

Account

An account represents a user of the service.

An account may own projects, participate in continuities or campaigns, collaborate on projects, or follow public stories and publications.

Workspace

A workspace is the collaboration and ownership boundary.

Workspace
  id
  owner_id
  name
  created_at
  updated_at

Project

A project is the root lore container.

Project
  id
  workspace_id
  title
  description
  status
  visibility
  created_at
  updated_at

Continuity

A continuity is a mutable branch or version of a project.

Continuity
  id
  project_id
  parent_continuity_id optional
  title
  status
  branch_point optional
  created_at
  updated_at

Story

A story is a narrative presentation over a continuity.

Story
  id
  project_id
  continuity_id
  title
  description
  status
  visibility
  created_at
  updated_at

Campaign

A campaign is an interactive play workflow attached to a continuity, or a specialized continuity if the implementation chooses a simpler model.

Campaign
  id
  project_id
  continuity_id
  title
  status
  rules_system
  created_at
  updated_at

Entity

An entity is a node in the lore graph.

Entity
  id
  project_id
  kind
  name
  summary
  body
  visibility
  metadata

Possible entity kinds:

Character
Faction
Location
Item
PlotThread
Concept
Species
Culture
Religion
Mystery

Relationship

A relationship is an edge in the lore graph.

Relationship
  id
  project_id
  source_resource_id
  relation_kind
  target_resource_id
  visibility
  metadata

Possible relationship kinds:

belongs_to
controls
knows
suspects
opposes
supports
funds
located_at
caused_by
reveals
advances

The first implementation may keep relationships entity-to-entity. The target model should allow resource-to-resource relationships.

Fact

A fact is a claim or assertion about a project or continuity.

Fact
  id
  project_id
  continuity_id optional
  subject_resource_id optional
  predicate
  object_resource_id optional
  literal_value optional
  truth_status
  visibility
  metadata

Knowledge

Knowledge records who knows, suspects, or falsely believes a fact.

Knowledge
  id
  project_id
  continuity_id optional
  knower_resource_id
  fact_id
  certainty
  learned_at_event_id optional
  source optional

Certainty values should include:

Rumor
Suspected
Known
FalseBelief

Disclosure

Disclosure records which audience can see a fact, secret, or resource in the application.

Disclosure
  id
  project_id
  target_resource_id
  audience_kind
  audience_id optional
  visibility

Secret should usually be treated as a fact or disclosure state with restricted visibility, not as the only way to represent hidden information.

Event

An event is something that happens or may happen in a continuity.

Event
  id
  project_id
  continuity_id
  title
  description
  status
  visibility
  created_at
  updated_at

Event statuses:

Planned
Possible
Occurred
Prevented
Failed

Chronology

A chronology positions events inside a continuity.

ChronologyEntry
  id
  project_id
  continuity_id
  event_id
  position_kind
  position_value

Mutation

A mutation records a continuity state change.

Mutation
  id
  project_id
  continuity_id
  target_id
  changed_field
  old_value
  new_value
  reason
  actor_id optional
  occurred_at

Visibility

Visibility should be explicit.

Private
OwnerOnly
GmOnly
Collaborators
ContinuityParticipants
SpecificAccounts
Public

Design Note

The first version can use JSON metadata for flexible fields. Once patterns become stable, promote important fields into typed columns or typed domain structs.

Keep base project lore separate from continuity-specific state. Entities and relationships can start project-scoped; events, chronology entries, and mutations should move under continuities as soon as the continuity model is introduced.