Module 6 — Knowledge and Thinking Tools · Lesson 6.4
Charters on Projects and Tasks
Scoping the boundary to the work it applies to — and the false-friends field
~10 min
What you'll learn
- Choose the right scope for a given boundary
- Write a project charter that adds something the workspace charter does not
- Use the false-friends field to name proxy work
- Avoid the two failure modes of over-charter and under-charter
One charter for a whole workspace has to be general enough to apply everywhere, which means it cannot say anything sharp about a specific project. That is what the smaller scopes are for — and one of them has a field that names a failure mode most teams have never articulated.
Three scopes, one question each
Workspace KVN answers: what is this organization for and what will it never do? It applies to everything and should be written to survive a change of projects.
Project KVN answers: what is this specific effort for, and what is out of bounds for it? A project charter is where you say 'this migration does not change the data model' or 'this engagement does not include design work'. Those are true here and would be nonsense at workspace scope.
Task KVN answers: what is off-limits for this particular piece of work? 'Do not touch production', 'do not contact the client directly'. Narrow and specific.
The rule for choosing is simple: put the boundary at the smallest scope where it is true. A boundary written too broadly blocks work it was never meant to, and that is how a charter becomes something people route around.
False friends
Project charters carry a field the other scopes do not: false friends. It is for work that looks like it serves the Vision but actually serves a proxy for it.
This is worth dwelling on because it names something teams experience constantly and rarely articulate. If the Vision is 'customers onboard without human help', then building a better onboarding dashboard for the support team is a false friend: it is obviously onboarding work, it is obviously useful, and it serves the proxy — support efficiency — rather than the goal.
False friends are more dangerous than obvious off-mission work precisely because they pass the sniff test. Nobody argues about them, they get approved easily, and they consume the quarter.
Writing them down is the defence. A project charter whose false-friends field says 'dashboards and tooling for the support team — useful, but it is not the goal' gives everyone, including the agent, a way to catch it at proposal time rather than at retrospective.
How the scopes compose
The agent checks the charters that apply to the work it is being asked to create. A task in a project is subject to the project's charter and the workspace's.
They compose additively: a project cannot loosen a workspace Negation, only add to it. That is the correct direction — a boundary set at the organization level should not be removable by anyone who can create a project.
Practically, this means the workspace charter should hold the things that are true everywhere and should be a short list. Everything situational goes lower down, where it can be specific.
Over-charter and under-charter
Under-charter is the common state: a workspace charter and nothing else. The symptom is that the charter never catches anything specific, because it cannot — it is written at a level of generality where almost nothing crosses it.
Over-charter is rarer and more corrosive: a Negation on every project and half the tasks. The symptom is that people stop reading them, which means the one that mattered gets ignored along with the rest. A boundary only works if it is exceptional enough to be noticed.
The shape that works: a short workspace charter, project charters on the projects where scope creep is actually a risk, and task charters only where a specific piece of work has a specific danger. Most tasks should have none.
Scope your boundaries
- 1
Write a project charter for your riskiest project
The one most likely to expand. Say what it is for and what is out of bounds for it specifically.
- 2
Fill in the false-friends field
Name the work that looks like it serves the goal but serves a proxy. This is the field that catches the plausible detour.
- 3
Add a task-level Negation where it is genuinely needed
'Do not touch production', 'do not contact the client directly'. Rare, so that it is noticed.
- 4
Trim the workspace charter to what is true everywhere
Anything situational belongs at a lower scope where it can be specific.
What to watch
- Charter scope distribution
- How boundaries are spread across workspace, project and task scope.
- Healthy signal: A short workspace charter, charters on the projects that need them, and very few at task level.
- False-friend catches
- How often a proposal is stopped by a false-friends line rather than a plain Negation.
- Healthy signal: Occasionally. These are the catches that matter most, because nobody else was going to make them.
- Charter-free project share
- Share of active projects with no project-level charter.
- Healthy signal: Some is fine. All of them means every boundary is being written at a level too general to catch anything.
Key takeaways
- ·Put a boundary at the smallest scope where it is actually true.
- ·Project charters add false friends: work that serves a proxy for the Vision rather than the Vision.
- ·False friends are more dangerous than off-mission work because they pass the sniff test.
- ·Scopes compose additively — a project can add to a workspace Negation, never loosen it.
- ·Over-charter is corrosive: boundaries only work while they are exceptional enough to notice.
Module 7 starts the part of the product everything so far has been preparing for: the AI agent, what it is, and what it can actually do.