info-tech-canon/infospace/patterns/intent-scope-purposes.md

id, title, type, status, version, uses, owned_concepts

id	title	type	status	version	uses	owned_concepts
pattern/intent-scope-purposes	Intent Scope Purposes Pattern	pattern	candidate	0.1	model/purpose-demand-extension model/governance model/task	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:

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.

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.

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:

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:

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.