generated from coulomb/repo-seed
219 lines
6.7 KiB
Markdown
219 lines
6.7 KiB
Markdown
---
|
|
id: model/purpose-demand-extension
|
|
title: InfoTechCanon Purpose And Demand Model Extension
|
|
type: model-extension
|
|
status: candidate
|
|
version: "0.1"
|
|
extends:
|
|
- model/governance
|
|
uses:
|
|
- kernel/itc-core
|
|
- model/information-space
|
|
- model/task
|
|
owned_concepts:
|
|
- Purpose
|
|
- ConsumerPurpose
|
|
- UseCase
|
|
- DemandSignal
|
|
- ConsumerNeed
|
|
- ProducerCapability
|
|
- PurposeFit
|
|
- ScopePressure
|
|
- EvolutionRequest
|
|
---
|
|
|
|
# InfoTechCanon Purpose And Demand Model Extension
|
|
|
|
## 1. Purpose
|
|
|
|
This candidate extension defines the PURPOSES concept family for repos and
|
|
infospaces that need to learn what consumers use, need, want, and value from
|
|
the producer.
|
|
|
|
The extension keeps three ideas distinct:
|
|
|
|
```text
|
|
INTENT
|
|
Why a producer or consumer exists and what it is trying to become.
|
|
|
|
SCOPE
|
|
What the producer currently includes, excludes, owns, and promises.
|
|
|
|
PURPOSES
|
|
What consumers use, need, want, or value from the producer, anchored in the
|
|
consumers' own intent.
|
|
```
|
|
|
|
PURPOSES are not a replacement for producer intent or scope. They are a
|
|
consumer demand surface that can inform governance, profiles, interfaces, and
|
|
roadmap work.
|
|
|
|
## 2. Position in InfoTechCanon
|
|
|
|
Purpose and demand currently cross several existing model boundaries:
|
|
|
|
```text
|
|
Core
|
|
Owns generic canon primitives such as Concept, Standard, Profile, Mapping,
|
|
Conformance, and canonical ownership.
|
|
|
|
Governance
|
|
Owns decisions, decision rights, evidence, acceptance, deferral, rejection,
|
|
change control, and the evaluation of scope pressure.
|
|
|
|
Information Space
|
|
Owns how consumer purposes, interface cards, briefs, mappings, evidence
|
|
references, and retrieval assets are captured and reused.
|
|
|
|
Task
|
|
Owns work items created from accepted evolution requests, including backlog,
|
|
readiness, commitment, progress, and completion evidence.
|
|
```
|
|
|
|
This extension is intentionally registered as a candidate model extension until
|
|
the concepts are exercised by the first consumer evaluations.
|
|
|
|
## 3. Concept Proposal
|
|
|
|
| Concept | Proposed permanent owner | Definition | Notes |
|
|
| --- | --- | --- | --- |
|
|
| Purpose | Core | A reason or use-value orientation that explains why an actor, artifact, capability, or repo matters in a context. | Generic enough to become a core concept, but introduced here as a candidate. |
|
|
| ConsumerPurpose | Information Space | A declared purpose from a consumer of a producer repo, artifact, profile, service, or canon surface. | Captured through interface cards, consumer briefs, mappings, and evidence references. |
|
|
| UseCase | Information Space | A bounded scenario in which a consumer applies a producer capability to satisfy a purpose. | Should remain distinct from Task; tasks implement changes, use cases describe demand. |
|
|
| DemandSignal | Information Space | A traceable observation that indicates consumer need, use, friction, request, value, or preference. | Examples include evaluation gaps, repeated questions, integration attempts, issues, and usage evidence. |
|
|
| ConsumerNeed | Information Space | A need expressed or inferred from a consumer purpose and one or more demand signals. | Needs may be current, anticipated, or exploratory. |
|
|
| ProducerCapability | Governance | A capability, profile, interface, artifact, or service the producer can intentionally provide or promise. | Governance decides whether it is promised, experimental, deprecated, or out of scope. |
|
|
| PurposeFit | Governance | An evaluation of how well producer scope and capabilities satisfy a consumer purpose. | Requires rationale and evidence because it can drive scope change. |
|
|
| ScopePressure | Governance | Pressure on producer scope caused by unmet, repeated, high-value, or strategically aligned consumer purposes. | Should not automatically expand scope; it triggers governance review. |
|
|
| EvolutionRequest | Task | A proposed change to producer artifacts, interfaces, profiles, standards, or scope created in response to purpose pressure. | Becomes Task work only after triage and commitment. |
|
|
|
|
## 4. Core Relationships
|
|
|
|
```text
|
|
ConsumerPurpose anchored_in ConsumerIntent
|
|
ConsumerPurpose expresses UseCase
|
|
UseCase creates DemandSignal
|
|
DemandSignal indicates ConsumerNeed
|
|
ProducerCapability satisfies ConsumerNeed
|
|
PurposeFit evaluates ConsumerPurpose against ProducerCapability and Scope
|
|
ScopePressure arises_from PurposeFit or DemandSignal
|
|
EvolutionRequest responds_to ScopePressure
|
|
Decision accepts / rejects / defers EvolutionRequest
|
|
Task implements accepted EvolutionRequest
|
|
Evidence supports PurposeFit and Decision
|
|
```
|
|
|
|
## 5. Governance Extension Candidates
|
|
|
|
Governance should gain three reviewable decision surfaces.
|
|
|
|
### 5.1 Consumer Purpose Triage
|
|
|
|
Purpose triage decides whether a declared consumer purpose is:
|
|
|
|
```text
|
|
accepted_for_analysis
|
|
needs_clarification
|
|
out_of_scope
|
|
duplicate
|
|
parked
|
|
rejected
|
|
```
|
|
|
|
Required evidence:
|
|
|
|
```text
|
|
consumer identity
|
|
consumer intent
|
|
declared purpose
|
|
use case
|
|
scope touched
|
|
source artifact or interface card
|
|
date captured
|
|
owner for follow-up
|
|
```
|
|
|
|
### 5.2 Purpose Fit Review
|
|
|
|
Purpose fit review evaluates whether the canon currently satisfies the
|
|
consumer purpose.
|
|
|
|
Fit states:
|
|
|
|
```text
|
|
fits_current_scope
|
|
fits_with_mapping
|
|
fits_with_profile
|
|
partial_fit
|
|
gap
|
|
conflict
|
|
out_of_scope
|
|
unknown
|
|
```
|
|
|
|
Required evidence:
|
|
|
|
```text
|
|
matched canon artifacts
|
|
matched concepts
|
|
gaps or ambiguity
|
|
consumer impact
|
|
producer impact
|
|
recommended disposition
|
|
```
|
|
|
|
### 5.3 Scope Pressure Decision
|
|
|
|
Scope pressure decision decides whether repeated or high-value purposes should
|
|
change the producer.
|
|
|
|
Outcomes:
|
|
|
|
```text
|
|
extend_scope
|
|
adapt_profile
|
|
add_mapping
|
|
add_interface_field
|
|
add_standard_candidate
|
|
create_task
|
|
defer
|
|
reject
|
|
```
|
|
|
|
Required evidence:
|
|
|
|
```text
|
|
purpose fit result
|
|
demand signal strength
|
|
alignment with producer intent
|
|
cost or complexity
|
|
affected owner
|
|
decision authority
|
|
review date
|
|
```
|
|
|
|
## 6. Boundaries
|
|
|
|
Purpose is not Policy. A purpose can inform policy, but policy remains a
|
|
governance directive.
|
|
|
|
Purpose is not Scope. Purpose can pressure scope, but scope remains the
|
|
producer's current boundary and promise.
|
|
|
|
Purpose is not Task. Purpose can create work, but task semantics begin when
|
|
work is captured, triaged, committed, assigned, and executed.
|
|
|
|
Purpose is not Capability. A consumer may need something the producer does not
|
|
yet provide, does not want to provide, or should explicitly reject.
|
|
|
|
## 7. First Consumer Evaluation Use
|
|
|
|
The first evaluations should use the purpose model to capture:
|
|
|
|
- what user-engine needs from the canon before user-management integration,
|
|
- what railiance-fabric needs for clean entity and edge capture,
|
|
- what repo-scoping needs from INTENT, SCOPE, PURPOSES, and interface cards.
|
|
|
|
Those evaluations should create consumer-side workplans in the consumer repos.
|
|
This repo owns the canon-side model, examples, and acceptance vocabulary.
|