---
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.