diff --git a/STUDIO_GLOSSARY.md b/STUDIO_GLOSSARY.md
new file mode 100644
index 0000000..91943e3
--- /dev/null
+++ b/STUDIO_GLOSSARY.md
@@ -0,0 +1,334 @@
+---
+type: foundation
+artifact: glossary
+status: draft-v0.2.32
+date: 2026-07-09
+tags:
+ - studio
+ - glossary
+ - terminology
+ - foundations
+---
+
+# Studio — Glossary of Terms (v0.2.32)
+
+**What this is.** A shared dictionary for everyone building Constructor Studio — Product, Design, R&D, GTM. One canonical term per concept, with a short definition and where it comes from. Use it to settle "what do we call this?" **before** the term hardens into the UI.
+
+**Studio in one line:** an AI-native, open-core **control plane** that mirrors a team's existing SDLC tools into one governed graph and moves work forward with **validated, human-approved actions** — across the wider **Software Construction Lifecycle** (intent → build → operate → evolve), not just coding.
+
+**How to read this table**
+
+| Column | Meaning |
+|---|---|
+| **Canonical** | The one term we use everywhere (UI, docs, scenarios). |
+| **Definition** | Short, shared definition. |
+| **Source** | Where the authoritative definition comes from: a `Vision §…` section of STUDIO_VISION.md, or a formal standard it follows (ISO/IEC/IEEE, NIST). **Blank = defined in our own foundations work** (not upstream). Industry analogies ("this is like X") are **not** sources and are not listed here. |
+| **Aliases** | Other names for the same thing found across the docs — do **not** use these in new work; they map to the canonical term. |
+| **Status** | `agreed` (settled) · `proposed` (candidate, not yet ratified) · `deprecated` (don't use) · `conflict` (unresolved — needs a naming decision). |
+
+**Canonical source (primary, pending ratification): `STUDIO_VISION.md` (the updated vision) is the primary source of truth.** It **wins** over the other vision docs, the merge deck, and the marketecture. Definitions in this v0.2 were re-checked against the updated vision.
+
+> **Two things stated up front (for the reader):** (a) **every *active* term is `proposed`** — nothing is ratified yet, so the Status column signals *maturity*, not disagreement; only *rejected* terms are `deprecated`. Ratification waits on the Factory sync (see Open questions). (b) the tables are wide — **scan Canonical + Definition first**, and treat Source / Aliases / Status as reference.
+
+---
+
+## 0. Product & umbrella
+
+| Canonical | Definition | Source | Aliases | Status |
+| ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------- | -------------------------------------------------------------------- | -------------------------------------------------------- |
+| **Constructor Studio** | AI-native software-**construction** workspace; an open-core control plane over existing SDLC tools. | Vision §1, §13 | Studio | proposed |
+| **Constructor Fabric** | The umbrella platform; Studio is one of its **3** elements — the others are **Constructor Insight** and **Constructor Gears**. | Vision §1, §11 | Fabric | proposed |
+| **Open-core** | The business + architecture model: the **core** (control-plane graph, actions, validators, connectors, SDKs, base SDLC Kit) is open-source; **proprietary** parts (HypoFinder Kit, enterprise/private deployment, premium connector/kit/benchmark packs) are paid. No vendor lock-in. | Vision §13 | open core | proposed |
+| **Control Plane** | Studio's role: it **governs / orchestrates** existing tools rather than being the system of record. | Vision §13 | open-core control plane | proposed |
+| **Constructor Insight** | The connector + analytics + benchmarking layer that feeds cross-vendor data into Studio. | Vision §11.1 | Insight | proposed |
+| **Constructor Gears** | The Fabric element that supplies reusable OSS/BSS building-block modules; these are packaged into Kits (see **Gears**, §6). | Vision §1 | Gears *(the building-blocks sense — see §6)* | proposed *(naming overlap flagged — see Open questions)* |
+
+
+---
+
+## 1. Actors & Roles
+
+**Actors** — *anything that performs a transformation in the lifecycle (Vision §7.1). Today mostly humans; increasingly AI agents and systems.*
+
+| Canonical | Definition | Source | Aliases | Status |
+| ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------- | -------- | -------- |
+| **Actor** | Anything that performs a transformation in the Software Construction Lifecycle. | Vision §7.1 | — | proposed |
+| ↳ **Human** | A person acting in Studio — today the majority of actors. | Vision §7.1 | person | proposed |
+| ↳ **AI Agent** | An actor (runtime entity) that performs lifecycle work autonomously; it **runs the Skills** a kit ships (§6). Today built on Claude. | Vision §7.1 | agent | proposed |
+| ↳ **External Tool** | A tool invoked as an actor (IDE agent, CLI). | Vision §7.1 | — | proposed |
+| ↳ **External System** | A connected system that acts in the lifecycle. | Vision §7.1 | — | proposed |
+| ↳ **Automated Pipeline** | A CI/CD or scheduled pipeline acting as an actor. | Vision §7.1 | pipeline | proposed |
+
+**Roles & functions** — *the functions Studio serves; a Role is assigned to a Member and drives which activities/stages they own.*
+
+| Canonical | Definition | Source | Aliases | Status |
+| ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------- | --------------------- | -------- |
+| **Role** | An **access / permission set** (RBAC / ABAC), **defined once** in the Organization catalog and **granted** to a **Member** (or **Team**) at a **scope** — Workspace or a specific Project (so the same person can be Editor in Project A, Viewer in Project B) — *never* baked into the Member. Distinct from **Function** (the 8 org functions — see the Functions & Roles table below). An Actor may hold one or many Roles (possibly different per Workspace / Project). | Vision §7.1–7.2 · NIST RBAC (INCITS 359) / ABAC (SP 800-162) | permission set | proposed |
+| **Access Control** | Who can see / do what — the **enforcement of Roles** as RBAC / ABAC rules. (Org-wide constraints live in Governance ▸ Access-control policy.) | Vision §14.3 · NIST RBAC (INCITS 359) / ABAC (SP 800-162) | RBAC / ABAC, permissions | proposed |
+| **Function** | One of the **8 org functions** Studio serves (Product Management · Product Marketing · UX · R&D · QA · DevOps/DCO · GTM · Customer Success); each groups a set of Roles and owns a purpose across the lifecycle — enumerated in the **Functions & Roles** table below. | Vision §7.2 | function set, role set | proposed |
+| **Buyer (persona)** | The economic buyers for Studio (a subset of the roles above) — **PM:** CPO, Director of Product Management, Product Manager; **R&D:** CTO, Chief Architect, VP Engineering, Head of Platform, Head of R&D. | Vision §6.2 | — | proposed |
+
+**Functions & Roles** — *the 8 functions Studio serves (Vision §7.2); each groups its Roles and a purpose. Each **Actor** may play one or many Roles.*
+
+| Function | Roles | Purpose |
+|---|---|---|
+| **Product Management** | CPO · Director of Product · Product Owner · Product Manager · Program Manager | Define what should be built |
+| **Product Marketing** | CMO · Product Marketing Manager · Technical Marketing Manager · Marketing Communications Manager | Position and launch products |
+| **User Experience Team** | UX Researcher · UX Designer · UI Designer · Interaction Designer · Design System Engineer | Design user experience |
+| **R&D** | CDO · CTO · Chief Architect · Engineering Manager · Developer · AI Engineer | Design and construct software |
+| **QA** | QA Engineer · Performance Engineer | Validate quality |
+| **DevOps / DCO** | SRE · DevOps | Operate production systems |
+| **GTM** | CRO · Regional VP | Sell and grow the business |
+| **Customer Success** | Implementation team · Customer Support · TAM | Earn from customers, support customer growth |
+
+---
+
+## 2. Organization, Workspace, Project & Collaboration
+
+**Organization, Workspace & Project (structural containers)**
+
+| Canonical | Definition | Source | Aliases | Status |
+| ----------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ | ------------------------- | -------- |
+| **Organization** | The company's account — owns the **user directory** and the **billing account**; holds one or more Workspaces. One identity per person lives here (SSO). Auto-created & invisible for a single-workspace company; shown once there are several. | | account, org | proposed |
+| **Workspace** | A billed **isolation + configuration unit** under an Organization: holds Projects, installed Kits, Settings, shared standards (guardrails, templates), Teams. Scoped per company or per product-line / portfolio; an Organization may run several. | Vision §9 | — | proposed |
+| **Project** | The working scope inside a Workspace — its own **Project Graph**, **Documents**, **Workflows**, **Dashboards**. Navigation is **Organization → Workspace → Project** (Organization hidden when there's one). | Vision §9 | — | proposed |
+| **User** | One identity per person, **created & managed at the Organization** (invite / SSO / SCIM / deactivate). Added to a Workspace by being made a **Member** (seat + roles). | | account, identity | proposed |
+| **Member** | A **User enrolled in a Workspace** — carries a **Seat** + **status** (active / invited / suspended) and **Roles** (granted at a **scope** — Workspace or Project). One person can be a Member of several Workspaces. Grants *presence*; roles are attached at a scope, not baked into the Member record. | | (join record: membership) | proposed |
+| **Seat** | A billable license slot a **Member**'s enrollment consumes; an *attribute* of the Member, not a separate access concept. | | license slot | proposed |
+| **Team** | A named grouping of **Members** within a Workspace; can be **granted a Role at a scope** (the whole team inherits it), but does **not** define roles. | Vision §9 | group | proposed |
+| **Environment** | A deployment target / isolation context (**dev · staging · prod**) that a Project's work is built, validated and released into; it **scopes connector & secret bindings**. | | deploy target, env | proposed |
+| **Shared asset** | A reusable asset published to the Workspace for reuse across projects — **Guidelines · Processes · Templates · Workflow blueprints · Shared artifacts**. Sharing them across projects/teams is a Collaboration capability (see **Sharing**). | | shared assets | proposed |
+
+
+**Collaboration** *(cross-cutting layer — not a standalone screen)* — the **sharing + coordination** capabilities (reviews, comments, handoffs, activity, sharing) that **surface on other entities**. *People, Teams, Roles & Access are the identity / access model — see §1 and §2 above; not repeated here.*
+
+| Canonical | Definition | Source | Aliases | Status |
+| -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------- | ------------------ | ------------------- |
+| **Collaboration** | The cross-cutting layer itself (sharing + coordination — reviews · comments · handoffs · activity feed). | Vision §9 | — | proposed |
+| ↳ **Activity Feed** | A chronological stream of changes / events. | | feed | proposed *(target)* |
+| ↳ **Sharing** | Sharing reusable assets — guidelines, templates, workflows, artifacts — across projects / teams / org. Custom-kit sharing (**bridge to Customization, §6**) extends this. | Vision §9 | — | proposed |
+| ↳ **Guardrails & Quality Gates** | Shared standards defined at team / org level — the org-wide **definition**; per-project enforcement is Project ▸ Quality Gates. | Vision §9 | — | proposed |
+| ↳ **Review & Approval** | Coordinated review and sign-off on transitions and artifacts. | Vision "Human-Centric Automation" | approval, sign-off | proposed |
+| ↳ **Handoff** | Passing one activity's outputs as the inputs of another. | Vision §3.3, §8 | — | proposed |
+| ↳ **Comment** | An inline discussion thread on an object / artifact. | | — | proposed *(target)* |
+| ↳ **Pull Request (PR)** | A **Work Artifact** (code-change) — an Artifact, not a document. **Created on a Workflow run**; its review / approval is in Collaboration; it's a node in the **Project Graph** — **not** under Documents. | Vision "Shadow SDLC Graph" | MR (GitLab) | proposed |
+| ↳ **Exception** | An override of a quality gate, surfaced for review. | Vision "Expansion Roadmap" | waiver, override | proposed |
+
+
+---
+
+## 3. Lifecycle & Stages
+
+| Canonical | Definition | Source | Aliases | Status |
+| ------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- | ------------------------------------- | ---------------------------------- |
+| **SCLC (Software Construction Lifecycle)** | The full lifecycle Studio champions: from product **Intent** through construction and operation to **learning, evolution and transformation** — wider than SDLC, which stops at creating software. **3 phases** (Plan → Build → Operate), **14 stages**. | Vision §1, §8 · ISO/IEC/IEEE 12207 | Software Construction Lifecycle | proposed *(NEW in updated vision)* |
+| **SDLC (Software Development Lifecycle)** | The traditional development lifecycle focused on *creating* software. Studio does **not** dictate one — it adapts to the company's SDLC and **extends it into an SCLC**. (The shadow graph, once "SDLC Graph," is now **Project Graph** — §4.) | Vision §8, §1.2–1.3, §13 · ISO/IEC/IEEE 12207 | — | proposed |
+| **Reference SCLC** | The example lifecycle Studio ships (Intent → … → Evolution); usable as-is or customizable. Delivered by the base **SDLC Kit** (§6). | Vision §8 | reference SCLC *(vision typo "SCLC")* | proposed |
+| **Lifecycle Model** | The IA-node name for the **Reference SCLC** applied to a Project — its actors, 3 phases / 14 stages, activities, inputs/outputs, quality gates and synchronisation checkpoints. (Map label; the concept is the **Reference SCLC** above.) | Vision §8 | Reference SCLC *(as shown in the map)* | proposed |
+| **Plan / Build / Operate** | The 3 high-level SCLC phases grouping the 14 stages. | Vision §8 | — | proposed |
+| **Stage** | A step within a phase. Reference set = 14: Intent → Vision → Discovery → Strategy → Definition → Design → Construction → Validation → Release → Operation → Support → Intelligence → Optimization → Evolution. | Vision §8 · ISO/IEC/IEEE 12207 | lifecycle stage | proposed |
+| **Activity** | Work an actor performs at a stage, defined (and configurable) with Inputs, Outputs, Quality gates, and Synchronisation checkpoints. | Vision §8 · ISO/IEC/IEEE 12207 | — | proposed |
+| **Input / Output** | The artifact(s) an Activity **consumes / produces**; one activity's Output can feed another's Input. | Vision §8 | — | proposed |
+| **Synchronisation checkpoint** | A defined coordination point between roles / activities at a stage. | Vision §8 | sync checkpoint | proposed |
+
+
+---
+
+## 4. Graph & Objects
+
+| Canonical | Definition | Source | Aliases | Status |
+| -------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- | ----------------------------------------------------------- | ------------------ |
+| **Project Graph** | Studio's **mirror / shadow copy** of a Project's SDLC objects, attributes, relationships, states, history and evidence — tracked from source-of-record tools (Jira / Git / CI…), which Studio governs but does **not** own. **One per Project; the system's spine.** *Renamed from "SDLC Graph" (2026-07-10)* to drop the SCLC/SDLC collision. | Vision §13 | SDLC Graph, Shadow SDLC Graph, Delivery Graph, shadow graph | proposed |
+| **Source of record** | The external tool that **owns the truth** for an object; Studio mirrors it and does not replace it. | Vision §13 | system of record | proposed |
+| **Object** | A node in the graph (Requirement, PRD, Design, ADR, Task, Epic, Bug, **Decision**, Repo, File, Branch, Commit, PR, Test, Build, Release, Deployment, Alert, Incident, Runbook, Postmortem, Person, Team, Role, Approval). | Vision "Shadow SDLC Graph" | Node | proposed |
+| **Object type** | A class of graph object; browsable / filterable in the Object Browser. | Vision "Shadow SDLC Graph" | node type | proposed |
+| **Artifact** | A **work product** — anything an Activity produces or consumes; a **subtype of Object** (not every Object is an Artifact). Splits into two families ↓. **Surfacing:** Document Artifacts → **Documents** (authored, or produced on a run then edited); Work Artifacts → **Workflow runs** (created) + **Dashboards** (status) + **Project Graph** (connected). | Vision §1, §1.1 | work product,
artefact,
deliverable | proposed |
+| ↳ **Document Artifact** | An artifact **authored / read as content** — PRD · BRD · ADR · Design · Decomposition · Feature spec · Report · Runbook · Postmortem · Competitive register · Comparison matrix · Pricing benchmark. Native ones own **Content + versions** (`sourceOfRecord`); mirrored ones point to an external source-of-record. **Written by hand — or produced by a Workflow run — then opened / edited in the _Documents_ surface** (a standing home). *("Documents" = the surface where these live; distinct from Work Artifacts, which are monitored, not opened for editing.)* | Vision §1.1 · ISO/IEC/IEEE 15289 | document; **Document artefact** *(surface)* | proposed |
+| ↳ **Work Artifact** | An artifact **produced by execution** — PR · Test · Build · Release · Deployment. **Created on a Workflow run** (run → produced artifacts + gate status); its status rolls up to **Dashboards** (release readiness / delivery health); it's a node in the **Project Graph** (traceability). **No separate authoring surface** — produced & monitored, not authored. *(Work items — Task · Epic · Bug · Incident — are tracked, not produced-and-shipped; also graph nodes.)* | Vision "Shadow SDLC Graph" | work object | proposed |
+| **Object Browser** | **Query / inspect / traceability** entry into the graph — search & filter by type · status · owner · staleness, then traverse edges & inspect a node. **Type is a filter, not a catalog**; it does not list documents (→ Documents) and does not duplicate the graph. | Vision "Platform Architecture" | — | proposed (UX term) |
+| **Attribute** | A tracked field on an object (source system + external ID, owner, team, state, version, last sync, validation status, staleness / risk). | Vision "Shadow SDLC Graph" | Property, свойство | proposed |
+| **Object state** | The `state` / validation-status **Attribute** an object advances as it is created → enriched → validated (progressive enrichment, in place); value-set is kit/scenario-specific. | Vision "Tracked attributes" | lifecycle state, validation status | proposed |
+| **Report field** | A column / field in an **Artifact** view that surfaces an object **Attribute**; the field-set is defined by the **Template** / ontology (via **Customization** — see scenarios SC-02/03) and selected at use-time. | | column, parameter | proposed |
+| **Traceability** | The relationships linking requirement → design → code → test across the graph. | Vision §1.1–1.3 · ISO/IEC/IEEE 29148 | — | proposed |
+| **Evidence** | Artifacts that prove an action's result was validated. | Vision "Validated Action Graph" | — | proposed |
+
+
+---
+
+## 5. Actions, Flows & Validators
+
+| Canonical | Definition | Source | Aliases | Status |
+|---|---|---|---|---|
+| **Action** | An executable **edge** over the graph — a transformation that turns object(s) into candidate object(s). | Vision "Actions Are Executable Edges" | Method, Job, executable edge | proposed (canonical: Action; *Method* = engine-side alias) |
+| **Transition type** | How an action runs: **deterministic script** / **AI-assisted transformation** / **human task**. | Vision "Core Ideas" | — | proposed |
+| **Write-back (Controlled write-back)** | Studio committing an **approved** change back into the source-of-record tool — create ticket, update doc, open PR, run CI, assign owner. Always human-approved first. | Vision §13 | write-back | proposed |
+| **Legacy-to-spec (brownfield)** | Ingesting existing code / repositories to generate or reconstruct a consistent spec set (reverse engineering). | Vision §1.1, §1.2 | brownfield reconstruction | proposed |
+| **Step** | A single step in a running workflow instance — distinct from a lifecycle **Stage** (§3). | Vision "First Killer Workflow" | workflow step | proposed |
+| **Workflow run (Run)** | One execution of a **Workflow** — the instance that **produces Work Artifacts** (run → produced artifacts + gate status); status & history live in Workflows ▸ Runs and history. Distinct from **Workflow** (the pipeline) and **Step** (one step within a run). | Vision "First Killer Workflow" | run | proposed |
+| **Workflow** | A repeatable pipeline of actions + validators + conditions/loops, with its own model settings and quality gates. | Vision "Killer Workflow(s)" | Flow | proposed (canonical: Workflow; *Flow* used loosely) |
+| **Flow Catalog** | Catalog of predefined, reusable workflows / blueprints a user can pick and orchestrate. | Vision "Studio Flow Library" | Flow Library | proposed |
+| **Blueprint** | A reusable workflow **template** you clone to create a workflow (the pattern, not a run). | Vision "Expansion Roadmap" | — | proposed |
+| **Predefined flow** | A **shipped, ready-to-run** analysis workflow (vs Blueprint = template): gap, traceability, contradiction, bloat, stale-artifact, ownership-gap, duplicate-work, architecture-drift, security-impact, test-gap, release-readiness, incident→postmortem, ops-metrics, AI-cost. | Vision "Studio Flow Library" | smart flow | proposed |
+| **Validator** | A check that decides whether candidate work may move to the next state. | Vision "Validated Action Graph" | — | proposed |
+| **Validator Loop** | The pass / fail / retry / escalate cycle around a validator (bounded automation). | Vision "Validator Loops" | validation loop | proposed |
+| **Quality Gate** | A **must-pass checkpoint**: work **cannot advance** until it passes. Defined org-wide at Workspace ▸ Guardrails & Quality Gates; enforced / observed per project at Project ▸ Quality Gates. | Vision §8 | gate | proposed |
+| **Guardrail** | A **hard preventive block**: the disallowed action simply **cannot happen** (vs a Quality Gate, which you must pass to advance). Set org-wide. | Vision §9 | — | proposed |
+| **Policy** | The **machine-readable rule** a Guardrail or Quality Gate enforces. | Vision §5 | — | proposed |
+
+---
+
+## 6. Kits & Gears
+
+| Canonical | Definition | Source | Aliases | Status |
+| --------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------- | ------------------------------------------------------- | -------- |
+| **Kit** | A packaged, reusable body of delivery knowledge for a domain: **reference architecture** + ontology + templates & examples + **sample data** + actions + validators + rules/policies + **Kit Workflows** + **deployment patterns** + Gears. | Vision "SaaS Development Kits" | Domain Kit, SaaS Development Kit | proposed |
+| **Kit package** *(IA node)* | The IA node under **Kits** that shows a kit's **anatomy** — its contents are listed under **Kit** (above). (Map node: "Kit (package / anatomy)".) | Vision "SaaS Development Kits" | kit contents, kit anatomy | proposed |
+| **SDLC Kit** | The open-source **base / default** kit; implements the Reference SCLC. Not a role variant. | Vision "Credible Wedge" | Product Design Kit | proposed |
+| **Ontology** | The entities and relationships that define a domain — the schema a kit brings. | Vision "Shadow SDLC Graph" | kit schema | proposed |
+| **Template** | A reusable artifact scaffold shipped in a kit. | Vision "SaaS Development Kits" | — | proposed |
+| **Sample data** | Seed / demo data a kit ships to **populate the Project Graph** — so a project shows the product working out of the box (PM Kit: sample competitors + a sample PRD; DevOps Kit: sample incidents / runbooks). Part of the **Kit package** (next to Templates & examples); loaded into a Project's graph at setup. | Vision "SaaS Development Kits" | seed data, demo data, examples | proposed |
+| **Kit Workflows** | The recommended flows a kit ships; they populate the Flow Catalog and can be run inside a project. | Vision "SaaS Development Kits" | kit flows, recommended flows | proposed |
+| **Gears** | Reusable building-block modules used to assemble the final application (Identity, Authorization, Events, Serverless, GenAI, Platform); supplied by **Constructor Gears** (§0). *Impl. note:* some delivered as pre-generated / auto-compiled libraries for basic, rarely-changing pieces, to save tokens — this is *how* they're built, not a competing meaning. | Vision "Gears Building Blocks" | building blocks | proposed |
+| **Skill** | The **code** (Python scripts) that implements a kit's domain logic / workflow — what an **AI Agent** (§1) actually runs. Distinct from Gears (reusable app modules); this is where the domain work lives. | | Claude Skill, Python agent | proposed |
+| **Function Kit** *(IA node — the shipped catalog)* | A ready-to-install kit scoped to a **function / role** (Architect · PM · Eng Mgmt · DevOps · QA · Support…); the installable catalog under **Kits**. Kits span three axes — **base/default** (SDLC Kit) · **function/role** (the variants below) · **domain** (M&A · HypoFinder = research) — and the shipped catalog lists all three, so *by function/role* is the primary organizing axis. *("Any other Kit" = a placeholder slot, not a shipped kit.)* | | role kit, pre-defined kits, installed kits, kit catalog | proposed |
+| ↳ **Architect Kit** | Kit for architects — system design, ADRs, architecture artifacts & flows. | | — | proposed |
+| ↳ **Product Management Kit** | Kit for PM / PgM — the 8 PM journeys (competitive landscape, PRD, metrics). | | PM Kit | proposed |
+| ↳ **Engineering Management Kit** | Kit for engineering managers — planning, delivery tracking, throughput. | | Eng Mgmt Kit | proposed |
+| ↳ **DevOps Kit** | Kit for DevOps / SRE — CI/CD, deployment, ops artifacts & flows. | | — | proposed |
+| ↳ **QA Kit** | Kit for QA — test planning, validation, coverage flows. | | — | proposed |
+| ↳ **Support Kit** | Kit for support / customer success — incidents, tickets, customer signals. | | — | proposed |
+| ↳ **HypoFinder Kit** | The proprietary research kit — science ontology + hypothesis-search flows; product name = **HypoFinder** (§0). *(Domain-axis; listed here because the shipped map places it in this set.)* | | Scientific Research Kit, science kit | proposed |
+| ↳ **Any other Kit** | Placeholder slot for additional / custom function-role kits (not itself a shipped kit). | | custom kit | proposed |
+| **Customization** *(the authoring face of Kits & Gears — an activity, not a container)* | Extending what the platform can do — introducing object types, properties, methods, workflows, and validation policies **without modifying the core**; building & sharing custom kits. **Orthogonal to Collaboration (§2):** the two meet only where a *custom kit is shared / reused*. In the IA it lives inside **Kits & Gears** (2026-07-10 root decision), not as its own top-level node. | Vision "SaaS Development Kits" | Customizable (adj.), Kit Customization | proposed |
+| ↳ **Kit authoring** | Build / extend a kit's domain model: objects (schema), properties, methods / actions, workflows, validators / policies. | | — | proposed |
+| ↳ **Instance configuration** | Per-workspace runtime settings: model routing, which validators / gates run, context compression. | Vision §5, §5.2 | runtime config | proposed |
+| ↳ **Build & share custom kit** | Package a custom kit and share / reuse it — the single bridge to Collaboration ▸ Share. | | — | proposed |
+
+---
+
+## 7. PM-scenario terms (first-version scope)
+
+| Canonical | Definition | Source | Aliases | Status |
+|---|---|---|---|---|
+| **User Journey** | An end-to-end path a role takes from intent to outcome, written in the `ALGORITHM` schema (Actor/Goal/Inputs/Outputs/Steps/Decision points/Guards/Next). | | journey | proposed |
+| **Scenario** | A concrete *way* of accomplishing an action within a journey; spans several atomic steps. | | — | proposed |
+| **Atomic scenario** | The leaf unit Scenarios are composed from: **one Action mapped to one IA object**, expressed in glossary terms. | | — | proposed |
+| **Scenario group** | The 3 first-version groups: **Competitive Landscape**, **Requirements / PRD**, **Metrics**. | | 3 groups | proposed |
+| **Opportunity Statement** | The Intent-stage output naming a market/customer opportunity worth pursuing. | Vision §8, §12.1 | — | proposed |
+| **JTBD (Jobs to Be Done)** | Framing a need as the "job" a customer hires the product to do; used in Discovery. | Vision §8 | jobs-to-be-done | proposed |
+| **Competitive register** | Shared competitor comparison schema populated in layers: identity → product & traction → pricing. | | competitor register | proposed |
+| **Comparison matrix** | The quarterly-comparison output Artifact — side-by-side competitors across product & functionality + scale & traction, versioned per quarter. | | quarterly comparison | proposed |
+| **Pricing benchmark** | The pricing-analysis output Artifact — our price vs competitors per geography × tier (normalised), with trend, versioned. | | pricing benchmark grid | proposed |
+| **CEP (Customer Experience Program)** | Weekly practice of analysing our own users' experience (usage + VoC) to find friction → improvement work. | | continuous discovery | proposed |
+| **EPSVS** | Internal 5-dimension quality framework: Efficiency, Performance, Scalability, Versatility, Security. Team-defined, not an industry standard. | ISO/IEC 25010 | — | proposed |
+| **Instrumentation** | Adding tracking events to the product per release. Naming scheme = *taxonomy*; emitted data = *telemetry*. | | — | proposed |
+
+**Spec framework** — *the artifact set Studio produces (each is also an Artifact object-type, §4)*
+
+| Canonical | Definition | Source | Aliases | Status |
+|---|---|---|---|---|
+| **BRD** | Business Requirements Document — business goals, scope, stakeholders (the *why* at business level). | Vision §1.1 | — | proposed |
+| **PRD** | Product Requirements Document — what to build: problem, requirements, acceptance, success metrics. | Vision §1.1 · ISO/IEC/IEEE 29148 | spec | proposed |
+| **Requirement** | An atomic statement of something the product must do or satisfy — the lead Object type; anchors traceability (**requirement → design → code → test**). Grouped/authored in BRD & PRD; a graph object. | Vision §1.1 · ISO/IEC/IEEE 29148 | — | proposed |
+| **ADR** | Architecture Decision Record — one architectural decision + context + consequences. | Vision §1.1 | — | proposed |
+| **Decision** | A recorded decision — choice + rationale + date — a graph object & Document Artifact; **ADR** is the architecture-specific form, a plain Decision covers non-architectural choices. | Vision "Shadow SDLC Graph" | — | proposed |
+| **Design** | The architecture / design artifact produced from a PRD. | Vision §1.1 | architecture | proposed |
+| **Decomposition** | Breaking a design / feature into tasks. | Vision §1.1 | breakdown | proposed |
+| **Feature spec** | The buildable feature definition, tied to code via @cpt-\* markers. | Vision §1.1 | FEATURE | proposed |
+
+**Other document artifacts** — *the rest of the document types that surface under Project ▸ Documents (all `Artifact` object-types; vision: "introduces no new artifacts")*
+
+| Canonical | Definition | Source | Aliases | Status |
+|---|---|---|---|---|
+| **Product strategy brief** | The durable "why" — north-star, positioning, bets — a PM returns to across the lifecycle. | | strategy brief | proposed |
+| **Roadmap** | The prioritised plan of what's coming — Now / Next / Later (or timeline). A *living* document. Distinct from **Roadmap phases** (§8, the build-out phases). | | product roadmap | proposed |
+| **One-pager / narrative** | The concise pitch / exec-alignment document for an initiative. | | narrative, brief | proposed |
+| **Launch plan / GTM checklist** | The cross-functional launch-coordination document (distinct from Release notes = the artifact). | | GTM checklist | proposed |
+| **Release notes** | The customer-facing summary of what shipped in a release (PM often owns this version). | | changelog | proposed |
+| **Test plan / Validation report** | The Validation-stage document — planned checks and their results/evidence (the *report*, not the `Test` work object). | Vision §8 · IEEE 829 | validation report | proposed |
+| **Runbook** | An operational procedure document for running / recovering a system. | Vision "Shadow SDLC Graph" | — | proposed |
+| **Postmortem** | The incident-retrospective document (what happened, why, prevention). | Vision "Shadow SDLC Graph" | incident retro | proposed |
+
+**Requirements & delivery**
+
+| Canonical | Definition | Source | Aliases | Status |
+|---|---|---|---|---|
+| **EPIC** | A large body of work that decomposes into user stories. | | epic | proposed |
+| **User story** | A backlog-ready item with acceptance criteria, sized to fit a sprint; decomposed from an EPIC. | | story | proposed |
+| **Backlog** | The prioritised, groomed list of stories / items awaiting a sprint. | | — | proposed |
+| **Sprint** | A fixed-length delivery iteration; scope committed at **sprint planning**, inspected at **sprint review**. | | iteration | proposed |
+| **Backlog refinement** | Ongoing refinement of the backlog (clarify, estimate, split) to keep it ≥ 1 sprint ahead. | | grooming, backlog grooming *(deprecated in Scrum)* | proposed |
+| **Problem statement** | Who is affected, the pain, and the evidence — how a PRD opens. | | — | proposed |
+| **Success criteria** | The business / user outcomes a feature must achieve. | | — | proposed |
+| **Acceptance criteria** | The testable conditions that define "done" for a story / spec. | ISO/IEC/IEEE 29148 | — | proposed |
+| **Effort estimate** | A high-level R&D sizing (t-shirt size or range) attached to a spec. | | estimate, t-shirt size | proposed |
+| **Mockup** | A mid/high-fidelity Design artifact reviewed where a story / spec has UX. | | wireframe | proposed |
+| **Design review** | **Review & Approval** with the Design team of UX-bearing work. | | — | proposed |
+| **Prioritisation basis** | How the backlog is ordered: value / risk / dependency. | | — | proposed |
+| **Blocker** | A dependency or open question that stops a story entering a sprint; carries an owner. | | impediment | proposed |
+
+**Metrics & instrumentation** — *(CEP · EPSVS · Instrumentation above; Product metrics in §8)*
+
+| Canonical | Definition | Source | Aliases | Status |
+|---|---|---|---|---|
+| **Event** | A tracked user / product action emitted to analytics. | | tracking event | proposed |
+| **Event property** | A field on an event — **global** (super) properties on every event + **local** (event-specific) ones. | | super property, local property | proposed |
+| **Event taxonomy** | The versioned catalogue + naming scheme of events, properties and definitions. | | tracking plan, data dictionary | proposed |
+| **Naming convention** | The single self-describing name format (`object_action`, snake_case, past tense). | | — | proposed |
+| **Autocapture** | SDK-level automatic capture of a baseline (`page_viewed`, `button_clicked`). | | SDK autocapture | proposed |
+| **Data-quality gate** | Pass/fail check that events arrive with correct properties, no duplicates or gaps, before a release is marked instrumented. | | — | proposed |
+| **Coverage** | Share of key user flows emitting the expected events (target 100%). | | instrumentation coverage | proposed |
+| **Telemetry** | The emitted data / signals (events, metrics, traces) the analytics journeys consume. | | — | proposed |
+| **Session replay** | Behavioural capture of a user session, used in CEP to explain the *why* behind a drop-off. | | — | proposed |
+| **Cohort / Segment** | A slice of users (plan/tier, role, persona, platform, tenure). | | segment | proposed |
+| **Feature adoption** | How widely a feature is used across the base; flags under-adopted areas. | | adoption | proposed |
+| **Drop-off / funnel** | Where users abandon a flow — the quantified UX-inefficiency signal in CEP. | | funnel drop-off | proposed |
+| **Scorecard** | A periodic rollup of metrics per dimension. | | — | proposed |
+| **Gap severity** | Disposition of a found gap: critical / planned / monitor. | | — | proposed |
+| **Peer review** | PM-team review of judgement-heavy analysis (severity / metric calls) before publishing. | | — | proposed |
+
+---
+
+## 8. Dashboards, Recommendations, Settings & Notifications
+
+**Dashboards & metrics**
+
+| Canonical | Definition | Source | Aliases | Status |
+| --------------------- | ----------------------------------------------------------------------------------------- | ---------------------------- | ----------- | -------- |
+| **Dashboard** | A panel view summarising delivery health, AI cost, or release readiness. | Vision "Expansion Roadmap" | — | proposed |
+| **Delivery health** | Dashboard view of delivery status across the graph (gaps, risks, staleness rollups). | Vision "Expansion Roadmap" | — | proposed |
+| **AI cost** | Dashboard view of token / compute spend; "AI cost per accepted change" is the key metric. | Vision §3.1, §5 | token spend | proposed |
+| **Release readiness** | Dashboard / flow view assessing whether work is ready to release. | Vision "Studio Flow Library" | — | proposed |
+| **Product metrics** | Product-analytics view (usage, funnels) built from instrumentation. | | analytics | proposed |
+
+**Recommendations**
+
+| Canonical | Definition | Source | Aliases | Status |
+|---|---|---|---|---|
+| **Recommendation** | A suggested next action Studio surfaces, alongside detected gaps/risks and prepared actions. | Vision "Human-Centric Automation" | — | proposed |
+| **Next action** | The suggested next task / action for the user. | Vision §8 | — | proposed |
+| **Detected gap** | A gap / contradiction / risk Studio found (e.g. a requirement with no test). | Vision "Gap Detection" | gap/risk signal | proposed |
+| **Prepared action** | A candidate action Studio has prepared, awaiting human approval. | Vision "Actions Are Executable Edges" | — | proposed |
+| **Trust level** | How much autonomy a prepared action is granted — from *recommend only* → *prepare for approval* → *auto-execute within policy*. Governs whether a Write-back needs human sign-off. | Vision "Human-Centric Automation" | autonomy level | proposed |
+
+**Settings & integrations**
+
+| Canonical | Definition | Source | Aliases | Status |
+| --------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- | ------------------- | -------- |
+| **Settings** | The workspace-level configuration container: model routing, instance config, connectors, localization. | | workspace settings | proposed |
+| **Model routing** | Routing each activity to the most cost-efficient model; centrally controllable / lockable. | Vision §5, §5.1 | multi-model support | proposed |
+| **Context compression** | Reducing token load via summarisation / filtering / pruning. | Vision §5.2 | — | proposed |
+| **Benchmarking** | Measuring cost / quality of AI tokens and dev compute for optimization. | Vision §5.3, §11.1 | — | proposed |
+| **Connector** | An integration to an existing system (Jira, Git, CI, Docs, cloud…), via **Constructor Insight** (the connector/analytics layer). The **catalog** of connectable systems lives at Organization ▸ Integrations (by lifecycle phase); a **bound** connection — with its Secret — is configured at Workspace ▸ Settings. | Vision §11.1, §13 | integration | proposed |
+| **Localization** | Locale support: UI translation + currency / date / time formats, week-start, RTL. | Vision §10 | l10n | proposed |
+| **Notification** | A signal to the user about gaps, risks, stale work, or failures. | Vision "Expansion Roadmap" | alert | proposed |
+| **Secret / Credential** | The connection credentials (OAuth tokens, PATs, API keys) a Connector needs — held **separately** from connector config, **Workspace / Environment-scoped**, with rotation + audit. | | credential, token | proposed |
+| **Audit (log / trail)** | The recorded history of *who did what* — sign-offs, write-backs, config changes — kept at **Organization and per Workspace** for compliance / segregation of duties. | Vision "Evidence" | audit trail | proposed |
+| **Data residency / region** | Where account / workspace data is **stored & processed** (region pinning) — an Organization policy with a per-Workspace region. Distinct from **Localization** (formats / language). | | region, residency | proposed |
+
+**Advanced / roadmap**
+
+| Canonical | Definition | Source | Aliases | Status |
+|---|---|---|---|---|
+| **Roadmap phases** | The 4 build-out phases: **Phase 1** CLI PoC · **Phase 2** Validated actions · **Phase 3** Centralized automation (workspaces, flow catalog, dashboards) · **Phase 4** Enterprise control plane (Insight-at-scale, on-prem, World Model). | Vision "Credible Wedge" | — | proposed (roadmap) |
+| **World Model** | A predictive model over the SDLC graph that forecasts a change's downstream impact; a Phase-4 enterprise capability and part of the moat. | Vision "Expansion Roadmap" | — | proposed (roadmap) |