{"contexts":[{"name":"Root","description":"Cross-cutting terms used across the whole of ValueStack.","terms":[{"name":"Workstream","context":"Root","definition":"A discrete, independently scopable deliverable phase within an engagement (e.g. WS1 Content Calendar, WS2 Brief Management). Each workstream has its own scope, acceptance criteria, and can ship without the others. A workstream delivers a single Outcome and, in an Airtable engagement, is realised as an ordered sequence of Airtable pages, listed, with what users do on each, in the workstream's SOW appendix.","author":"CC (Mclaren)","added":"2026-05-28","avoid":[],"distinctFrom":[{"ref":"Workstream block","note":"Workstream is the deliverable concept; Workstream block is its visual rendering on a Discovery board"},{"ref":"Outcome","note":"Workstream is the deliverable phase; Outcome is the user-facing result it delivers"}]},{"name":"Outcome","context":"Root","definition":"The user-facing result a Workstream delivers: the higher-order \"so that\" the workstream exists for (e.g. \"disclosures get triaged within 48 hours\"). One per workstream; it is what the SOW commits to. Evidenced by the workstream's pages and their Airtable page outputs, but not identical to any single page output.","author":"cuan (Novocure)","added":"2026-05-30","avoid":["output (an Outcome is a business result","not an artifact; see Airtable page output)"],"distinctFrom":[{"ref":"Airtable page output","note":"Outcome is the result of the whole workstream; an Airtable page output is a concrete artifact produced by one page"},{"ref":"Workstream","note":"Workstream is the deliverable phase; Outcome is what it delivers"}]},{"name":"Deal","context":"Root","definition":"A specific commercial opportunity ValueStack is pursuing, from prospect through signing to delivery to closure. Holds the commercial wrapper: title, owner, business unit, stage, value, and links to companies and contacts. May produce one or more SOWs and an engagement.","author":"claude (assistant)","added":"2026-05-28","avoid":["opportunity","lead"],"distinctFrom":[{"ref":"Engagement","note":"a Deal is the commercial record; an Engagement is the delivery work that follows a signed SOW"}]},{"name":"Engagement","context":"Root","definition":"The active delivery work executed against a signed SOW. Begins when delivery starts, ends at handover or wrap-up. A single Deal may produce one or more Engagements (e.g. discovery → build → ongoing).","author":"claude (assistant)","added":"2026-05-28","avoid":[],"distinctFrom":[{"ref":"Deal","note":"Engagement is execution; Deal is the commercial wrapper that authorises it"}]},{"name":"Action","context":"Root","definition":"A forward-looking task tied to a Deal, company, contact, or person. Rendered as a kanban card with exactly one Owner and any number of Members. Represents something to DO, not a record of what happened.","author":"claude (assistant)","added":"2026-05-28","avoid":["task","todo"],"distinctFrom":[{"ref":"Note","note":"an Action is future-tense work to be done; a Note is past-tense record of what occurred"}]},{"name":"Note","context":"Root","definition":"A record of an interaction that occurred: a call, a meeting, an email exchange, a conversation summary. Past-tense by design. May spawn one or more Actions for follow-up, but the Note itself is never the action.","author":"claude (assistant)","added":"2026-05-28","avoid":["log entry","activity"],"distinctFrom":[{"ref":"Action","note":"a Note records what happened; an Action specifies what's next"}]},{"name":"Owner","context":"Root","definition":"The single staff person accountable for a record (Deal, Action, Note, and similar). Exactly one Owner per record at any time. Used for filtering \"show my work\" surfaces and for accountability.","author":"claude (assistant)","added":"2026-05-28","avoid":[],"distinctFrom":[{"ref":"Member","note":"an Owner is uniquely accountable; a Member is an additional participant without primary accountability"}]},{"name":"Member","context":"Root","definition":"A staff person attached to a record (currently Actions) in addition to its Owner. Many Members per record are allowed; the Owner is never also a Member of the same record. Surfaces the record on every Member's \"my work\" view.","author":"claude (assistant)","added":"2026-05-28","avoid":[],"distinctFrom":[{"ref":"Owner","note":"the Owner is the single accountable person; Members are additional staff involved without primary accountability"}]}]},{"name":"Pre-sales","description":"Terms specific to the pre-sales phase: Discovery, Findings, SOW authoring.","terms":[{"name":"Data outputs","context":"Pre-sales","definition":"The right-hand lane of a workstream on a Discovery board: what comes OUT of the workflow (systems updated, files produced, notifications dispatched). Workstream-level, not per-step. Always rendered (with a \"To be discovered\" placeholder when empty) so the structure prompts the discovery question.","author":"cuan (human)","added":"2026-05-28","avoid":["outputs (too generic; sounds like return values or general output)","output column"],"distinctFrom":[{"ref":"Data sources","note":"Data outputs are downstream of the workflow; Data sources are upstream"},{"ref":"Airtable page output","note":"Data outputs are workstream-level; an Airtable page output is one page's per-page artifact"}]},{"name":"Data sources","context":"Pre-sales","definition":"The left-hand lane of a workstream on a Discovery board: the systems-of-record flowing data INTO the workflow. Workstream-level, not per-step. Always rendered (with a \"To be discovered\" placeholder when empty) so the structure prompts the discovery question.","author":"cuan (human)","added":"2026-05-28","avoid":["inputs (too generic; confused with user inputs / form fields by agents in earlier workshops)","input column"],"distinctFrom":[{"ref":"Data outputs","note":"Data sources are upstream of the workflow; Data outputs are downstream"},{"ref":"Airtable page input","note":"Data sources are workstream-level; an Airtable page input is one page's per-page boundary"}]},{"name":"Feed","context":"Pre-sales","definition":"A type of Data source: a recurring, permanently-connected system the workstream consumes data from on an ongoing basis (e.g. a synced CRM, an inbound webhook). Lives in the Data sources lane.","author":"cuan (Novocure)","added":"2026-05-31","avoid":[],"distinctFrom":[{"ref":"Migration","note":"a Feed is an ongoing connection; a Migration is a one-off initial load"}]},{"name":"Migration","context":"Pre-sales","definition":"A type of Data source: a one-off load of existing data to seed the base at go-live (e.g. importing a SharePoint backlog or a legacy spreadsheet). Lives in the Data sources lane.","author":"cuan (Novocure)","added":"2026-05-31","avoid":[],"distinctFrom":[{"ref":"Feed","note":"a Migration runs once to seed the base; a Feed is an ongoing connection"},{"ref":"Export","note":"Migration is inbound; Export is its outbound mirror"}]},{"name":"Integration","context":"Pre-sales","definition":"A type of Data output: an ongoing system the workstream ports data INTO on a recurring basis (the outbound mirror of a Feed). Lives in the Data outputs lane.","author":"cuan (Novocure)","added":"2026-05-31","avoid":[],"distinctFrom":[{"ref":"Export","note":"an Integration is an ongoing outbound connection; an Export is a one-off outbound load"},{"ref":"Feed","note":"Integration is outbound; Feed is inbound"}]},{"name":"Export","context":"Pre-sales","definition":"A type of Data output: a one-off outbound load of data to an external destination (the outbound mirror of a Migration). Lives in the Data outputs lane.","author":"cuan (Novocure)","added":"2026-05-31","avoid":[],"distinctFrom":[{"ref":"Integration","note":"an Export runs once; an Integration is ongoing"},{"ref":"Migration","note":"Export is outbound; Migration is its inbound mirror"}]},{"name":"Actor","context":"Pre-sales","definition":"A person or role who performs steps in a workstream (e.g. Inventor, Reviewer, Outside Counsel). A ValueStack discovery concept captured regardless of the build tool: Airtable has no \"actor\" term, and that's fine.","author":"cuan (Novocure)","added":"2026-05-31","avoid":[],"distinctFrom":[{"ref":"Owner","note":"an Actor is a workflow participant in discovery; an Owner is the single accountable staff person on a CRM record"}]},{"name":"Out of scope","context":"Pre-sales","definition":"A step or card on a Discovery board that has been identified but explicitly excluded from the build, captured so the boundary is visible, not silently dropped. Flagged with a red border on Canvas (data.outOfScope = true).","author":"cuan (Novocure)","added":"2026-05-31","avoid":[],"distinctFrom":[{"ref":"Open question sticky","note":"Out of scope is a decision NOT to build something known; an open question is an unresolved unknown to answer"}]},{"name":"Discovery","context":"Pre-sales","definition":"The pre-sales phase where ValueStack interviews stakeholders, maps current workflow, and decides what to build. Output is a Findings document that drives the SOW.","author":"CC (Mclaren)","added":"2026-05-28","avoid":[],"distinctFrom":[{"ref":"Findings","note":"Discovery is the activity; Findings is the artifact it produces"},{"ref":"Discovery board","note":"Discovery is the activity; Discovery board is the live visual artifact built during it"}]},{"name":"Discovery board","context":"Pre-sales","definition":"The visual board on canvas.echoai.zone populated during Discovery: banner, legend, and one or more Workstream blocks. The shareable live artifact of a discovery workshop. Captures the same content as Findings but in a workshop-facing format participants edit together.","author":"cuan (human)","added":"2026-05-28","avoid":["discovery canvas","canvas (ambiguous)","board (ambiguous)"],"distinctFrom":[{"ref":"Findings","note":"Discovery board is the visual workshop artifact; Findings is the written document drafted from it"}]},{"name":"Findings","context":"Pre-sales","definition":"The written output of Discovery. Captures stakeholders interviewed, current pain, target workflow, scope recommendations, and open questions. Drives the SOW.","author":"CC (Mclaren)","added":"2026-05-28","avoid":[],"distinctFrom":[{"ref":"Discovery","note":"Findings is the artifact; Discovery is the activity that produces it"},{"ref":"Discovery board","note":"Findings is the written document; Discovery board is the visual workshop artifact"}]},{"name":"Open question sticky","context":"Pre-sales","definition":"A yellow sticky note on a Discovery board marking an unknown that must be resolved before the SOW can be drafted. Created with the `role: open-question` state so it renders with the question-mark affordance. Discovery converts every unknown into an open question sticky (with a clear question someone owns) rather than leaving placeholder values like \"TBC\" in cells; the methodology rule is \"ask the question explicitly, not implicitly\". Once resolved in the session, the answer is captured inline on the sticky (in its answer field) so question and answer stay together.","author":"cuan (human)","added":"2026-05-28","avoid":["TBC","placeholder","unknown sticky","question card"],"distinctFrom":[]},{"name":"SOW","context":"Pre-sales","definition":"Statement of Work. The contract document defining what ValueStack will build, by when, for what fee. Authored from Findings; once signed, defines scope for delivery.","author":"CC (Mclaren)","added":"2026-05-28","avoid":[],"distinctFrom":[]},{"name":"Workstream block","context":"Pre-sales","definition":"The on-canvas rendering of a Workstream on a Discovery board. A single bounded container holding the workstream's title block, Data sources column, Workflow strip, Data outputs column, open question stickies, and (optional) Data model table. Multiple workstream blocks stack vertically on a page, separated by gaps.","author":"cuan (human)","added":"2026-05-28","avoid":[],"distinctFrom":[{"ref":"Workstream","note":"Workstream is the deliverable concept; Workstream block is its visual rendering on a Discovery board"}]}]},{"name":"Delivery: Airtable","description":"Terms specific to delivering Airtable-flavoured engagements. Other engagement types (Custom Build, Interim, Consulting) will get their own sections as they are scoped.","terms":[{"name":"Airtable base","context":"Delivery: Airtable","definition":"The top-level Airtable container holding tables, automations, and interfaces. The unit a single Airtable engagement typically maps to.","author":"CC (Mclaren)","added":"2026-05-28","avoid":[],"distinctFrom":[{"ref":"Airtable workspace","note":"a base lives inside a workspace; a workspace contains many bases"}]},{"name":"Airtable workspace","context":"Delivery: Airtable","definition":"Airtable's account-level container above bases. A client has one workspace; their engagement may produce one or more bases inside it.","author":"CC (Mclaren)","added":"2026-05-28","avoid":[],"distinctFrom":[{"ref":"Airtable base","note":"a workspace contains bases"}]},{"name":"Airtable interface","context":"Delivery: Airtable","definition":"An Interface Designer container inside an Airtable base. Holds one or more Airtable pages organised in a sidenav. The end-user-facing layer atop the base's tables.","author":"CC (Mclaren)","added":"2026-05-28","avoid":[],"distinctFrom":[{"ref":"Airtable page","note":"an interface contains pages"}]},{"name":"Airtable page","context":"Delivery: Airtable","definition":"A single screen inside an Airtable interface: the thing a user lands on when they click a sidenav item. Built from an Airtable layout (Blank, Dashboard, Record review, Record detail, Form, or a visualization layout) and composed of Airtable elements. Decomposition rule for Discovery: one page per distinct screen a user navigates to; activities done without navigating away are Airtable steps on that page, and behind-the-scenes Airtable automations are steps on the page that triggers them, not their own page.","author":"CC (Mclaren)","added":"2026-05-28","avoid":[],"distinctFrom":[{"ref":"Airtable interface","note":"a page lives inside an interface"},{"ref":"Airtable layout","note":"a page is built FROM a layout; the layout is the template"},{"ref":"Airtable element","note":"a page is COMPOSED OF elements"}]},{"name":"Airtable step","context":"Delivery: Airtable","definition":"An activity or event that happens on an Airtable page: something a user can do there (an Airtable element they interact with: submit a form, click a button, create or edit a record) or an event that fires (an Airtable automation runs, a notification sends). Captured during Discovery as part of a page's spec. Airtable steps may or may not be sequential: some are an ordered task, others are just \"this can happen here\". An optional type distinguishes user actions from events/automations.","author":"cuan (Novocure)","added":"2026-05-30","avoid":["step (bare","ambiguous)","activity","action (too narrow; an Airtable step can also be an event)"],"distinctFrom":[{"ref":"Airtable page output","note":"an Airtable step is the activity or event; an Airtable page output is the artifact it produces"},{"ref":"Airtable page","note":"steps happen on a page; the page is the surface"},{"ref":"Airtable element","note":"a step is the user action/event; an element is the on-page component the action happens through"}]},{"name":"Airtable page input","context":"Delivery: Airtable","definition":"What flows INTO an Airtable page in the discovery construct: the data, record, or artifact the page needs to do its job. In a workstream's page sequence, a page's input is the previous page's Airtable page output, so pages chain input → output end to end.","author":"cuan (Novocure)","added":"2026-05-30","avoid":["page input (bare","ambiguous with Canvas / generic)","input"],"distinctFrom":[{"ref":"Data sources","note":"Airtable page input is per-page, at one page's boundary; Data sources are the workstream-level systems-of-record column on a Workstream block"},{"ref":"Airtable page output","note":"a page input enters a page; a page output leaves it"}]},{"name":"Airtable page output","context":"Delivery: Airtable","definition":"What an Airtable page produces in the discovery construct, a concrete artifact: content, a form, an email, an event, or a record. A page is modelled as a transform: Airtable page input → (Airtable steps) → Airtable page output. One page's output becomes the next page's Airtable page input.","author":"cuan (Novocure)","added":"2026-05-30","avoid":["page output (bare","ambiguous with Canvas / generic)","output"],"distinctFrom":[{"ref":"Data outputs","note":"Airtable page output is per-page; Data outputs are the workstream-level column on a Workstream block"},{"ref":"Outcome","note":"an Airtable page output is a concrete artifact from one page; the Outcome is the business result of the whole workstream"}]},{"name":"Airtable view","context":"Delivery: Airtable","definition":"A saved, configurable way of displaying ONE table's records, living at the base/data layer (not in an interface). Has a view type (Grid, Calendar, Kanban, Gallery, Timeline, List, Gantt, Form) plus its own filter / sort / group / hidden-field config. A table can have many views. An Airtable element can optionally copy a view's settings as a one-time clone, but the element then sources from the table directly; it does not stay bound to the view.","author":"CC (Mclaren)","added":"2026-05-28","avoid":["view (ambiguous; \"view\" means many things across software)"],"distinctFrom":[{"ref":"Airtable element","note":"a view configures data at the base level; an element renders/acts at the interface level and sources from a table, not a view"},{"ref":"Airtable visualization","note":"a view is a base-level table display; a visualization is an interface page-layout type"}]},{"name":"Airtable element","context":"Delivery: Airtable","definition":"A building block placed on an Airtable page: Airtable's actual term for interface components. Includes record-display elements (Grid, Record list, Gallery, Kanban, Calendar, Timeline), plus Chart, Number, Button, Filter, Field, Record picker, Text, and Divider elements. An element's data source is a table from the base (optionally copying a view's settings), NOT a view.","author":"cuan (Novocure)","added":"2026-05-30","avoid":["visualization (Airtable's word for interface building blocks is \"element\"","not \"visualization\")","component","widget"],"distinctFrom":[{"ref":"Airtable visualization","note":"an element is any interface building block; a visualization is specifically a page-layout type"},{"ref":"Airtable layout","note":"elements are placed within a layout; the layout is the page template"},{"ref":"Airtable view","note":"an element renders at the interface level; a view configures data at the base level"}]},{"name":"Airtable layout","context":"Delivery: Airtable","definition":"The template an Airtable page is built from. Layout types: Blank, Dashboard, Record review, Record detail (formerly \"Record summary\"), Form, Overview, and the table-data \"visualization\" layouts (List, Gallery, Kanban, Calendar, Timeline, Grid). The layout sets the page's structure; Airtable elements fill it.","author":"cuan (Novocure)","added":"2026-05-30","avoid":[],"distinctFrom":[{"ref":"Airtable page","note":"a layout is the template; the page is the built screen"},{"ref":"Airtable visualization","note":"a visualization is one family of layout types, the table-data ones"}]},{"name":"Airtable visualization","context":"Delivery: Airtable","definition":"A table-data page-LAYOUT type in Interface Designer: List, Gallery, Kanban, Calendar, Timeline, or Grid. This is the ONLY place Airtable uses the word \"visualization\". It is NOT the word for interface building blocks (those are Airtable elements) and NOT a base-level view.","author":"CC (Mclaren)","added":"2026-05-28","avoid":["visualization (bare","ambiguous with general data viz; and don't use it for interface elements","see Airtable element)"],"distinctFrom":[{"ref":"Airtable element","note":"a visualization is a specific layout type; an element is any interface building block"},{"ref":"Airtable view","note":"a visualization is an interface page-layout; a view is a base-level table display"},{"ref":"Airtable layout","note":"a visualization is one family within the broader set of layout types"}]},{"name":"Airtable automation","context":"Delivery: Airtable","definition":"A trigger-action workflow configured at the base level (not in an interface). Each automation is one trigger (e.g. record created/updated/enters a view, form submitted, scheduled time) plus one or more actions (create/update record, send email, run script). Where an Airtable step is an event rather than a user action, it is usually an automation.","author":"cuan (Novocure)","added":"2026-05-30","avoid":["trigger (a trigger is one PART of an automation","not the whole)","workflow (ambiguous; see Workstream)"],"distinctFrom":[{"ref":"Airtable step","note":"an automation is the base-level mechanism; an Airtable step is the discovery-level activity/event, which may be realised by an automation"}]},{"name":"Channel","context":"Delivery: Airtable","definition":"A marketing or publishing surface in the client's content operation (e.g. Social, Paid Media, CRM, Pop-ups, Partnerships, Licence). Lives as a record in the client's Channels control table. Maps to a real-world team or distribution route.","author":"CC (Mclaren)","added":"2026-05-28","avoid":[],"distinctFrom":[{"ref":"Airtable page","note":"a Channel is a record in a control table; an Airtable page may be filtered to one Channel's content, but the page is the UI and the Channel is the data"}]},{"name":"Control table","context":"Delivery: Airtable","definition":"A small table holding enum-like seed values referenced from other tables via linked-record fields (statuses, types, categories, channels). Distinct from a single-select because choices are records that can carry metadata, sort order, links, and colour.","author":"CC (Mclaren)","added":"2026-05-28","avoid":[],"distinctFrom":[{"ref":"Operational table","note":"control tables hold a small fixed vocabulary; operational tables hold the records users interact with day-to-day"}]},{"name":"Operational table","context":"Delivery: Airtable","definition":"A table holding records that users create, edit, and progress through workflows day-to-day (e.g. Briefs, Content, Events). Distinct from control tables, which hold reference data.","author":"CC (Mclaren)","added":"2026-05-28","avoid":[],"distinctFrom":[{"ref":"Control table","note":"operational tables are where work happens; control tables are vocabulary the work refers to"}]},{"name":"Sandbox environment","context":"Delivery: Airtable","definition":"A separate copy of an Airtable base used for testing schema and interface changes before they go live in production. Enabled on Airtable Enterprise Scale plans. All schema work happens in the sandbox environment, then changes are promoted to the production base via the Sandbox changes panel.","author":"CC (Mclaren)","added":"2026-05-28","avoid":["sandbox (without \"environment\" it can mean many things: security sandbox","dev sandbox","etc.)","dev base","test base"],"distinctFrom":[]}]},{"name":"Canvas (tooling)","description":"Structural terms for the Canvas app at canvas.echoai.zone, the tool Discovery boards are built in. Prefixed \"Canvas\" so the tool's containers never collide with the domain terms above (Airtable page, the discovery Page, etc.).","terms":[{"name":"Canvas board","context":"Canvas (tooling)","definition":"A board in the Canvas app (canvas.echoai.zone): the top-level container a single discovery or visual workspace lives in. Always say \"Canvas board\", never bare \"board\", which is ambiguous.","author":"cuan (Novocure)","added":"2026-05-30","avoid":["board (ambiguous on its own)"],"distinctFrom":[{"ref":"Canvas sub-board","note":"a Canvas board contains sub-boards"},{"ref":"Discovery board","note":"a Discovery board is a populated Canvas sub-board with banner, legend, Workstream blocks; a Canvas board is the tool container that holds it"}]},{"name":"Canvas sub-board","context":"Canvas (tooling)","definition":"A tab-level container inside a Canvas board: one switchable surface that shapes are drawn on. Renamed from \"page\" so the tool's surfaces don't collide with Airtable page or the discovery-construct Page. A Discovery board is a populated Canvas sub-board. (The Canvas app still labels these \"page\" in its current UI; \"Canvas sub-board\" is the canonical term to adopt.)","author":"cuan (Novocure)","added":"2026-05-30","avoid":["page (collides with Airtable page and the discovery Page)","canvas page"],"distinctFrom":[{"ref":"Canvas board","note":"a Canvas board contains sub-boards"},{"ref":"Airtable page","note":"a Canvas sub-board is a drawing surface in Canvas; an Airtable page is a screen in an Airtable interface"}]}]},{"name":"Products & Platforms","description":"Terms for what ValueStack builds and runs, used by Canary and the PEA (Product Engineering Agents) flow. The chain is: a Client uses Products / Platforms; a Platform has one Repo and a Hosting; a Product is a configured instance on a configurable Platform.","terms":[{"name":"Platform","context":"Products & Platforms","definition":"A repo-backed, deployable base that ValueStack runs. Has exactly one Repo and a Hosting location. Two kinds: **single-instance** (e.g. Hancock, Canary, GenOps, YCO: the platform itself is the deliverable, no per-client configuration) and **configurable** (e.g. EchoAI: client Products are configured on top of it).","author":"cuan (Novocure)","added":"2026-06-03","avoid":[],"distinctFrom":[{"ref":"Product","note":"a Platform is the base that runs and holds the Repo + Hosting; a Product is a client-facing instance configured on a configurable Platform"},{"ref":"Repo (a Platform has one Repo; the Repo is just the code).","note":""}]},{"name":"Product","context":"Products & Platforms","definition":"A client-facing instance configured on a *configurable* Platform: a named Configuration for a Client (e.g. INSYTS = the EchoAI platform + config `insyts`, for client Y.CO). Single-instance Platforms have no separate Product. For tooling (e.g. a PEA dispatch), a Product resolves to its Platform's Repo + its own Configuration.","author":"cuan (Novocure)","added":"2026-06-03","avoid":[],"distinctFrom":[{"ref":"Platform","note":"a Product runs on a Platform; the Platform holds the Repo + Hosting"},{"ref":"Configuration (a Product is the instance; the Configuration is the settings that produce it).","note":""}]},{"name":"App","context":"Products & Platforms","definition":"Informal term for a single-instance Platform: software ValueStack wrote that has its own Repo and runs as one instance with no per-client configuration (e.g. Hancock, Canary, GenOps). Prefer \"Platform (single-instance)\" in data and models.","author":"cuan (Novocure)","added":"2026-06-03","avoid":["using \"app\" interchangeably with Product (an App is the deliverable itself; a Product is a configured instance on a Platform)."],"distinctFrom":[{"ref":"Product (an App/single-instance Platform is the deliverable; a Product is a configuration on a configurable Platform).","note":""}]},{"name":"Repo","context":"Products & Platforms","definition":"A GitHub repository: the codebase for a Platform. One Platform ↔ one Repo (e.g. EchoAI → `echoai`, YCO → `yco`, Hancock → `hancock`). The unit a PEA agent spins up to investigate or build.","author":"cuan (Novocure)","added":"2026-06-03","avoid":[],"distinctFrom":[]},{"name":"Hosting","context":"Products & Platforms","definition":"Where a Platform is deployed and run, typically a Railway project/instance (e.g. EchoAI runs on our Railway in its own project; YCO runs as a separate Railway instance). Tells a PEA agent which environment to reproduce/build against.","author":"cuan (Novocure)","added":"2026-06-03","avoid":[],"distinctFrom":[]},{"name":"Configuration","context":"Products & Platforms","definition":"The settings that turn a configurable Platform into a specific Product instance (e.g. config `insyts` on EchoAI yields INSYTS). Empty/absent for single-instance Platforms.","author":"cuan (Novocure)","added":"2026-06-03","avoid":[],"distinctFrom":[]},{"name":"Client","context":"Products & Platforms","definition":"An organisation ValueStack serves (e.g. Y.CO, ValueStack, Startino). A Client uses a set of Products (configured instances) and/or single-instance Platforms. Note Y.CO the Client is distinct from the YCO Platform (its software).","author":"cuan (Novocure)","added":"2026-06-03","avoid":[],"distinctFrom":[{"ref":"Platform / Product (a Client is the organisation; Platforms and Products are what they use).","note":""}]},{"name":"PEA (Product Engineering Agents)","context":"Products & Platforms","definition":"The agent team on hertz that takes a Canary board card (a bug or feature) and runs an engineering program against the right Repo + Configuration, investigating (reproduce / explore) or building (fix / feature). Triggered from Canary's admin tickets board; reports status, a checklist, deliverables, and verdicts back to the card.","author":"cuan (Novocure)","added":"2026-06-03","avoid":[],"distinctFrom":[]},{"name":"Al","context":"Products & Platforms","definition":"The PEA switchboard agent. Receives Canary's trigger, authenticates it, spawns the right program session for the (card-type × column), and streams timestamped status callbacks (and the confirmed Products involved) back to Canary.","author":"cuan (Novocure)","added":"2026-06-03","avoid":[],"distinctFrom":[]}]},{"name":"Delivery: Agentic Build","description":"Terms for turning a signed SOW into work an autonomous agent team can build. The pipeline runs Appendix to Deliverables to Agentic Mandates to Releases. This is the vocabulary the product-manager agent (Tom) authors and the engineering agents execute, so each term is written to be read and filled in by an agent.","terms":[{"name":"Appendix","context":"Delivery: Agentic Build","definition":"The section of a signed SOW that sets out the full contractual scope, organised by section for completeness rather than for build order. It is document structure only: where scope is written, not a thing that is tracked or delivered against directly. Every item in the appendix is harvested, one to one, into a Deliverable.","author":"cuan","added":"2026-06-18","avoid":[],"distinctFrom":[{"ref":"Deliverable","note":"the appendix is the written structure; a Deliverable is the tracked unit harvested from one appendix item"},{"ref":"SOW","note":"the appendix is a part of the SOW document"}]},{"name":"Deliverable","context":"Delivery: Agentic Build","definition":"A single contractual unit of scope, harvested one to one from an appendix item. The Deliverable, not the appendix, is the tracked entity, and because the mapping is one to one it is an exact representation of what the client purchased. Each Deliverable carries a status (Not covered, Covered, Delivered, Accepted) that rolls up from the Agentic Mandates referencing it, so all client-facing reporting runs off Deliverables. A Deliverable is delivered through one or more Mandates, and a single Mandate may deliver parts of several Deliverables.","author":"cuan","added":"2026-06-18","avoid":["appendix item (the appendix item is the written source; the Deliverable is the harvested tracked unit)","feature","requirement"],"distinctFrom":[{"ref":"Agentic Mandate","note":"a Deliverable is a unit of purchased scope; a Mandate is a unit of build work that delivers it"},{"ref":"Outcome","note":"a Deliverable is a contractual line item; an Outcome is the user-facing business result a whole Workstream delivers"}]},{"name":"Agentic Mandate","context":"Delivery: Agentic Build","definition":"A self-contained specification of a single verifiable outcome, written for an autonomous agent team to execute rather than for a human to interpret. It states the intended behaviour and the conditions that prove it complete, not how to build it: the ask, never the solution. It is the unit of work in an agent-built backlog and the build-side counterpart to a user story. Acceptance criteria are written as EARS statements (WHEN trigger the system SHALL response; IF edge or failure condition THEN the system SHALL safe response), with at least one criterion covering an unwanted-behaviour case, and those acceptance criteria ARE the definition of done. A Mandate is sized by verifiability, not by smallness: it carries exactly one done-condition, realised end to end, with a bounded and reviewable blast radius. Split it only when a second independent done-condition appears, or when the agent team cannot reliably complete and verify it in one pass, never because it feels big. A Mandate may carry a Checkpoint: a gate, human sign-off by default and extensible to an agent or automated review, that must clear before any dependent Mandate may start. Checkpoints exist to de-risk repetition: a risky pattern is proven once in a small Mandate behind a Checkpoint, then applied across many items in a single larger Mandate blocked by it.","author":"cuan","added":"2026-06-18","avoid":["user story (a user story is a deliberately vague placeholder for a human conversation; a Mandate is executed exactly as written)","task","ticket","card (too generic to carry the acceptance and traceability rules)"],"distinctFrom":[{"ref":"Outcome","note":"an Agentic Mandate is one buildable unit with its own acceptance criteria; an Outcome is the user-facing business result a whole Workstream delivers"},{"ref":"Deliverable","note":"a Mandate is a unit of build work; a Deliverable is the purchased scope it delivers"},{"ref":"Release","note":"a Mandate is one unit of work; a Release is a group of Mandates bounded by a Checkpoint"}]},{"name":"Intent","context":"Delivery: Agentic Build","definition":"The part of an Agentic Mandate that states what the Mandate is for and why, in one line, without saying how to build it. Written in the form \"When [situation], the system should [capability], so that [outcome]\", borrowing the situation-first framing of a job story so the agent gets a concrete circumstance to reason about rather than a persona. It is the ask; the solution is the agent team's job.","author":"cuan","added":"2026-06-18","avoid":[],"distinctFrom":[{"ref":"Acceptance criteria","note":"Intent states the goal; Acceptance criteria state the checkable conditions that prove the goal is met"}]},{"name":"Acceptance criteria","context":"Delivery: Agentic Build","definition":"The part of an Agentic Mandate that defines done, written as a list of EARS statements, each independently verifiable. Forms: \"WHEN [trigger] the system SHALL [response]\" for event behaviour, and \"IF [edge or failure condition] THEN the system SHALL [safe response]\" for unwanted behaviour, with at least one unwanted-behaviour criterion compulsory because agents tend to ship the happy path and skip the edges. The acceptance criteria ARE the definition of done: when they all pass, the Mandate is complete.","author":"cuan","added":"2026-06-18","avoid":["done-when","definition of done (the acceptance criteria are the definition of done; do not add a second field that repeats them)"],"distinctFrom":[{"ref":"Checkpoint","note":"Acceptance criteria are automatic, agent-verifiable conditions; a Checkpoint is a human or review gate sitting on top of them"}]},{"name":"Constraints","context":"Delivery: Agentic Build","definition":"The part of an Agentic Mandate that records the rules the build must honour: interfaces and contracts to preserve, naming and house conventions, and anything the agent team must not break. Constraints describe boundaries and contracts, never implementation steps, and never file paths, which go stale. This is where encoded ValueStack and client conventions live.","author":"cuan","added":"2026-06-18","avoid":[],"distinctFrom":[{"ref":"Acceptance criteria","note":"Constraints say how the work must be done and what it must not break; Acceptance criteria say what proves it complete"},{"ref":"Excludes","note":"Constraints govern the work the Mandate does do; Excludes lists the work it does not do"}]},{"name":"Excludes","context":"Delivery: Agentic Build","definition":"The part of an Agentic Mandate that lists what this Mandate deliberately does not do, so the agent does not gold-plate or wander into work that belongs to another Mandate. A scope boundary local to one Mandate.","author":"cuan","added":"2026-06-18","avoid":[],"distinctFrom":[{"ref":"Out of scope","note":"Excludes means not built by THIS Mandate, where another Mandate may still cover it; Out of scope means excluded from the build entirely"},{"ref":"Constraints","note":"Excludes says what this Mandate does not do; Constraints say how the work it does do must be done"}]},{"name":"Checkpoint","context":"Delivery: Agentic Build","definition":"A gate on an Agentic Mandate that must clear before any Mandate depending on it may start. Human sign-off by default, extensible to an agent or automated review later. When a Mandate carries a Checkpoint it is not done on acceptance alone: it is done when its Acceptance criteria pass and the Checkpoint clears. A Checkpoint closes a Release and unlocks the next, so Releases are the runs of Mandates between Checkpoints. Checkpoints exist to de-risk repetition: a risky pattern is proven once in a small Mandate behind a Checkpoint, then applied across many items in a single larger Mandate blocked by it.","author":"cuan","added":"2026-06-18","avoid":[],"distinctFrom":[{"ref":"Acceptance criteria","note":"a Checkpoint is a human or review gate; Acceptance criteria are the agent-verifiable conditions underneath it"},{"ref":"Release","note":"a Checkpoint is the gate; a Release is the group of Mandates the gate closes"}]},{"name":"Deliverable reference","context":"Delivery: Agentic Build","definition":"The part of an Agentic Mandate that records which Deliverables it delivers, in whole or in part. It is the many-to-many link between build work and purchased scope: a Mandate may reference several Deliverables, and a Deliverable may be referenced by several Mandates across several Releases. These references roll a Mandate's progress up into Deliverable status for client reporting, and they prove the build plan covers the whole appendix with nothing built outside it.","author":"cuan","added":"2026-06-18","avoid":["appendix reference (a Mandate references Deliverables","not the appendix directly)"],"distinctFrom":[{"ref":"Deliverable","note":"the Deliverable is the purchased unit; the Deliverable reference is the Mandate's link to it"}]},{"name":"Release","context":"Delivery: Agentic Build","definition":"A group of Agentic Mandates delivered between two user Checkpoints. The unit of delivery sequencing, and deliberately not the appendix order: Mandates are arranged into Releases for build order and risk, then a Checkpoint closes each Release and unlocks the next. Mandates can be dragged between Releases as the plan changes.","author":"cuan","added":"2026-06-18","avoid":[],"distinctFrom":[{"ref":"Agentic Mandate","note":"a Release is a group of Mandates; a Mandate is one unit of work inside it"},{"ref":"Checkpoint","note":"a Release is the group of work; a Checkpoint is the gate that closes it"}]}]}]}