Domain Glossary

This glossary defines the key terms and concepts used throughout Wayd. It is designed to help AI agents and developers understand the domain language.

Organization

Term	Definition
Team	A group of people that work together to deliver value. Has a Name, Code (unique 2-10 char identifier), Active Date, and Operating Model. Can be a member of a Team of Teams.
Team of Teams	A higher-level organizational unit that contains child teams and other teams of teams, forming the organizational hierarchy. Provides rollup visibility. Does not have backlogs or sprints. Has its own Operating Model holding only a Time Zone, used for its own rollups and never inherited by its child teams.
Team Code	A unique 2-10 character uppercase alphanumeric identifier for a team (e.g., PLATFORM, MOBILE).
Operating Model	Defines how a team works: Methodology (Scrum or Kanban), Sizing Method (Story Points, Effort, Size or Count), Time Zone (IANA id), Commitment Grace Period (days), Working Days, Holiday Calendar and, for Kanban only, an optional Cadence. Has a date range creating a history of changes; a sprint uses the model in effect on its planned start date.
Cadence	A Kanban team's optional reporting period on its operating model: a length of 1-8 weeks and an anchor date that one period starts on. Periods are worked out when read, never stored, and have no commitment or lifecycle. A Scrum team has none; its sprints are its cadence. A period cut short by a new operating model ends the day before it. Not a planning interval iteration, which slices every team by its own dates.
Methodology	The team's delivery approach. Scrum = sprint-based with time-boxed iterations. Kanban = continuous flow from product backlog.
Sizing Method	Which of a work item's estimates the team's metrics read: Story Points, Effort or Size, each its own work item field, or Count (each item counts as 1). The work process plays no part. An item with no value in the team's estimate is unestimated; another estimate never stands in, and 0 is a real estimate.
Team Membership	A date-ranged parent-child relationship between a team and a Team of Teams. States: Past, Active, Future. Only one active parent per team.
Allocation	The share of an employee's time (a whole percent, 1-100) a team or team of teams has over a date range, optionally in a team member role. Separate from membership: a non-member can be allocated, and a member can have none. An employee's allocations never total more than 100% on any day. Behind the Team Capacity Management feature flag. Not Work Distribution, the report that shows where a team's completed work went.
Time Away	A stretch of days an employee is away from every team they are allocated to, for a share of each day (1-100%), with a reason from a closed set (Paid time off, Business travel, Training, Other). Not only leave. Separate from allocation: it never counts toward the 100% limit and lowers the person's time on every team in proportion. Recorded by the person, anyone above them in the manager chain, or a time away administrator; only they are shown the reason. Behind the Team Capacity Management feature flag. Not a Team Day Off, which is a sprint day the whole team is off for some or all of.
Availability	How much of a person's allocated time a team has on a day: their allocation, on a day in the team's working week, that is not a holiday in the calendar they take, less the share of the day they are away, times their working day as a share of the system's. Derived when read, never stored. A team's capacity in person-days and a sprint day's working weight are both sums of it.
Working Day	How many hours a working day has. The system's (a scheduling setting, default 8) is the length of a person-day; an employee may have their own, such as 4 for a part-timer, the same on every team. Their allocation and time away are shares of their own day, so a 4-hour part-timer allocated 100% is 0.5 person-days a day against an 8-hour system day. Team days off are always a share of the system's. Behind the Team Capacity Management feature flag.
Person-day	The unit of capacity: one person allocated in full, and there, for one system working day. Hours are a display of it.
Capacity Plan	A team's capacity over a fixed range such as a sprint, shown as its people against the range's weeks, each expandable to days. Not stored: it is a view of the people's allocations, and editing a week or day changes their allocation for those days only. Behind the Team Capacity Management feature flag.
Holiday Calendar	A shared, named set of dated holidays, such as a country's. A team's operating model points at one, or the system default applies, for the days the whole team is off. An employee follows one too: the one assigned to them for where they work, otherwise the system default, the same on every team. Not a person's individual days off, which are Time Away.
Employee	An individual in the organization. Can be a member of multiple teams. May be synced from a people connector (Microsoft Entra ID via Graph, or Workday).
Work Email	One of the email addresses an employee is known by. Exactly one is the primary (mirroring Employee.Email); the rest are other work addresses the same person uses or used to use — typically ones left behind by a tenant or domain migration. Only work addresses are recorded; home and personal addresses are filtered out at the connector. Owned by the active people connector and fully replaced on each sync. Used to match people against systems that still reference an older address, such as Azure DevOps work items.
Functional Organization Chart	A visualization of the complete team hierarchy as of a specific date.

Planning

