generated from coulomb/repo-seed
119 lines
2.8 KiB
Markdown
119 lines
2.8 KiB
Markdown
---
|
|
id: pattern/intent-scope-purposes
|
|
title: Intent Scope Purposes Pattern
|
|
type: pattern
|
|
status: candidate
|
|
version: "0.1"
|
|
uses:
|
|
- model/purpose-demand-extension
|
|
- model/governance
|
|
- model/task
|
|
owned_concepts:
|
|
- IntentScopePurposePattern
|
|
---
|
|
|
|
# Intent Scope Purposes Pattern
|
|
|
|
## Context
|
|
|
|
A producer repo or infospace has its own reason to exist and a current boundary
|
|
of ownership. Consumers arrive with their own intents and use cases. Without a
|
|
purpose layer, the producer either ignores consumer demand or silently expands
|
|
scope through accidental commitments.
|
|
|
|
## Problem
|
|
|
|
Intent, scope, and purpose are often collapsed:
|
|
|
|
```text
|
|
consumer asks for something
|
|
producer treats it as a requirement
|
|
scope expands without governance
|
|
tasks appear without a decision trail
|
|
```
|
|
|
|
This makes repos less clean over time and hides why interfaces or standards are
|
|
evolving.
|
|
|
|
## Solution
|
|
|
|
Keep the three planes explicit.
|
|
|
|
```text
|
|
ProducerIntent
|
|
explains why the producer exists.
|
|
|
|
ProducerScope
|
|
declares what the producer currently owns, excludes, and promises.
|
|
|
|
ConsumerPurpose
|
|
declares what a consumer wants to use, need, or value from the producer,
|
|
anchored in the consumer's own intent.
|
|
```
|
|
|
|
Then connect them through reviewable fit and change decisions.
|
|
|
|
```text
|
|
ConsumerIntent
|
|
-> ConsumerPurpose
|
|
-> UseCase
|
|
-> DemandSignal
|
|
-> PurposeFit
|
|
-> ScopePressure
|
|
-> EvolutionRequest
|
|
-> GovernanceDecision
|
|
-> Task / ProfileChange / InterfaceChange / Mapping
|
|
```
|
|
|
|
## Pattern Rules
|
|
|
|
1. A ConsumerPurpose MUST identify the consumer and the consumer intent it is
|
|
anchored in.
|
|
2. A ConsumerPurpose SHOULD identify one or more use cases and demand signals.
|
|
3. A PurposeFit MUST distinguish current fit, fit through mapping, partial fit,
|
|
gap, conflict, and out-of-scope demand.
|
|
4. ScopePressure MUST NOT change producer scope by itself.
|
|
5. An EvolutionRequest SHOULD identify whether it proposes a task, mapping,
|
|
profile change, interface change, standard candidate, or explicit rejection.
|
|
6. Governance decisions SHOULD carry rationale and evidence.
|
|
|
|
## Resulting Moves
|
|
|
|
The pattern supports four clean moves:
|
|
|
|
```text
|
|
Learn
|
|
Capture consumer purpose and demand signals.
|
|
|
|
Evaluate
|
|
Compare purpose with producer scope and capabilities.
|
|
|
|
Govern
|
|
Accept, reject, defer, map, or convert pressure into an evolution request.
|
|
|
|
Implement
|
|
Create task work, profile changes, interface changes, mappings, or standards
|
|
only after the governance decision is explicit.
|
|
```
|
|
|
|
## Practical Interface
|
|
|
|
Consumer-facing interface cards should carry:
|
|
|
|
```text
|
|
consumer intent
|
|
consumer scope
|
|
consumer purposes
|
|
use cases
|
|
demand signals
|
|
needed concepts
|
|
producer capabilities used
|
|
purpose fit result
|
|
scope pressure
|
|
requested extensions
|
|
evidence references
|
|
```
|
|
|
|
This gives the producer a memory of why consumers use it and what they ask it
|
|
to become.
|