Model

This page describes the structure behind the method. It defines what a topic is, how a topic is identified, which surfaces it has, how the reason for work is recorded, which statuses apply, and where each kind of information belongs. The terms are defined in the glossary.

The examples on this page use an invented venture called Example Co. Its names and codes are illustrations only.

Topic

A topic is exactly one venture combined with exactly one unit. This is the Venture × Unit rule.

A venture is a durable context in which value is created: a business, an organization, a client engagement, a household, or one person’s own affairs.
A unit is a functional area of accountability, such as operations, finance, or marketing. A unit is defined by its function, not by the team that does the work, and the same unit can exist in more than one venture.

Each venture has one topic for each unit it operates. Each unit has one topic for each venture it serves. The table shows this for two invented ventures and three units. Each cell is one topic, identified by its topic code.

Unit	Example Co (EX)	Demo Works (DW)
Operations (OP)	EXOP	DWOP
Finance (FI)	EXFI	DWFI
Marketing (MK)	EXMK	DWMK

Rules for topics:

There is at most one topic for each venture and unit combination.
The size of a topic is set by its venture and unit, not by the number of tasks, people, or months involved. Do not create a new topic because work is large or long.
A topic is not a chat channel, a folder, a project, or a goal. Those are surfaces or records that belong to a topic.
Each record has one home topic. When a record relates to another topic, link to that topic. Do not copy the record.
Not every venture uses every unit. Create a topic only when the venture and unit combination has ongoing work.

Topic code

A topic code is a short code that identifies exactly one topic. The recommended form has four characters:

Characters 1 and 2 identify the venture. For Example Co, the venture code is EX.
Characters 3 and 4 identify the unit. For Operations, the unit code is OP.
The topic code for Example Co Operations is EXOP.

Rules for topic codes:

A topic code identifies a topic. It is not a type, a status, or a priority. Do not use it as a prefix to mean “this is a decision” or “this is urgent”.
Use the same topic code in the name of every surface of the topic.
Look up the topic code in the registry before you use it. Never guess a code from the venture name or the unit name.
When a tool uses a different identifier for the topic, record it as an alias. An alias points to the same topic; it does not create a new one.

The topic also has a canonical name made of the venture name and the unit name, for example “Example Co Operations”. Surfaces use the topic code, the canonical name, or both.

Surfaces

A surface is a place in one tool where work on a topic happens. Tools are grouped into tool classes. TFW has eight tool classes. Each topic has at most one surface in each tool class. Chat is the exception: each topic has two channels. In the code repository class, the surface is the set of repositories whose names start with the topic’s prefix.

Tool class	Surface for EXOP	Purpose
Document storage	Shared drive “EXOP Example Co Operations”	Files, source material, and working documents
Task management	Project “Example Co Operations”, key `EXOP`	Accountable work and the Focus System
Knowledge base	Space “Example Co Operations” with a purpose page	Durable explanations, processes, and decision records
Chat	Channels `exop-exampleco-operations-chat` and `exop-exampleco-operations-automated`	Conversation between people, and messages from software
Email	Group `exop@example.com` and a label `EXOP`	Correspondence with people inside and outside the topic
Calendar	Event titles that start with `EXOP:`	Scheduled meetings and deadlines
Code repository	Repositories whose names start with `exop-`	Source code, configuration, and its change history
AI agent workspace	Project “EXOP Example Co Operations”	Instructions and reference material for AI agents

Rules for surfaces:

Not every topic needs a surface in every class. Create the surfaces the topic uses. Each surface that exists must map to exactly one topic.
A missing, duplicate, or inconsistent surface is a provisioning gap. Repair it. Do not create a parallel surface next to it.
All surfaces of a topic use the same access boundary. Record each deliberate exception.
Each surface has a maintainer.
A topic profile lists the topic code, name, owner, lifecycle status, participants, and a link to each surface.

The tool classes section describes each tool class. The tools section gives setup steps for specific products.

Focus System

TFW answers where work belongs and with whom. The Focus System answers why the work matters. It is a hierarchy of four levels, recorded in the task management surface.

Level	What it is	Links to
Objective	A durable target state or outcome	The top level
Intention	A desired direction that groups strategies	An objective
Strategy	An ongoing area of focus that groups action records, with an owner and a review date	An intention
Action record	A task, decision, blocker, idea, or role	A strategy

The kinds of action record are:

Task: a defined action with one accountable owner and a completion condition.
Decision: a choice, with its rationale, the person who made it, and the date.
Blocker: a present condition that prevents progress.
Idea: a possible action that is not yet defined well enough to do.
Role: a durable, recurring responsibility and the person who holds it.

Each lower level links to the level above it with one link. Read upward, the link is contributes to. Read downward, it is “is fulfilled by”. These links give every action record a path through a strategy and an intention to an objective.

Rules for the Focus System:

