6.7 KiB
id, title, type, status, version, extends, uses, owned_concepts
| id | title | type | status | version | extends | uses | owned_concepts | |||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| model/purpose-demand-extension | InfoTechCanon Purpose And Demand Model Extension | model-extension | candidate | 0.1 |
|
|
|
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:
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:
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
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:
accepted_for_analysis
needs_clarification
out_of_scope
duplicate
parked
rejected
Required evidence:
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:
fits_current_scope
fits_with_mapping
fits_with_profile
partial_fit
gap
conflict
out_of_scope
unknown
Required evidence:
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:
extend_scope
adapt_profile
add_mapping
add_interface_field
add_standard_candidate
create_task
defer
reject
Required evidence:
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.