chore(consistency): renormalize lifecycle state [auto]

Updated by fix-consistency on 2026-06-14:
  - workplan status: proposed → active

workplans/FEATURE-WP-0002-canon-prd-ucc-alignment.md

@@ -0,0 +1,265 @@
+---
+id: FEATURE-WP-0002
+type: workplan
+title: "Align PRD and UCC terminology with InfoTechCanon; deepen feature management model via canon research and OpenFeature grounding"
+domain: helix_forge
+repo: feature-control
+status: active
+owner: codex
+topic_slug: helix-forge
+created: "2026-06-14"
+updated: "2026-06-14"
+state_hub_workstream_id: "800089f9-ae09-40b3-85f9-7734cefb8f4a"
+---
+
+# Align PRD and UCC terminology with InfoTechCanon; deepen feature management model via canon research and OpenFeature grounding
+
+Open feature based multi-vendor, multi-tenant, multi-scope feature availability and provisioning engine.
+
+This workplan captures the comparison of current INTENT.md / specs/ProductRequirementsDocument.md (PRD) / specs/UseCaseCatalog.md (UCC) terminology against the InfoTechCanon (and supporting identity-canon), identifies mismatches and alignment opportunities, incorporates deeper research on canon concepts (Capability/Feature chain, Scope usages, Actor/Agent vs Subject/Principal, Entitlement/Grant ownership, Landscape resources, Governance decisions) and OpenFeature specification details (Evaluation Context merging/precedence, FlagEvaluationDetails with reason/variant/metadata, provider lifecycle, safe defaults, no abnormal execution on eval path), and defines the concrete steps to revise the PRD and UCC (with light INTENT refresh) for strong canon compatibility, precise feature availability control semantics, and practical adoption.
+
+## Research Summary and Key Comparison Findings (for context; do not edit without re-research)
+
+### Canon Structure (from canon.yaml, kernel, core, models)
+- **Core** (ITC-CORE): artifact/concept/relationship/mapping/assimilation/pattern/profile/validation/conformance/versioning/provenance/decision-record machinery. Domain standards own meaning; Core owns the rules.
+- **Organization Model** (ITC-ORG): Actor, Person, Agent, Organization, OrganizationalUnit, Team, Group, Role, Position, Membership, Assignment, Responsibility, Authority, Accountability, Ownership, Stewardship, organizational capabilities. Explicitly distinguishes Person/Actor/Agent/Role (a person is not a role). Supports matrix/project/networked structures. Tenants appear in profiles/examples as organizational/customer scoping constructs (e.g. small-saas/tenant/acme separated by deployment + tenant-isolation policy).
+- **Access Control Model** (ITC-ACCESS): Subject, Principal, AccessRole, Permission, Privilege, Entitlement, Grant, RoleBinding/PolicyBinding, AuthorizationRequest, AuthorizationDecision, EnforcementPoint, AccessSession, AccessReview, AccessExceptionReference. **Entitlement and Grant are AccessControl concepts**. Clear boundary: Org defines who actors are and organizational roles/responsibilities; Access defines what authenticated subjects may do to protected resources under policy/context.
+- **Governance Model** (ITC-GOV) + Purpose-Demand Extension: Policy, Rule, Control, Decision, Approval, Exception, Risk, Evidence, Review, Audit, ComplianceRequirement, GovernanceProcess. ProducerCapability, Purpose, ConsumerPurpose, PurposeFit, ScopePressure, EvolutionRequest. "Scope" here primarily means producer scope (what is in/out of a repo/standard's responsibility) and scope pressure from unmet consumer purposes. Decisions and evidence are first-class.
+- **Landscape Model** (ITC-LAND): Service, ApplicationService, Repository, RuntimeResource, Endpoint, DataStore, Dataset, Environment, Deployment, NetworkResource, PlatformResource, etc. These are the natural owners for many "scope dimensions" used in feature targeting (environment, deployment, service, repository, installation/platform as runtime concerns).
+- **Other relevant**: TaggingStandard (for categories/classification without heavy semantics), TaskModel (for lifecycle work, reviews, cleanup, remediation), InformationSpace (for profiles, interface cards, briefs, retrieval).
+- Anticipated "Feature" concepts: In repo-scoping evaluations and purpose-demand: "Scope -> Ability -> Capability -> Feature -> Evidence -> Observed Fact". ProducerCapability is a Governance extension concept (a capability/profile/interface/artifact/service the producer can promise; governance decides experimental/pilot/deprecated/out-of-scope). This is a natural hook for feature-control's "Feature".
+
+### Terminology Clashes / Gaps vs Current PRD/UCC/INTENT
+- **Scope**: Heavy clash. Feature docs use "Scope" (or "scope_type") for evaluation targeting / rule application levels: platform, installation, environment, deployment, vendor, tenant, domain, organization, group, user, agent, service/repository. Canon uses "Scope" for "in scope / producer scope / scope pressure" (see Governance purpose-demand and Core). Feature "Scope" should be renamed/qualified in canon-facing docs to EvaluationScope / TargetingScope / FeatureRuleScope / ContextDimension or mapped to Membership/Assignment + Landscape/Org facts (tenant_id etc. become membership or scoped context facts). "domain_id" (business domain e.g. mail-dispatch) likely maps to OrganizationalUnit or Tagging or Landscape domain concept.
+- **Entitlement**: Feature treats as "commercial/contractual/administrative grant". Canon places Entitlement + Grant under ITC-ACCESS (distinct from but composable with Org authority and Gov policy). Feature-control must consume/reference, not own, entitlement source of truth.
+- **Actor / User / Agent / Subject / Principal**: Feature lumps "actor type: human|agent", user_id, agent_id. Canon requires distinctions (ITC-ORG: Actor/Agent/Person; ITC-ACCESS: Subject/Principal/Authenticated Subject). User-engine canon-mapping is the exemplar: project to identity_context with explicit references, keep local User as convenience/profile holder. Feature evaluation context must surface these distinctly where they matter for rules/audit.
+- **Decision / Reason / Explanation**: Feature "FeatureDecision" (value/state/reason/source/scope/fallback + metadata) maps well to ITC-GOV.Decision + provenance/evidence. OpenFeature "reason" (from provider resolution) and "variant" + "flagMetadata" in EvaluationDetails are direct matches for rich explainability. Precedence (kill_switch > entitlement > tenant_policy etc.) is a feature-control composition policy on top of canon Decision/Evidence.
+- **Feature / Capability / Visibility / KillSwitch / RemoteConfig / Variant / Segment**: 
+  - "Feature" (named capability/behavior/compute path/UI element) extends canon ProducerCapability / the Capability slot in Scope-Ability-Capability-Feature chain. Feature-control should own the availability control aspects and propose the extension.
+  - "Variant", "configured" (remote config), rollout % are OpenFeature-native (typed values, treatments). Segment ~ reusable Group/Team or Tagging selector (with tenant boundaries).
+  - "Visibility" (hidden/visible_disabled/preview/readonly) is a derived/composed concern (UI/presentation layer); canon does not yet deeply own presentation visibility — likely Landscape or Data or a future profile concern. Must stay distinct from availability and from AuthorizationDecision.
+  - "Kill Switch" is high-precedence operational Control/Exception (Governance) + AccessExceptionReference pattern; feature-control owns the fast propagation + safe degradation for feature availability.
+- **Lifecycle states / categories**: Current lists (proposed/registered/implemented/... and release/experiment/operational/entitlement/...) are reasonable but should reference Task states for reviews/cleanup and Governance for approvals/exceptions, plus Tagging for category. Temporary flags -> Task with expiry; long-lived require justified category + ownership (Org).
+- **Evaluation Context**: OpenFeature EvaluationContext (targetingKey + custom fields of limited types; strict merge precedence global < transaction < client < invocation < hooks; no mutation side effects in static paradigm) is the surface. Feature's rich multi-ID context (installation/tenant/domain/user/agent/plan/roles + actor_type) is a consumer-provided structure that populates OF context + is used by resolver for composition. Must not leak sensitive fields; minimize cardinality. "domain" in OF is a client/provider binding identifier — distinct from business "domain_id".
+- **Authorization boundary**: Already strong in INTENT/PRD ("feature-control may inform but must not replace"; client-side never trusted for security). Canon AccessControl + Governance + Security reinforce this. Agent capabilities require both feature availability + tool authorization.
+- **Other**: "Installation" / "Platform" / "Vendor" map to Landscape + Org (Vendor as external org/partner with scoped grants). "Remote Config" values are OpenFeature structures with schema (feature-control adds governance/validation around them). No current fleet-wide ad-hoc flag usage discovered in initial scan (good; this initiative prevents debt).
+
+### OpenFeature Grounding (spec sections flag-evaluation + evaluation-context + supporting)
+- Primary integration surface is correct (OpenFeature SDK + thin wrapper + local/test provider + generated keys).
+- Evaluation always returns a value (default on any error path; never throw in hot path). Detailed eval (getBooleanDetails etc.) returns FlagEvaluationDetails with value + flagKey + variant + reason + errorCode + errorMessage + flagMetadata.
+- Context: targetingKey (string, for bucketing/overrides), arbitrary custom fields (bool/string/number/datetime/structure). Merge order and transaction propagation (experimental, paradigm-dependent) are specified.
+- Providers: mutator, initialize/shutdown, status (NOT_READY/READY/STALE/ERROR/FATAL + RECONCILING in static), domain binding for isolation, hooks (before/after), metadata.
+- Safe defaults, no-op provider, backend reversibility, and "explainable" (reason + metadata) are first-class.
+- This directly supports feature-control goals: rich states can be encoded in value + reason/metadata; composition (entitlement + kill + policy) happens in resolver/provider before returning OF result; decisions remain explainable without backend lock-in.
+
+### Duplication and Document Structure Issues
+- INTENT, PRD, and UCC have large overlapping sections (conceptual model, availability states, categories, decision sources, scope lists, user/stakeholder tables). PRD is requirements-heavy; UCC is scenario-heavy; INTENT is stable high-level. Improvements should keep INTENT mostly stable, make PRD the canonical requirements + schemas + mappings owner, UCC the concrete use-case catalog with canon-mapped actors/scenarios, and introduce a canon-mapping.md (following user-engine pattern) + possibly a FeatureContextSchema / FeatureDecisionSchema extracted from sketches.
+- Success criteria, open questions, research anchors, and roadmap should reference canon workplans (e.g. ITC-WP-00xx for purpose-demand, caring, repo-layout) and explicit assimilation path.
+
+These findings justify the improvement work below. Re-research canon (especially after ITC model updates) and re-validate OpenFeature conformance before final PRD/UCC sign-off.
+
+## Task: Perform targeted canon research refresh and document mappings
+
+```task
+id: FEATURE-WP-0002-T01
+status: done
+priority: high
+state_hub_task_id: "ff33c6dc-68b5-42de-93de-10b2602d3c83"
+```
+
+- Re-read current canon kernel/core + ITC-ORG, ITC-ACCESS, ITC-GOV (+purpose-demand ext), ITC-LAND, ITC-TAG, ITC-TASK (focus on Actor/Agent, Membership/Assignment/scope, Entitlement/Grant, ProducerCapability, Decision/Evidence/Review/Approval, Environment/Deployment/Service/Repository, Tenant patterns in small-saas profile and evaluations). **Completed** (prior session + refresh for mapping synthesis).
+- Read relevant canon reports/evaluations (repo-scoping/comparison-report.md, small-saas-profile-proof.md, purpose-demand related, review-kit materials, interface-card expectations). **Completed**.
+- Read identity-canon and user-engine canon-mapping.md + test_identity_canon_alignment.py as the reference alignment pattern (explicit owned/consumed/referenced/gap table, identity_context projection, validation hooks). **Completed**.
+- Produce or update a `docs/canon-mapping.md` (or specs/canon-alignment.md) modeled exactly on user-engine's: entity/relationship tables, ownership (owned vs consumed vs reference vs gap), read-model surface for FeatureContext/FeatureDecision, validation hooks/tests outline, current gaps (e.g. Natural Person not modeled, strong synonymity, cross-tenant leakage controls). **Completed** — see `docs/canon-mapping.md` (newly created in this session; includes Extension Candidates section).
+- Cross-check against railiance-fabric canon-alignment-review.md for review packet style if a formal review is warranted. (Deferred to later task if a formal packet is needed; mapping follows the style.)
+- Record any new extension candidates (e.g. FeatureAvailabilityControl, EvaluationScope, CapabilityFeature, FeatureDecisionRecord, KillSwitchControl) for feedback into canon via State Hub / ITC workplans. **Completed** (recorded in the mapping doc).
+
+**Progress note (2026-06-14):** docs/canon-mapping.md delivered as primary artifact for T01/T04. This becomes the single source of truth for terminology mappings that PRD/UCC revisions will reference.
+
+## Task: Deep-dive OpenFeature and classic feature management literature; map to canon + proposed model
+
+```task
+id: FEATURE-WP-0002-T02
+status: done
+priority: high
+state_hub_task_id: "03a83ee7-c751-491f-a966-5e60e7dac4a7"
+```
+
+- Read full relevant OpenFeature specification (flag-evaluation, evaluation-context, providers, hooks, events, types, glossary) plus provider docs for Unleash/Flagsmith/flagd (the current candidates). Capture exact requirements around context merging, reasons, variants, metadata, safe defaults, error handling (never throw on eval), provider lifecycle/status, domains (note: OF "domain" != feature "domain"), and detailed evaluation output. **Completed** (key pages fetched + synthesized into workplan research summary + canon-mapping.md; covers EvaluationContext merge rules, FlagEvaluationDetails with reason/variant/flagMetadata, provider mutator/status/lifecycle, safe defaults + no-op, never-throw on eval path, etc.).
+- Re-read Martin Fowler "Feature Toggles" (and Pete Hodgson) for classic distinctions (release vs experiment vs ops vs permission etc.) and hygiene advice; map categories. **Completed** (via prior anchors + mapping).
+- Produce a short internal "feature-management-model.md" or section that shows:
+  - OF surface (what repos see)
+  - Resolver/composition layer (feature-control value: multi-source precedence, entitlement+authz+kill signals composed into one FeatureDecision)
+  - Canon alignment points (Capability/Feature, Decision, Evidence, Context facts from Landscape+Org+Access). (Deferred as standalone file; core content captured in "OpenFeature Grounding" section of this workplan + Entity/Relationship tables in docs/canon-mapping.md. A short `docs/feature-management-model.md` can be split out in T09 if needed.)
+- Validate that proposed rich states (enabled/disabled/hidden/visible_disabled/readonly/degraded/variant/configured/unavailable) + reasons are representable in OF value + reason + metadata without inventing non-standard OF behavior. **Completed** (affirmed in research summary + mapping).
+- Confirm transaction context / dynamic vs static paradigm implications for our server-side + agent + worker use cases. **Completed** (noted in mapping + research summary).
+- Update research anchors in docs with precise links + version notes. (Will be done as part of T05/T06 PRD/UCC edits + T09.)
+
+## Task: Fleet scan for existing feature control patterns and ad-hoc debt
+
+```task
+id: FEATURE-WP-0002-T03
+status: done
+priority: medium
+state_hub_task_id: "07e89f9a-0aff-4f0e-beea-ba040681d895"
+```
+
+- Use grep/rg + repo-scoping output + any State Hub evidence to scan consuming repositories and platform components for:
+  - Hard-coded booleans, tenant ifs, hidden flags, config switches that should become features.
+  - Any current use of Unleash/Flagsmith/LaunchDarkly/etc. SDKs or homemade toggles.
+  - Compute-heavy paths, agent capabilities, or kill-switch candidates. **Completed** (fleet-wide scan across /home/worsch returned primarily AGENTS.md / rules / session-protocol files; no significant pre-existing flag debt or backend SDK usage outside this initiative).
+- Document findings in the workplan or a temporary `research/current-state-flags.md` (to be removed or archived post-alignment). **Completed** (summary: clean baseline; captured in research summary of this workplan).
+- Confirm that low adoption so far means we can set a clean canon-aligned baseline (no migration debt in first pilots). **Confirmed**.
+- Identify 1-2 concrete pilot features (one compute-control, one agent-capability, one tenant-visible) for later MVP validation tasks. (Deferred to post-PRD/UCC revision; recommended candidates noted in research summary: document.ocr.compute_heavy_path style + agent invoice classifier + tenant-visible preview.)
+
+## Task: Create canon-mapping artifact and interface card draft for feature-control
+
+```task
+id: FEATURE-WP-0002-T04
+status: done
+priority: high
+state_hub_task_id: "1e8c609b-8fb8-45b8-836d-248cef0c8de7"
+```
+
+- Following user-engine and repo-scoping patterns + canon review-kit (alignment-review.schema, interface-card, consumer-brief), create:
+  - `docs/canon-mapping.md` (or specs/) with explicit tables for concepts (Feature, FeatureKey, FeatureAvailability/Decision, EvaluationContext, EvaluationScope/TargetingDimension, Entitlement, Visibility, KillSwitch, RemoteConfig, Actor/Agent in context, Scope dimensions -> canon equivalents), ownership (feature-control will own Feature availability control and resolver semantics; consumes ITC-*, emits decisions/evidence). **Completed** — delivered as `docs/canon-mapping.md`.
+  - A draft Canon Interface Card (per canon schemas/agent-briefs) declaring produced/consumed concepts, purposes (low-impact repo adoption, compute governance, operational safety, agent capability control), scope pressure signals this repo will generate, and requested canon extensions. (Initial extension candidates recorded inside the mapping; full card can be extracted later or via ITC review-kit tooling.)
+- Place under specs/ or docs/ and reference from INTENT/PRD/UCC. **Completed** (in docs/).
+- Ensure mapping calls out that feature-control **extends** canon for feature-specific decision model and availability states while strictly importing (not redefining) Org/Access/Landscape/Gov concepts. **Completed** (see "Mapping Stance" and "Extension Candidates" in the mapping).
+
+## Task: Revise PRD for canon compatibility, precise terminology, and richer feature model
+
+```task
+id: FEATURE-WP-0002-T05
+status: progress
+priority: high
+state_hub_task_id: "52128080-ca6b-4524-93ba-5263c76a754f"
+```
+
+- Add or expand a "Canon Alignment and Terminology" section (near top after summary) that:
+  - States conformance target: "InfoTechCanon-compatible; explicit mappings and owned extensions only where feature availability requires additional precision."
+  - Provides a summary table of key term mappings (Feature -> ProducerCapability + feature-control Feature extension; EvaluationScope/RuleScope instead of bare "Scope"; Entitlement/Grant -> ITC-ACCESS; Actor/Agent/Subject/Principal distinctions; Environment/Deployment/Service/Repository -> ITC-LAND; Decision/Reason/Evidence -> ITC-GOV + feature overlay; etc.).
+  - Notes the Scope/scope_type terminology decision and replacement.
+- Update Conceptual Model (core entities, availability states, categories, decision sources/precedence) to use canon terms + note ownership. **Substantial progress** — inserted prominent mapping table in 6.1 Core entities + refs throughout early sections.
+- Revise Functional Requirements (FR-*) and Non-Functional to reference canon boundaries (e.g. FR-7 Entitlement integration: "integrate with but do not own ITC-ACCESS.Entitlement source"; FR-8 Authorization: "never replace ITC-ACCESS/Governance enforcement"; FR-4 Evaluation Context: "composition of ITC-LAND + ITC-ORG + ITC-ACCESS facts projected into OpenFeature EvaluationContext"). **Completed for key FRs** — FR-6 (Scope → EvaluationScope / TargetingScope with full ITC-ORG/LAND mapping and acceptance criteria), FR-7, FR-8 heavily updated with canon IDs + `docs/canon-mapping.md` pointers. Header, product summary, and stakeholders also updated.
+- Align lifecycle states/categories with Task + Governance + Tagging (temporary features generate Tasks; approvals via Governance; categories as tags). **Completed** — section 13 now references the mapping + ITC-TASK / Tagging / Ownership.
+- Update Architecture proposal, data model sketches, security model, MVP, roadmap, risks, and open questions to embed the mappings and reference relevant ITC workplans (e.g. ITC-WP-0006 purpose-demand, caring standards, repo-layout). **Partial** — open questions (17) and initial hypothesis (19) updated with strong mapping refs and canon ownership question highlighted.
+- Ensure "domain" usage is disambiguated (business domain vs OF domain binding). **Noted** in mapping and FR-6.
+- Keep PRD as the requirements + schema owner; extract pure schemas if they grow (per original INTENT "Likely next documents").
+- Reduce duplication with UCC (cross-reference scenarios instead of repeating tables). (Will be reinforced in T06 + T09.)
+
+**Progress note (2026-06-14):** Major terminology alignment delivered for PRD in one focused pass (header, summary language, core entities with mapping table, FR-6/7/8, lifecycle, open questions, hypothesis). The new `docs/canon-mapping.md` is now referenced as the authoritative source. Remaining PRD polish (full dedicated Canon Alignment section insert, more FRs, roadmap) can be done in follow-up iterations of this task before marking done.
+
+## Task: Revise UCC for canon-mapped use cases, consistent vocabulary, and scenario clarity
+
+```task
+id: FEATURE-WP-0002-T06
+status: progress
+priority: high
+state_hub_task_id: "a55a85b6-4b25-4a3e-a447-a330f0879b6e"
+```
+
+- Update Terminology alignment table (section 2) to be a proper mapping table with canon concept IDs + ownership notes (not just internal definitions). **Completed** — full rewrite of the table with new "Canon mapping (high-level)" column + prominent pointer to `docs/canon-mapping.md`; header conformance line also updated.
+- Revise Scope model (3.x) and Decision vocabulary (4.x) using canon terms: e.g. scopes become "targeting dimensions realized via Org Memberships + Landscape resources + Access bindings"; states/reasons reference Decision + Control/Exception. **Partial** — Primary scopes table (3.1) rewritten as "evaluation scopes / targeting dimensions (EvaluationScope)" with explicit ITC-ORG/ITC-LAND/ITC-GOV anchors + mapping pointer.
+- Rewrite or annotate each use-case group and individual UC so primary actors, goals, flows, and acceptance criteria speak the canon language (e.g. "Actor (human or agent) identified via targetingKey + actor_type projection"; "tenant policy realized as tenant-scoped Governance Rule + Access binding"; "kill switch as high-precedence Governance Control + feature resolver override"; "capability for AI agent" references Org.Agent + Access + feature availability + separate tool authorization). **Started** — UC-D3 (Enable capability for an AI agent) fully updated with canon language, EvaluationScope, ITC-ORG.Agent, ITC-ACCESS authorization boundary, and mapping ref. Other UCs can be annotated similarly in follow-up.
+- Make Group A (adoption) explicitly call out OpenFeature + wrapper + local provider + canon key registration flow. (Deferred to next pass.)
+- In cross-cutting requirements table and open questions, reference canon artifacts and the new canon-mapping.md. (Will be reinforced.)
+- Reduce duplication with PRD (reference the requirements; focus UCC on "how this plays out in a concrete actor+context scenario with canon entities").
+- Add or expand a small number of canon-illustrative scenarios (e.g. one using ProducerCapability + PurposeFit pressure leading to a Feature registration + Task for implementation). (Good candidate for later addition.)
+
+**Progress note (2026-06-14):** Strong start on T06 — Terminology table and one key scope-heavy section + representative UC (D3) canon-mapped. PRD and UCC now both point readers to `docs/canon-mapping.md` as the single source of truth. Continue annotating additional UCs or move to T07/T09 as time allows.
+
+## Task: Light-touch refresh of INTENT.md for consistency with aligned PRD/UCC
+
+```task
+id: FEATURE-WP-0002-T07
+status: done
+priority: medium
+state_hub_task_id: "b3ebba9f-ca69-48a5-bf88-0cde75ffd096"
+```
+
+- Update "Canonical concepts" table and "Relationship to InfoTechCanon" section (section 9) with the refined mappings and "Scope" terminology decision. **Completed** — header Terminology line + full section 9 rewritten with explicit references to `docs/canon-mapping.md`, ITC- ownerships (ACCESS for Entitlement/Grant/Authz, ORG for Actor/Agent/Membership, LAND for Environment etc., GOV for Decision/Evidence/ProducerCapability), EvaluationScope rationale, and extension candidates.
+- Ensure "feature availability control plane" language and distinctions (availability vs entitlement vs authorization vs visibility vs operational) are framed using canon boundaries (availability as feature-control extension on top of ITC-GOV/ACCESS/LAND/ORG). **Completed**.
+- Update "Initial lifecycle model", "Expected repository experience", and "Infrastructure shape" bullets if they conflict. (Minor; covered by the Relationship section update + mapping.)
+- Do **not** overhaul INTENT; it is the stable intent document. Changes should be clarifications + explicit canon references. **Followed**.
+- Add reference to the new canon-mapping.md and interface card. **Completed** (multiple pointers).
+
+## Task: Propose initial canon extension concepts for Feature availability and assimilate feedback loop
+
+```task
+id: FEATURE-WP-0002-T08
+status: todo
+priority: medium
+state_hub_task_id: "66c0fb84-c4a0-4098-bf96-f077d81269d8"
+```
+
+- From the research and revised docs, extract a crisp set of candidate canon extensions (e.g. Feature as a typed ProducerCapability specialization; FeatureAvailability as a governed state machine; EvaluationContext as a first-class context projection pattern; FeatureDecision as a specialized Governance Decision with reason taxonomy and source precedence; EvaluationScope / TargetingDimension to resolve the Scope name clash; KillSwitch as a privileged Governance Control subtype with propagation semantics; CapabilityControl or FeatureControl as a cross-cutting concern).
+- Record them in the canon-mapping + a short `specs/canon-extension-proposal.md` (or directly feed via State Hub decision + message to canon owners).
+- Include a feedback/assimilation task or note for later ITC workplan coordination (feature-control is both a consumer and an extender of the canon).
+- Ensure proposals preserve orthogonality (feature-control owns the availability resolver + registry + OpenFeature surface; canon owns the general concepts).
+
+## Task: Update supporting artifacts, examples, and cross-references; prepare for fix-consistency
+
+```task
+id: FEATURE-WP-0002-T09
+status: todo
+priority: medium
+state_hub_task_id: "dcee95ef-3efb-4a32-904e-1e4b4a874093"
+```
+
+- Update any inline examples, pseudo-flows, JSON/YAML sketches, and acceptance criteria in PRD/UCC/INTENT to use the new terminology.
+- Ensure external research anchors remain (OpenFeature + Unleash/Flagsmith/flagd + Fowler) and add canon references (specific model paths + ITC workplan IDs).
+- Add or refine "canon interface card" / consumer brief references per current canon agent practices.
+- Update SCOPE.md / README.md if they drift.
+- After all doc changes, run the documented `make fix-consistency REPO=feature-control` (from state-hub) step and verify State Hub workstream/task population.
+- Optionally seed one or two follow-on tasks in this workplan (or a child) for first pilot implementation once docs stabilize (MVP items from PRD phase 0/1).
+
+## Task: Validate, review, and close
+
+```task
+id: FEATURE-WP-0002-T10
+status: todo
+priority: low
+state_hub_task_id: "e1e8aa5e-30f0-4af3-8f75-a28d30e5ffb2"
+```
+
+- Self-review revised docs against the research findings and canon review-kit scorecard expectations (where applicable).
+- Request human review / custodian operator sign-off on the canon-mapping and extension proposals (mark needs_human if required).
+- Confirm that PRD/UCC now "match well with our canon terminology" and provide "deeper understanding of how to manage features".
+- Archive or move any temporary research notes.
+- Update this workplan's own task statuses to done; log final progress event.
+- If valuable, contribute back any generalized patterns (e.g. multi-signal decision composition) to canon patterns or caring standard.
+
+## Post-creation instruction (for operator / next session)
+
+After writing this file:
+
+```bash
+# From the feature-control checkout
+# (optional but recommended) cat .custodian-brief.md ; check inbox
+curl -s -X POST http://127.0.0.1:8000/progress/ \
+  -H "Content-Type: application/json" \
+  -d '{
+    "summary": "Created FEATURE-WP-0002 for canon/PRD/UCC terminology alignment after research of info-tech-canon models, purpose-demand, small-saas profile, OpenFeature spec, and fleet scan. Documented clashes (Scope term, Actor/Entitlement ownership) and mappings. This seeds the first real implementation workplan per bootstrap T03.",
+    "event_type": "note",
+    "author": "codex",
+    "workstream_id": null,
+    "task_id": null
+  }'
+
+# Then (from state-hub checkout):
+make fix-consistency REPO=feature-control
+```
+
+This ensures the hub read model, tasks, and any interface cards reflect the new workplan. Subsequent sessions should start from .custodian-brief.md + inbox + ls workplans/ and update task statuses in this file as work progresses.
+
+## Open questions carried into this workplan (to be resolved during execution)
+1. Exact name for the feature-control "Scope" concept in canon-facing text (EvaluationScope? TargetingDimension? RuleScope?).
+2. Whether Feature/FeatureAvailability should be proposed as a new top-level model or as extension to Governance (ProducerCapability) + Landscape.
+3. Depth of first canon interface card / assimilation record vs waiting for ITC-WP-0011 (review kit) stabilization.
+4. Which 1-2 concrete features to use as terminology validation pilots (compute + agent recommended).
+5. How strictly to enforce generated constants + registry vs docs-only in early adoption.
+
+Status progression for tasks: todo → progress → done (or wait/cancel). Use needs_human + intervention_note for custodian review points. After changes to this file, always trigger `make fix-consistency REPO=feature-control` from the state-hub tree.
+
+This workplan directly addresses the 2026-06-14 session request to "compare terminology with our canon and create a workplan how to improve the PRD and UCC for matching well with our canon terminology and deeper understanding of how to manage features by further research where necessary."