Objectives, intentions, and strategies are ongoing. Do not close them when one set of tasks is finished. Change their lifecycle status instead.
Every objective has at least one intention. Every intention links to an objective and has at least one strategy. Every strategy links to an intention and has an owner and a review date.
Links can cross topics when that is deliberate. A strategy in one topic can contribute to an intention in another.
A strategy can contain sub-strategies (nested strategies) when that is needed. A sub-strategy links to the strategy above it in the same way.
Add a level only when it helps planning or review.

Lifecycle statuses

Topics and focus items use the same four lifecycle statuses:

Status	Meaning for a topic	Meaning for a focus item
Identified	Recognized. Some surfaces or mappings may still be missing.	A candidate. Details may be incomplete.
Active	In operation and receives new work.	Pursued now.
Downstream	Accepted for the future. No action is needed now.	Accepted for later. No action is needed now.
Inactive	Receives no new work. Surfaces are kept or redirected under a retention rule.	No longer pursued.

Action records do not use these four statuses. They use the action workflow statuses below.

Action workflow statuses

Action records, such as tasks, move through the action workflow statuses. These statuses are separate from the lifecycle statuses of topics and focus items. The recommended workflow is:

Identified → Accepted → Work Started
Blocked, when work cannot continue
Needs Clarification → Clarification Provided, when a question must be answered first
Resolution Proposed → Closed, or Resolution Proposed → Resolution Rejected

Status	Meaning for an action record
Identified	The record exists, but it has not been accepted as work to do.
Accepted	The owner has accepted the record as work to do. Work has not started.
Work Started	Work on the record has started.
Blocked	Work cannot continue until a named condition is resolved.
Needs Clarification	Work cannot continue until a recorded question is answered.
Clarification Provided	The answer is recorded, and work can continue.
Resolution Proposed	The work is done, and the result is proposed for review against the completion condition.
Closed	The proposed result is accepted, or the record is closed without action for a recorded reason. The record receives no more work.
Resolution Rejected	The proposed result does not meet the completion condition. The record returns to work.

The word Identified is used in both sets of statuses. For a topic or focus item it is a lifecycle status; for an action record it is the first status of the action workflow. The workflow that is configured in the task management tool takes precedence over this list. Keep the meaning of each status written down where the workflow is configured.

Reviews by scope

A review checks one scope of the Focus System or of a topic. There are five reviews. Choose the smallest scope that answers the question you have. Use a saved view or filter in the task management tool for each review; the view shows the records, and the records stay the source of truth.

Review	Typical tempo	Scope	Question the review answers
Near-term action	Weekly or more often	Active strategies and their action records	What will be worked on next, and what is blocked, unowned, or unranked?
Strategy review	On each strategy’s review date	One strategy and the action records that contribute to it	Does every action record contribute to the strategy? Does the strategy have an owner and a review date?
Intention review	Monthly or quarterly	One intention, its strategies, and their action records	Are the strategies current, consistent with each other, and linked to the intention?
Objective review	Quarterly or yearly	One objective and every focus item that contributes to it	Is there a complete path from the objective to action records? Are inactive and downstream focus items intentional?
Topic audit	When the topic changes	One topic (one venture and one unit)	Which focus items or action records have no home topic, owner, review date, or focus path? Does every required surface exist with the right access?

During a review, treat a missing link as something to check on the records, not something to assume from the view. Propose or make corrections to the records in the task management surface, using contributes to links, then check the view again.

Information placement

Each kind of information has one source of truth. Choose the tool class by the kind of information, not by the tool that happens to be open.

Kind of information	Source of truth	Do not use for
Accountable work: focus items, action records, owners, status, dates, dependencies	Task management	Long explanations, files, source code
Durable knowledge: purpose, processes, explanations, decision records, indexes	Knowledge base	Fine-grained task status, secrets
Files: source documents, assets, scans, signed copies, working documents	Document storage	Decisions that exist only inside a file comment
Versioned implementation: source code, configuration, executable runbooks	Code repository	Business approvals, chat transcripts, credentials
Discussion and coordination	Chat	Decisions, requirements, or procedures that must stay findable
Correspondence with its original sender and recipients	Email	The task or decision that results from the message
Scheduled time, attendees, and meeting logistics	Calendar	The decisions and actions that result from the meeting
Instructions and reference material for AI agents on the topic	AI agent workspace	Agent output that has not been written to its source of truth, credentials
Credentials and secrets	A dedicated secrets manager (outside the eight tool classes), with one shared folder or vault per topic	Any of the eight tool classes

Rules for placement:

Write the record in its source of truth first. Then link to it from other surfaces.
Do not copy content between tools. Copies go out of date.
Keep facts, proposals, decisions, and tasks separate. Do not present a proposal as a decision.
For each material claim, keep a link to its evidence: a source document, a measurement, or an approved record.
When a conversation produces a result that must last, record it in the source of truth and post the link back in the conversation.