Term	Definition
Planning Interval (PI)	A fixed timeframe (typically 8-12 weeks) during which teams deliver value toward committed objectives. Contains iterations, objectives, and team associations. States: Future, Active, Completed.
Iteration	A time-boxed period within a PI, generated with the PI from an iteration length in weeks. Has a Name, Category (Development or Innovation and Planning, shown as IP), and Date Range. Aggregates metrics across all mapped team sprints and the PI's Kanban teams, measured over its dates. Not to be confused with a Sprint, which belongs to Work Management.
Sprint Mapping	The association of a team's sprint to a PI iteration. One sprint per team per iteration, and at most one iteration per sprint. Only Sprint-type sprints of the PI's teams can be mapped. Enables cross-team aggregate views.
Planning Interval Objective	A team's commitment to deliver a specific outcome within a PI. Has Status (NotStarted, InProgress, Completed, Canceled, Missed), IsStretch flag, Progress, optional Start and Target dates, and optional Health Check. Its Type (Team or Team of Teams) follows the kind of team that owns it.
Stretch Objective	An aspirational goal left out of the predictability denominator, so missing one costs nothing; completing one still counts toward the numerator. Contrasts with committed objectives.
Predictability	How much of what a PI's teams committed to they delivered. Formula: (Completed objectives, stretch included / Committed non-stretch objectives) × 100, capped at 100. Across the PI only Team objectives count; per team, all of the team's. None for a Future PI.
Objectives Locked	A PI flag that freezes the set of objectives after PI planning: none can be created or deleted, and each objective's name and stretch flag stay as they are. Status, progress, description and dates remain editable.
Plan Review	A team-by-team view of the PI for planning ceremonies. Shows objectives and risks per team with list and timeline views.
Risk	A potential circumstance that could impact delivery. Tracked with Status (Open/Closed), ROAM Category, Impact, Likelihood, Exposure, Assignee, and Follow-Up Date. Its team is chosen at creation and never changes.
ROAM	Risk categorization model: Resolved (eliminated), Owned (being managed), Accepted (acknowledged), Mitigated (impact reduced).
Exposure	Calculated risk severity from Impact + Likelihood, each Low=1, Medium=2, High=3: Low (sum less than 4), Medium (equals 4), High (greater than 4).
Roadmap	A visual timeline for planning work. Has Visibility (Public/Private), Managers (employees, min 1), State (Active, or Archived and read-only), and hierarchical Items (Activities, Milestones, Timeboxes). Date ranges are inclusive, so start and end may be the same day. Can be copied (the color palette is not). Optionally has a Color palette — an ordered set of named colors (one optional default) used to color activities and drive the timeline legend.
Activity	A roadmap item with an inclusive date range that can contain child items (other activities, milestones, timeboxes). Ordered within parent. Parent activities auto-expand to contain child dates; shrinking an activity behind its children is rejected; moving an activity without changing duration shifts the whole subtree.
Milestone	A roadmap item representing a single point in time (key date or achievement). Created through the API only.
Timebox	A roadmap item representing a fixed time period (e.g., a sprint or stage).
Planning Poker	Collaborative estimation using estimation scales and real-time voting via SignalR. Behind planning-poker feature flag.
Estimation Scale	A named set of values for estimation (e.g., Fibonacci: 1, 2, 3, 5, 8, 13). Minimum 2 values.
Poker Session	A real-time estimation event with a facilitator, estimation scale, and rounds. Immediately Active on creation.
Poker Round	One estimation within a session. Workflow: Voting → Revealed → Accepted. Can be Reset to re-vote.
Story Map	A user journey laid out as a grid of Steps × Swim Lanes (goals span their own steps' columns), sliced into releases. Aggregate root containing Goals, Swim Lanes, and Personas. Status: Active → Removed (archive is one-way; there is no un-archive). An archived map is read-only — every mutating method on the aggregate rejects. Behind story-maps feature flag.
Goal	The top level of a story map — what the user is trying to accomplish (the "backbone"). Ordered within the map. May have zero steps. Deleting a goal cascades to its steps and their tasks.
Step	A stage within a goal, occupying one column of the board. Ordered within its goal. May have zero tasks. Can be moved between goals.
Story Map Task	A unit of work under a step, positioned at the intersection of its step and a swim lane. Order is scoped per (step × swim lane) cell, not per step. Optionally links to one work item.
Swim Lane	A horizontal band slicing a story map into releases or stages. Every map has exactly one default lane (named "Tasks", Order 0) that cannot be renamed, reordered, or removed. Removing a lane reassigns its tasks to the default lane rather than deleting them.
Persona	An audience tag scoped to a single story map. Has Name, optional Description, and Color. Tagged on steps and tasks (goals are tagged only by inheritance in the UI). Deleting a persona untags it everywhere without deleting the tagged work.
Checklist Item	A sub-item of a story map task, with Name and IsChecked. Can be promoted into a full task in the same step, always landing in the default swim lane. Exposed via API; no board UI as of this writing.

Planning Metrics

Term	Definition
Total	Sum of a sprint's work items' estimates in its sizing method (Story Points, Effort or Size), or the number of work items under Count.
Completed	Items where status category is Done OR Removed. Includes both.
Remaining	Total minus Completed.
Completion Rate	(Completed / Total) × 100. Target: 80%.
Velocity	Completed work, as estimates in the sprint's sizing method or as items under Count. For a Kanban team with a Cadence, the Requirement-tier work that reached a Done-category status in each cadence period, by done date (Removed not counted), averaged over ended, whole periods.
Average Cycle Time	Mean days from Activated to Done for eligible items. Only Done items (not Removed) with both timestamps.
Unestimated	Count of a sprint's items with no value in its sizing method; 0 is an estimate. Indicates estimation gaps.
Time to Start	Days from work item creation to activation (how long work waited).
Cycle Time	Days from activation to completion. Formula: DoneTimestamp − ActivatedTimestamp.
Lead Time	Days from creation to completion (total request-to-delivery time).

Work Management

Term	Definition
Sprint	A short time-boxed period (typically 2 weeks) owned by a team, holding the work items assigned to it. Type: Sprint, or Iteration for one that is not a team's sprint (no team, or a team of teams). State: Future, Active, Completed, worked out when read from the sprint's actual dates (else its planned days) in its team's time zone. Can be Owned (Wayd) or Managed (external system, e.g. an Azure DevOps iteration). Mapped to PI iterations through a Sprint Mapping.
Sprint Type	Whether a sprint is comparable with the team's other sprints: Standard, or Non-standard (an IP sprint, a hackathon, a holiday sprint), which is left out of the team's sprint metrics (see Team Sprint Metrics) while its own metrics still show. Not to be confused with a sprint's Type (Sprint or Iteration). Worked out when read: the type the team set, else the one its mapped PI iteration's category declares (Development → Standard, Innovation and Planning → Non-standard), else Standard.
Team Sprint Metrics	A team's Velocity, Predictability and Say/Do across its most recent completed standard sprints: each sprint's values, their average and their range. Worked out when read from each sprint's scope, never stored. Left out, and listed with the reason: Non-standard sprints, sprints whose work item history is incomplete, and sprints with nothing committed. Measured over the organization's Sprint Window (a system setting, default 7, 3–12), the same for every team; the team's report can be run over another window.
Actual Start / Actual End	When the team started or completed a sprint, recorded in Wayd as instants and never synced. Without one, the sprint follows its planned dates in the team's time zone: it starts at the beginning of the first planned day (or when the previous sprint ended, if later) and ends at the end of the last planned day (or when the next sprint starts, where Azure DevOps dates overlap). The UI never calls these "default" dates: it shows Planned beside Actual, and an unrecorded actual as "—". Together they are the sprint's Active period (activeFrom/activeUntil in the API, end exclusive), which its state, timeline and countdown follow.
Commitment Point	When a sprint's committed scope is taken for metrics: its actual start, or else the end of the commitment grace period after the planned start (the end of the first planned day by default), in the team's time zone.
Open Sprint	A sprint the team has started and not completed. A team has at most one; starting the next sprint completes it at the same instant.
Work Item	The fundamental unit of work, synced from an external system. Has a Key (WorkspaceKey-Number), Title (kept in step with the source), Type, Status, StatusCategory, Priority, the estimates StoryPoints, Effort and Size (kept separately), Assignee, Team, Parent, Sprint, Project.
Work Item Key	Unique identifier in format WorkspaceKey-Number (e.g., PLAT-1234). Workspace key is 2-20 uppercase alphanumeric starting with a letter; the number is the item's id in the external system (its Azure DevOps work item id).
Workspace	A container for work items using a specific work process, synced from an external system (an Azure DevOps project). Has a Key, Name, Ownership (Owned/Managed), and IsActive flag; items are added or removed only while it is active.
Work Process	A configuration linking work types to workflows, synced from an external system (an Azure DevOps process) and only activated or deactivated in Wayd. Assigned to workspaces. Each type appears once. Cannot be deactivated while an active workspace uses it.
Work Process Scheme	A mapping of a work type to a workflow within a work process.
Work Type	A category of work item (e.g., Epic, Feature, User Story, Task, Bug). Name is immutable. Assigned to a level, which sets its tier; a synced type starts in the Other tier.
Work Type Tier	Grouping of work types by purpose: Portfolio (container, multi-level), Requirement (team work), Task (child items), Other (non-standard).
Work Type Level	Hierarchical ordering within a tier. System defaults: Epics (Portfolio L1), Features (Portfolio L2), Stories (Requirement L1), Tasks (Task L1), Other (Other L1). Only the Portfolio tier takes custom levels.
Workflow	A sequence of statuses defining how work items of one type progress, synced from the external system (an Azure DevOps work item type's states). Contains a workflow scheme mapping statuses to categories and order. Each status appears once; no count, coverage or ordering of categories is required. Not a Status Workflow.
Workflow Scheme	A mapping of a work status to a position in a workflow, with a status category and order. The category lives here, so the same status can be in different categories in different workflows.
Work Status	A specific state within a workflow (e.g., "New", "In Progress", "Done"). Name is immutable. Has no category of its own. Reusable across workflows.
Work Status Category	Fixed normalization set: Proposed (not started), Active (in progress), Done (completed), Removed (removed without completion). Enables cross-workflow metrics.
Work Item Dependency	A predecessor/successor relationship between work items. Tracks State (ToDo/InProgress/Done/Removed/Deleted), Health (Healthy/AtRisk/Unhealthy), and Scope (IntraTeam/CrossTeam).
Dependency Health	Calculated from both items' status and planned date (the last planned day of the sprint each is in; none, or a past date, is unplanned). Healthy = dependency done, predecessor planned and successor not, or predecessor planned on or before the successor. AtRisk = neither side planned. Unhealthy = predecessor Removed, successor already started while the predecessor is not done, successor planned and predecessor not, or predecessor planned after the successor. Unknown = the link was deleted.
Work Item History	A work item's tracked state over time, imported from the source's revisions as effective-dated periods. Answers what was true about an item at an instant, which sprint metrics need. Revisions are snapshots of the tracked fields as the source recorded them, not a field-level audit trail of who changed what. Deleted with the work item.
Work Item Hierarchy	Parent-child relationship. Only Portfolio tier types can be parents. A Portfolio tier child needs a higher-level parent; Requirement and Task tier items can sit under any Portfolio level.
Backlog	A team's unified view of all assigned work items across all workspaces. Visible in the team's Backlog section.
Work Distribution	Where a team's (or a team of teams' and every descendant team's) completed Requirement-tier work went over a date range, grouped by portfolio, program, project, strategic theme or work type. A team's work rolls up to the parent it had on the day each item was done.
No Project	Completed work where neither the item nor its parents link to a project. Its own group in every work distribution dimension except work type, where it is shown as a portion of each type. Distinct from No program / No theme, which is work on a project that lacks that level.
Estimate Coverage	The share of completed items from story-point-sized teams that carry an estimate (0 is an estimate). Shown on the Work Distribution report when measuring story points.
Share of Team Effort	A work distribution measure: each team's split measured in its own sizing method (story points, effort, size, or items for count-sized teams, as it sized on the day the work was done), then teams combined by their share of completed items, so story points are never added across teams.

Project Portfolio Management

Term	Definition
Portfolio	Top-level container for programs, projects, and strategic initiatives. Status lifecycle: Proposed → Active → Closed → Archived; activating and closing set today as its start and end dates. OnHold ↔ Active exists in the domain but has no endpoint, so a portfolio reaches OnHold only through import. Children can be created only while it is Active or OnHold. May assign one active scoring model to enable project priority scoring. Owns the project ranking for all projects in the portfolio.
Program	Groups related projects within a portfolio. Status: Proposed → Active (requires dates) → Completed/Canceled, or Proposed → Canceled. Only active programs accept new projects; an active program completes or cancels only once all its projects are closed. Only a Proposed program with no projects can be deleted.
Project	A timed endeavor with scope, timeline, and deliverables. Key is 2-20 uppercase alphanumeric. Status: Proposed → Approved (requires lifecycle) → Active (requires dates) → Completed/Canceled; approval is optional, so a Proposed project with dates can be activated directly. Uniquely among PPM records, a project can also move backwards — see Project Status Revert.
Project Key	A unique 2-20 character uppercase alphanumeric code identifying a project (e.g., APOLLO). Can be changed (cascades to task keys).
Project Lifecycle	A template of stages that projects go through. States: Proposed (editable) → Active (locked) → Archived. Must have min 1 stage to activate.
Project Lifecycle Stage	A template stage within a lifecycle (e.g., Initiation, Planning, Execution, Closing). Ordered. Immutable after lifecycle activation.
Project Stage	A concrete instance of a lifecycle stage on a project. Has Status (NotStarted/InProgress/Completed/Canceled), Date Range, Progress (0-100%), and Assignee roles. Date range is optional unless root tasks have dates, in which case it automatically rolls up to encompass the minimum start and maximum end dates of all tasks under the stage.
Project Task	An actionable work item within a project stage. Key: ProjectKey-Number. Type: Task (date range, 0-100% progress) or Milestone (single date, 0 or 100% only). Supports hierarchy (WBS) and Finish-to-Start dependencies. Parent task date ranges automatically roll up from child dates. A parent task cannot be manually shrunk behind its children's dates, nor can its dates be cleared while children have dates. Shifting a parent task shifts its dated descendants.
Project Rank	Opaque fractional sort key used to order projects within a portfolio. Every project receives a rank on creation. Users see the derived 1-based display position, not the raw rank value.
Portfolio Ranking Board	Portfolio detail section that shows Proposed, Approved, and Active projects in rank order. Portfolio Owners/Managers — and PPM Administrators — can drag projects to reorder them; score columns come from the current portfolio scoring model when assigned.
Delivery Leadership	The PPM membership rule that decides which records a user may change, evaluated in addition to the permission claim. An actor leads a record if they hold the Owner or Manager role on it or on any ancestor (project ← program ← portfolio); leadership inherits downward. Sponsors and project Members are deliberately excluded — they fund, oversee, or contribute, but don't run delivery. Gates status transitions, detail/timeline edits, role assignment, health checks, scores, and ranking. Does not gate viewing, creation, deletion, or bulk import.
PPM Administrator	Holder of Permissions.ProjectPortfolioManagement.Administer. Treated as leading every PPM record, substituting for Delivery Leadership but never for the permission claim itself. The only actor who can seed the first Owner on a new portfolio, which has no ancestor to inherit from. Included in the seeded Admin role.
Project Priority Score	The latest score recorded for a project using its portfolio's assigned scoring model. Shows the primary score value, scorer, timestamp, and model name.
Project Score Snapshot	An immutable score history entry for a project. Stores the scoring model id/key/name, criterion ratings, computed outputs, scorer, timestamp, and per-project sequence so prior scores remain meaningful after model or portfolio assignment changes.
Project Status History	An immutable record of one project status transition, appended by the aggregate itself so a status cannot change without being recorded. Stores the statuses moved from and to (from is null when the project enters its initial state), when, the acting user, and the employee they were linked to at that moment. Both are frozen at write time because the user-to-employee link is mutable. A row always represents movement — from and to can never be equal. Rows also carry a Source marking whether they were recorded as the change happened or reconstructed from the audit trail for projects predating the feature, a Reason (required on a revert, absent on forward transitions), and a per-project monotonic Sequence that establishes the true order. The history is append-only: a revert adds a row, never edits the one it supersedes, so a project may enter the same status more than once.
Project Status Revert	Moving a project backwards to an earlier status — the escape from an accidental close, a refunded cancellation, or a premature approval. Legal targets: Completed/Canceled → Proposed, Approved, or Active; Active → Proposed or Approved; Approved → Proposed. A status carries the same entry requirements whichever direction it is reached from, so returning to Approved still needs a lifecycle and returning to Active still needs dates — a project cancelled straight from Proposed may therefore only return to Proposed. Requires delivery leadership, a written reason (kept in the status history), and an open parent program and portfolio. Projects only; programs and portfolios have no equivalent.
Task Priority	Low, Medium, High, or Critical. Shown as color indicators in the UI.
Task Dependency	Finish-to-Start relationship between two tasks of the same project. Recorded, not enforced: a successor can start or finish whatever its predecessor's state. No cycle check. Soft-deleted (marked as removed, not permanently deleted). Managed through the API and MCP only; the Plan section neither shows nor edits them.
Strategic Initiative	A high-level strategic effort within a portfolio, tracked with KPIs and linked to the projects delivering it. Status: Proposed → Approved → Active → Completed, or Canceled from any open status. OnHold is defined but nothing moves an initiative into or out of it. Carries no strategic themes.
KPI	Key Performance Indicator on a strategic initiative. Has StartingValue, TargetValue, ActualValue (from latest measurement), Direction (Increase/Decrease), Checkpoints, and Measurements.
KPI Checkpoint	A planned target value at a specific date within a KPI. Has TargetValue and optional AtRiskValue threshold.
KPI Measurement	An actual recorded value at a specific date, which cannot be in the future, with the employee who recorded it. Most recent becomes the KPI's ActualValue.
Expenditure Category	Classifies project spending. Has IsCapitalizable, RequiresDepreciation, AccountingCode. Settings frozen after activation.
Projects Dashboard	The PPM triage page (replacing the earlier My Projects dashboard) for the projects of a scope — Me (projects where the user's employee holds a role, the default), another person, a portfolio, a program, or all projects — led by attention tiles (Unhealthy, At risk, Overdue tasks, No health check, Ending in 30 days).

Strategic Management

Term	Definition
Vision	The desired future state of the organization. Only ONE can be Active at any time. States: Proposed → Active → Archived; activating stamps the moment as its start, archiving as its end. Archived visions cannot overlap in dates. API only — no screens.
Strategy	The approach for achieving the vision. Status: Draft, Active, Completed or Archived, set directly with no enforced order. Independent of visions. API only — no screens.
Strategic Theme	A high-level organizational priority guiding investment decisions. States: Proposed → Active → Archived. Only Proposed deletable. Cross-domain: tags Projects and Programs in PPM (not strategic initiatives).
Effective Themes	A project's own strategic themes when it has any, otherwise its program's. The two sets replace each other, never combine. Used wherever a project's work is attributed to themes.

Status Workflows

Term	Definition
Status Workflow	The ordered set of statuses one owner type's records move through. Draft (editable) → Published (structure frozen, assignable) → Archived (read-only). IsSystem workflows are platform-seeded and cannot be edited, published or archived. Renames and reordering apply to a published workflow directly; a structural change means Clone → edit → Publish → Reassign.
Workflow Status	One stage: Name, Description, Category, Alias, Order. Statuses are added, removed or reclassified (category and alias) only while the workflow is a Draft, because records carry a denormalized copy of the category and alias; name, description and order can change until the workflow is archived.
Status Category	Proposed / Active / Done / Removed. The rollup a status belongs to, so counts work across differently-named statuses. Denormalized onto every record.
Alias	An int marking the one status carrying a well-known meaning for that owner type. Platform logic reads the alias, never the name — a renamed status still counts. Unique within a workflow; 0 means none.
Required Aliases	The aliases an owner type cannot function without, declared on its descriptor. GuardRequiredAliases refuses to publish a workflow missing any. Product: Active, Retired. Version/Release: Ready, Released, Withdrawn. Package: Released, Withdrawn. Deployment: In Progress, Succeeded, Failed, Rolled Back.
Workflow Owner Type	The kind of record a workflow governs (product.product, delivery.version, delivery.release...), registered at startup with its alias vocabulary. Keyed by string, not a database id. Fixed on a workflow at creation.
Workflow Assignment	Which workflow a scope's records use. ScopeId null is the organization-wide default and the only scope in use today.
StatusRemap	A transient mapping from every status of one workflow to one of another. AutoMap decides by alias, then exact name, then category-with-one-candidate; the rest are Unresolved and need a person. Never persisted — rebuilt server-side on confirmation.
Reassignment	Moving an owner type onto another workflow and migrating every existing record. Records move first and the assignment flips last, so an interrupted run is safely re-runnable — SwitchWorkflow is a no-op on an already-moved record.
StatusTransition	A move a record made: one recorded status change — from, to, actor, timestamp, sequence. Written by BaseDbContext draining the aggregate on save. RecordId is deliberately not a foreign key. Not to be confused with a WorkflowTransition.
WorkflowTransition	A move the workflow allows: FromStatusId → ToStatusId, a child of the workflow with its own id, carrying its Transition Conditions. Consulted only under the Restricted transition mode. Edited only in Draft (SetTransitions replaces the whole set with each move's conditions, keeping the ids of moves and conditions it keeps); removing a status removes its transitions; Clone copies them, conditions included, onto the new status ids.
Transition Mode	AnyToAny (the default, and every workflow's behaviour before transitions existed) or Restricted (only the workflow's transitions are allowed). Explicit rather than inferred from an empty set, so removing the last transition never reopens every move. Draft-only. A Restricted workflow publishes only for an owner type whose descriptor declares SupportsRestrictedTransitions (Product and the four delivery owner types). For an owner type that declares no Workflow Moves, every status must be reachable from the initial status and every Proposed or Active status must have a way out. For one that does, instead: every status is the initial one or aliased (a reassignment can map records anywhere, and no method leaves any other status), every Proposed or Active status has an allowed declared move out, and every required move is allowed.
Workflow Move	A move one of an owner type's named methods makes (Cut, Withdraw, Fail), declared on its WorkflowOwnerDescriptor as alias → alias, either end possibly the initial status, marked required or optional, with the condition kinds it accepts. Resolved against a workflow by StatusWorkflow.DeclaredMoves(). A restricted workflow must allow every required move; leaving out an optional one refuses the method that makes it. A transition no declared move covers accepts no condition. The delivery owner types declare theirs in ProductWorkflowOwners; none accepts a condition.
AllowedFrom	The statuses a move into a target is allowed from, carried on StatusRef by the workflow that resolved it (StatusWorkflow.TargetRef, IStatusResolver); null when any move is allowed. StatusTrackedEntity.ApplyStatus refuses a move whose current status is not in it, naming both statuses, so every aggregate enforces transitions without loading the workflow. A record's initial status and SwitchWorkflow are exempt.
Transition Condition	Something a move along a WorkflowTransition needs before a record may make it: a child of the transition with a Kind from the closed TransitionConditionKind enum, at most one of each kind per transition. RequiresReason needs a non-empty reason, recorded on the StatusTransition; RequiresPassedApproval is reserved for approvals (#1039) and cannot be attached until something evaluates it. Structural like the transition: Draft-only, copied by Clone, removed with its transition, recorded through WorkflowTransitionsChangedEvent (ConditionsChanged carries both ends). Enforced only under the Restricted mode; a record's initial status and SwitchWorkflow are exempt.
ConditionsFrom / MetConditions	What StatusRef carries about conditions alongside AllowedFrom: ConditionsFrom maps each allowed from-status to the conditions that move needs (set by TargetRef), and MetConditions holds the conditions the application layer evaluated as met. ApplyStatus checks self-checked kinds (a reason) itself and the rest against MetConditions, refusing with what is missing — "Moving from 'Sunset' to 'Retired' needs a reason."
Transition Condition Evaluator	An ITransitionConditionEvaluator decides one condition kind a record cannot check itself (a passed approval), registered per kind through the IScopedService scan. Handlers reach evaluators only through ITransitionConditionChecker.Evaluate, called before the aggregate method, which returns the target StatusRef with MetConditions filled in. A kind with no evaluator is unmet, and IsAvailable refuses attaching it to a transition. No evaluator ships yet.

Product Management

Term	Definition
Product	A node in the product catalog — product line, product, application, service, library, tool, module, or interface. Nests by containment; a node with no parent is a root. Durable, unlike the Projects that change it. Cannot become its own ancestor.
Product Type	What the organization calls a kind of node, stored as a table rather than an enum so the vocabulary stays editable. Carries IsReleasable. The seeded types are system types — never renamed, re-flagged or deleted, only deactivated. Any other type can be deleted only while no product carries it; one in use is deactivated, because existing products still resolve their type. Managed through the API only — no screen.
Releasable	The type flag deciding whether versions can be cut against a node. Grouping types (Product Line, Platform, Module, Interface) are not releasable. A product cannot be retyped onto a non-releasable type once versions exist. Note this gates the artifact, not the announcement: a Release may be announced under any node, and a product line — usually not releasable — is exactly what one sits under.
Product Tag / Tag Category	Classification along an axis (Platform, Tech Stack, Compliance). Categories group tags so "what platform is this?" is a query rather than prior knowledge; a category allows one value or several. Carries what does not change behaviour — the type system carries what does. Only the Platform category is seeded, as a read-only system category.
Product Dependency	One product needing another over a period — Storefront Web depending on Identity Service. Owned by the product that has the dependency. Carries a required Strength and optional Interaction Styles. Not composition: a product cannot depend on itself or on anything above or below it in the tree. Rolled up when read, so a parent's view includes its descendants' links without anything being stored twice. Ended when it stops (kept, still counts for the period it held); Removed only when it was never true (deleted, reason required). Not version-pinned.
Hard / Soft Dependency	The required Strength of a product dependency, in the AWS Well-Architected sense: hard means the product stops working without the other, soft that it degrades but keeps working. Fixed for a link's life — Change Terms ends the link and opens another, so past downtime is judged by the strength that held then.
Interaction Style	How two dependent products talk: Synchronous (the product waits for an answer, so the other must be up at that moment), Asynchronous (messages, so an outage becomes delay), or both. Optional; unrecorded is null, never "neither". Recording styles on a link that had none fills them in place; changing recorded ones is a change of terms.
Change Terms	The action that changes a product dependency's strength, interaction styles or both from a chosen day: it ends the current link the day before and opens a new one on the new terms. Refused on the link's first day, on an ended link and for a future day.
External Id	A product's identifier in the system that owns it — repository, pipeline, registry package. Set through its own command (LinkProductExternallyCommand), never as part of a details edit, so a rename cannot clear it. Nothing consumes it yet; it exists so a later automated feed can match hand-curated products.
Release	What was announced to customers — Wayd 2026.07. The product half of delivery, gathering whatever Versions and Release Packages carried it. Holds its own free-text version label (2026.07), distinct from the artifact version strings it carries (4.12.0). ProductId is optional: a release spanning product lines has no single owner, so requiring one would force a misleading choice. Never cut — cutting freezes an artifact's scope and belongs to a Version. States: Planned → Ready → Released, or Withdrawn. An empty release is legitimate, not a draft: a repackaging or pricing change is announced with nothing deployed.
Version	A versioned cut of one releasable product node — Wayd API 4.12.0. The artifact half of delivery: what was built, at what version, and when scope froze. Describes what was cut, never where it went — rollout lives on Deployment. A version with no deployment is a complete record. Its Number is free text, never parsed or compared. States: Planned → Ready → Released, or Withdrawn. CutAt (the build or tag that froze scope) and ReleasedAt (production receiving it) are Instants; TargetDate is a plan and stays a LocalDate. ReleasedAt cannot precede CutAt. Cutting is not a prerequisite for releasing, so a version may be marked released with no CutAt — historical import depends on this. Each lifecycle move is one-way: it cannot be cut twice, cannot be released twice, and a withdrawn one cannot be released (though a released one can be withdrawn). Owner key delivery.version.
Correct Dates vs Revert Release	Two different acts on a released record, and they exist on both Version and Release. CorrectDates says a date was written down wrongly: it changes the dates without touching the status (target date / CutAt / ReleasedAt on a Version; target / released date on a Release, which has no cut), and may add or clear one — except the released value, which cannot be emptied. A Release Package also has CorrectDates (target date / ReleasedAt) but no revert, and its released moment can only be changed, never added or cleared, because a set one is what closes its manifest. A version's CutAt and ReleasedAt and a package's ReleasedAt are Instants — what happened — while every target date, and a release's released date (an announcement is a business date), is a LocalDate. RevertRelease says the shipment or announcement never happened at all: it moves the status back, clears the released value, and requires a reason. Neither is a withdrawal, which asserts a real shipment was pulled and is terminal.
Date Correction	Fixing a date or moment recorded wrongly — a target date, or a version's CutAt / ReleasedAt — without moving the record's status. Distinct from Cut and MarkReleased, which assert the record moved and refuse to run twice; without it the only route to a corrected released date would be withdrawing and re-releasing, appending two status transitions that never happened. Writes no StatusTransition — it raises a *DatesCorrectedEvent carrying both ends of each change, so the correction lands in the audit trail only. Refused on a withdrawn record.
Release Package	Several component versions shipped as one coordinated unit, versioned in its own right and carrying a manifest of component versions. Where a package exists it owns the deployment and its components do not, so one pipeline run counts once. Not a SAFe Release Train — that is TeamOfTeams. A package carries no owning product and no owning release: it may serve more than one release, so membership lives in the ReleasePackageInclusions join and is queried the other way.
Manifest	A package's full statement of what shipped. Each entry carries a Kind — Changed or CarriedForward — so the unchanged components are recorded too. A component may appear only once. Each line names a version string and only optionally links to a Version record (VersionId), because a carried-forward line often names an upstream version never cut here. SetManifest is a whole-manifest replace, never a delta: entries carry no id, so an omitted line is a removed line. Refused once the package is released or withdrawn, and refused when empty.
Deployment	One version or package reaching one environment, with start, end, outcome, and artifact id. VersionId XOR PackageId — validated in three places, answered with 422 when both or neither is supplied. The substrate every delivery metric is computed from. States: In Progress → Succeeded, Failed, or Rolled Back. Never edited. Deleted (Delivery.Delete) only for one recorded by mistake — the measures stop counting it, so a real failure or rollback is recorded as one. Succeed/Fail only while incomplete; Roll Back only from Succeeded.
Deployment Environment	A named deploy target, globally scoped and ordered into rings for progressive rollout. Named DeploymentEnvironment because Environment would shadow System.Environment. Retired (PUT /{id}/active) as the everyday way out — historical deployments point at it. Deleting takes every deployment into it and, when there are any, also needs Delivery.Delete; DeploymentCount shows what either affects. Update and reclassify are refused on an inactive one.
Environment Category	Fixed enum (Development, Testing, Staging, Production, Other) — a classification, not a state. Other is the escape hatch for a target that fits no stage, so nothing is forced into a bucket that counts. Every production-scoped measure counts on the category, not the free-text name (prod, prd, live). Frozen on each deployment as it stood at the time, so a deployment's category may legitimately differ from its environment's today. Reclassifying raises its own event and changes what is counted from then on; it rewrites nothing already recorded.
Delivery Metrics	Deployment Frequency and Change Failure Rate, computed from production deployments. Lead Time for Changes and Time to Restore Service are reported as explicitly unavailable — with reasons — rather than approximated, so "not measured" is distinguishable from "zero".

Identity & Access

Term	Definition
Identity Provider (OIDC Provider)	A configured single sign-on source (Microsoft Entra ID or a generic OIDC issuer), stored as a row in Identity.OidcProviders. The database is the sole source of truth; providers are managed via Settings → Access → Identity Providers.
UserIdentity	The link between an ApplicationUser and a login provider, keyed by (Provider, ProviderTenantId, ProviderSubject). At most one active row per user; every authentication path resolves through this table.
Role	A named permission group assigned to users. One system role (Admin) is seeded and protected; admins can create custom roles.
Auto-Registration (JIT Provisioning)	Creating a Wayd account automatically the first time an unknown user signs in through an identity provider. Governed by a per-provider registration policy; off by default (secure by default). Microsoft Entra ID providers only: a Generic OIDC provider never creates an account, so its users need an existing account whose move to it was staged.
Registration Policy	The per-provider settings that govern auto-registration: AllowAutoRegistration (master switch), RequireEmployeeRecord (employee-match gate), and DefaultRoleId (role for new users). Modeled as a RegistrationPolicy value object whose dependent fields are only meaningful while auto-registration is enabled.
Employee-Record Gate	The RequireEmployeeRecord policy: when on, auto-registration is restricted to users whose email matches an existing Employee. Turning it off grants accounts to anyone who can authenticate through the provider.
Default Role	The role assigned to auto-registered users for a provider (DefaultRoleId); required when auto-registration is enabled (no implicit fallback). Protected by a foreign key — a role pinned as a default cannot be deleted until the provider is repointed.
First-User Bootstrap	The first user to sign in to an empty deployment is always created and made Admin, bypassing the registration policy so a fresh install cannot lock itself out.
Identity Migration	Admin-staged moves that preserve ApplicationUser.Id: Entra tenant migration, cross-provider migration (OIDC→OIDC or Wayd→OIDC), and immediate OIDC→local conversion.

Cross-Cutting Concepts

Term	Definition
Ownership	Whether an object is Owned (Wayd-managed), Managed (external system, read-only in Wayd), or System (immutable Wayd defaults).
Link	A cross-entity association between any Wayd object and an external URL. Simple name + URL pair.
Connection	A configured integration with an external system via a Connector (e.g., Azure DevOps). Includes auth and endpoint config.
Connector	A configurable integration type that enables a specific external service to plug into Wayd (e.g., AzureDevOps, Entra, AzureOpenAI). Each connector declares the capabilities it supports (WorkItems, People, AiProvider); a multi-surface connector can support several through one connection. Multiple connections per connector type are allowed.
Connector Capability	A discrete integration surface a connector supports, named for the resource or service provided. WorkItems routes through WorkSyncRunner; People routes through PeopleSyncRunner; AiProvider connectors aren't synced. The capability — not the specific connector — drives which background job and Sync History view applies. Each capability carries a display category (its Display(GroupName), e.g. "Work Management") that groups the connector picker UI.
External Identity Mapping	Links a user in an external delivery system (an Azure DevOps identity, later a Jira account or GitHub user) to a Wayd Employee, so synced work can be attributed. Keyed on the external system's stable identity id rather than an email address, which changes. Status is Unmapped, AutoMatched (matched by address, revisable by a later sync), ManuallyMapped, or Ignored — the last two are admin decisions a sync never overwrites. Scoped per connection; managed on the connection's People tab.
MCP Server	Wayd's API exposed as agent tools over the Model Context Protocol: the hosted /mcp endpoint on the API (behind the mcp-server feature flag; sign-in or a Personal Access Token) and the @wayd/mcp npm package, with the same tool names. Tools act as the user, under the same permissions. See MCP Server.
Feature Flag	A toggle controlling feature visibility. Defined in code, stored in database, managed via Settings UI. New flags seeded on startup, disabled unless the definition sets DefaultEnabled.
Health Check	A status indicator (Healthy, AtRisk, Unhealthy) with an optional note and an expiration, which must be in the future. Recorded on PI objectives and projects. A record has at most one current check: a new one ends the current one at that moment, and once it expires the record has no health (shown as Unknown).
Scoring Model	A reusable formula-driven model for rating items. Contains criteria, optional rating scales, ordered output formulas, and exactly one primary output. Lifecycle: Proposed (editable) → Active (assignable/locked) → Archived.
Scoring Criterion	A scoring-model input that a user rates. Has a unique token for formulas, optional description, optional weight, and optional rating scale.
Scoring Output	An ordered formula in a scoring model. Outputs can reference criterion tokens and earlier output tokens; one output is primary and becomes the score.
Rating Scale	A named set of ordered rating levels on a scoring model. Criteria can reference a scale so raters select standardized labels/values instead of entering a raw number.
SystemContext	Identifies which domain references a work item (e.g., Planning Interval Objectives, Projects). Used for work item references.
Import Run	One submitted CSV file (ImportProcess) and what became of each of its rows. Queued to a background worker; the post waits ~5 s and answers with the run (200 finished, 202 in flight). An import is either Per Row (rejected rows reported, the rest kept; saved in chunks of 500) or Atomic (one transaction) or Per Group (every row sharing a group key applies together or not at all, and the other groups are kept; chunks never split a group). Each import declares its own row cap: 50,000 for employees and product dependencies, 10,000 for the rest. Rows are keyed by the caller's ImportId (≤128 chars, case-insensitively unique per file, never written onto created records). Tried at most 3 times; stalled runs are reclaimed by import-stall-recovery; row payloads are discarded 30 days after completion by import-retention-sweep. Submitted from and listed under Settings → System → Imports, or posted directly to each area's import endpoint.
Submission Group	An optional caller-chosen GUID (submissionGroupId query parameter) recorded on every run posted under it, so files submitted as one operation — a wayd-data seed, an export split to fit the row cap — can be found together. A label only: it links nothing and changes no run's outcome. An empty GUID is rejected.

Technical Terms

Term	Definition
Bounded Context	Each domain service (Work, Organization, etc.) is a bounded context with its own ubiquitous language and models.
Aggregate Root	The primary entity ensuring consistency in a cluster of related objects. Feature folders organized by aggregate root.
Value Object	An immutable object defined by attributes, not identity (e.g., WorkItemKey, ProjectKey, FlexibleDateRange, Progress).
Domain Event	A notification that something significant happened in a domain, published for cross-context communication (e.g., TeamCreatedEvent, StrategicThemeActivatedEvent).
Command	A request to change state (write operation). Dispatched through IDispatcher (Wolverine) to its handler. Returns Result<T>.
Query	A request to read state (read operation). Dispatched through IDispatcher (Wolverine) to its handler. Returns Result<T>.
Result	A functional return type (Result<T>) from CSharpFunctionalExtensions. Explicitly represents success or failure without exceptions.
Work Process Scheme	Links a work type to a workflow within a work process.
Workflow Scheme	Maps a work status to a position (order) and category within a workflow.
FlexibleDateRange	A value object with required start date and optional end date. Used by portfolios, project stages and tasks, strategies, product dependencies, and other entities with open-ended timelines.
LocalDateRange	A value object with required start and end dates. Used by PIs and their iterations, roadmaps, programs, projects, and strategic initiatives. Sprints use their own IterationDateRange.