111k

Project Object Model

Project architecture contract synced from the project module source documents.

Purpose

This document defines the what + why of the project-centered object model.

It does not define detailed implementation flows.

It exists because the hardest project question is not "what fields do we show" but "what is the root object we are actually building around."

Block Position

Inside the toProject board, this page is the primary definition page of the Core Definition block.

It primarily owns these topics:

  • Project Root
  • Outcome
  • Workstream
  • Task
  • Activity
  • Assets & Files

It should be read before runtime, git, or UI mapping.

Those pages depend on these semantics. They do not replace them.

Core Position

This architecture is project-centered first.

The primary design question is:

  • what is the project object
  • how do all other objects derive meaning from it

Not:

  • what tools are available
  • what runtime is active
  • what one engine can do

This ordering matters.

If the architecture starts from tools or runtime, project becomes an afterthought. If it starts from project, tools and runtime become subordinate operating concerns. That is the difference between a product object model and an agent shell.

Project As The Root Object

Project is the root coordination object of the module.

Everything else is subordinate to project context.

That means:

  • outcome belongs to a project
  • workstream belongs to a project
  • task belongs to a project
  • activity belongs to a project
  • assets belong to a project
  • runtime is the current operating state of a project

Project gives execution data its shared meaning, boundary, and version spine.

That is why Project is more than a container. A container can hold unrelated things. A root object gives them common semantics.

What Project Owns

Project owns six kinds of things.

This section is intentionally phrased as ownership rather than inclusion.

The point is not just that these things appear on the screen together. The point is that their meaning depends on project context.

1. Intent

  • summary
  • objective
  • scope boundary
  • acceptance framing

Without intent, execution becomes motion without an anchor.

2. Result Structure

  • outcome
  • success criteria
  • result definitions

Without result structure, work can be organized but never actually judged.

3. Execution Structure

  • workstreams
  • tasks
  • dependencies
  • timeline projections

Without execution structure, outcome remains abstract and cannot be operationalized.

4. Operating State

  • status
  • execution runtime
  • execution mode
  • progress
  • blocking
  • dates

Without operating state, the project cannot expose its live condition.

5. Operating Evidence

  • activity
  • reviews
  • decisions
  • approvals
  • automation traces
  • git-related events

Without operating evidence, project history collapses into anecdote rather than record.

6. Knowledge And Artifacts

  • files
  • docs
  • linked artifacts
  • design references

Without knowledge and artifacts, execution loses continuity and recoverability.

Canonical Relationship Chain

The canonical relationship chain is:

Project -> Outcome -> Workstream -> Task -> Activity / Assets

This does not imply a strict tree at every moment.

It defines semantic direction:

  • project sets the boundary
  • outcome defines success
  • workstream defines strategic lines of effort
  • task defines execution units
  • activity and assets capture what happened and what was produced

This is the key connective logic of the whole model.

Outcome is not just another tab next to Tasks. Workstream is not just another formatting of Tasks. The chain exists to stop those objects from collapsing into each other.

Canonical Entity Definitions

Project

The top-level execution container.

Responsibilities:

  • hold the primary objective
  • bind together its object types
  • expose current operating state
  • connect project intent to project execution
  • bind project structure to git and runtime surfaces

Outcome

A result object.

Outcome answers:

  • what result should exist if the project succeeds
  • how do we know it succeeded

Outcome is not:

  • feature decomposition
  • task breakdown
  • timeline itself

This boundary exists because the project previously drifted toward mixing desired result with execution decomposition. The architecture separates them so success remains legible even while execution changes.

Workstream

A structured execution line.

Workstream answers:

  • by which major lines of effort do we pursue the outcome
  • what problem domain each line covers
  • what key risk or uncertainty makes the line necessary

Workstream owns:

  • key features
  • execution lines
  • key risks
  • strategic decomposition of delivery

Risk is included here deliberately. A workstream exists because some line of effort is necessary to produce the outcome under real constraints. If risk is detached entirely, the rationale for the workstream becomes harder to see.

Task

A concrete execution unit.

Task answers:

  • what specific work must be done
  • who or what is progressing it
  • what is its state, timing, and dependency

This is why task must stay downstream from workstream. If task becomes the main abstraction, strategy disappears behind operational rows.

Activity

An execution history object.

Activity answers:

  • what happened
  • who or what did it
  • when it happened

Activity may include:

  • update
  • decision
  • review
  • approval
  • note

This object exists to keep the system honest. A project that can execute but cannot produce a trustworthy history is weakly governable.

Asset / File

A resource object.

This includes:

  • linked files
  • docs
  • references
  • design artifacts
  • delivery attachments

Runtime

A project facet, not the project itself.

Runtime answers:

  • what is the current active execution state
  • which agent mode is active
  • what is blocked, progressing, or waiting

Deliberate Boundaries

These boundaries matter because the earlier project surface drifted by letting adjacent concepts collapse into each other.

Notes Are Not A Top-Level Object Type

Notes belong under:

  • activity
  • files
  • knowledge artifacts

Risk Lives Inside Workstream

Risk is part of decomposition logic, not a detached register.

Project Is Not Runtime

Project owns runtime, but is larger than runtime.

Project Is Not An Engine

Project may dispatch into an execution engine, but should not collapse into one.

This is the most important protection against runtime-first architecture taking over the product model.

Reading Relationship

Use this page to define the semantic chain first.

Then continue into:

Return to the board home when you need the full block map: