Add purpose and demand model extension

infospace/models/governance/InfoTechCanonPurposeDemandExtension.md

@@ -0,0 +1,218 @@
+---
+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.