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