agentme 0.34.0 → 0.35.0

package/.xdrs/agentme/bdrs/operations/404-team-roles-and-specialists.md

@@ -0,0 +1,274 @@
+---
+name: agentme-bdr-policy-404-digital-product-roles-team-specialists
+description: Defines team-level roles and specialist roles — Product Owner, Project Manager, Business Analyst, AI Business Analyst, AI Lead, AI Engineer, Tech Lead, Backend Engineer, Frontend Engineer, DevOps/Infra Engineer, Full Stack Engineer, and shared specialists. Use when staffing, onboarding, or assigning responsibilities within a product team.
+apply-to: All roles that belong to or support a product team
+valid-from: 2026-08-30
+---
+
+# agentme-bdr-policy-404: Digital product roles — team & specialists
+
+## Context and Problem Statement
+
+Product teams require a well-defined set of roles covering product ownership, project coordination, business analysis, AI and engineering execution, and specialist support. Without explicit definitions of responsibilities, authority boundaries, and skill requirements at the team level, teams experience unclear ownership, misaligned expectations, and delivery gaps.
+
+What roles belong to or support a product team, and what does each role own?
+
+## Decision Outcome
+
+**A defined set of team-level roles and shared specialist roles with explicit responsibilities, authority boundaries, and skill requirements**
+
+### Details
+
+#### 01-team-roles
+
+The following roles MUST belong to a product team. Some roles are shared across squads within the team; others are dedicated to a squad.
+
+---
+
+**Product Owner (PO)**
+
+*Purpose*: Own the product vision for the team's scope, define sprint goals, and ensure team priorities align with broader OKRs.
+
+*Responsibilities*:
+- Define and maintain the product vision for the team
+- Set sprint goals and prioritise the team backlog
+- Align team-level OKRs with Product Manager direction and execute against Tactical OKRs set by the PM
+- Define and track Operational OKRs for the team's day-to-day execution, when applicable
+- Accept or reject completed work against acceptance criteria
+- Communicate product direction to stakeholders and team members
+
+*Shared across squads*: Yes — the PO connects to all squads in the team.
+
+*Soft skills*: Vision articulation, prioritisation under uncertainty, stakeholder management, decisiveness, facilitation
+
+*Hard skills*: Backlog management, OKR definition and tracking, user story writing, roadmap planning, basic domain knowledge of the product area
+
+*Common activities*: Sprint planning, backlog refinement, sprint reviews, stakeholder presentations, OKR reviews, acceptance testing participation
+
+---
+
+**Project Manager (PjM)**
+
+*Purpose*: Own stakeholder management, reporting, and cross-team coordination. Proactively unblock the team by connecting priorities and people across organisational boundaries.
+
+*Responsibilities*:
+- Manage relationships with external stakeholders and report on progress
+- Identify and resolve cross-team dependencies and scheduling conflicts before they block delivery
+- Coordinate cross-squad dependencies within the team
+- Track risks, assumptions, issues, and dependencies (RAID)
+- Facilitate communication between the team and external parties
+
+*Authority*: No authority over technical or product decisions. Facilitates and connects; does not override PO or Tech Lead decisions.
+
+*Soft skills*: Communication, relationship management, proactive problem-solving, negotiation, organisation, cross-team coordination
+
+*Hard skills*: Project planning, risk management, reporting, dependency tracking, facilitation, RAID log management
+
+*Common activities*: Stakeholder updates, dependency mapping sessions, risk reviews, cross-team syncs, status reporting, escalation facilitation
+
+---
+
+**Business Analyst (BA)**
+
+*Purpose*: Understand what needs to be built and translate business problems into clear, implementable requirements for non-AI features and processes.
+
+*Responsibilities*:
+- Research business problems through stakeholder interviews, process observation, and analysis — focusing on changes to processes and systems that contribute to Tactical OKR objectives
+- Model as-is and design to-be business processes
+- Define system requirements at requirement level: data inputs/outputs, business rules, human interactions, and external dependencies
+- Write user stories and acceptance criteria at a level implementable within a few days
+- Support engineers during implementation by clarifying requirements
+
+*Squad assignment*: Ideally one BA per squad, working ahead on upcoming features while available for in-sprint requirement clarification. May move between squads when demand shifts (self-organised with PO awareness).
+
+*Soft skills*: Curiosity, structured thinking, stakeholder communication, facilitation, attention to detail
+
+*Hard skills*: Business process modelling (BPMN or equivalent), requirements writing, user story authoring, process analysis, data mapping
+
+*Common activities*: Stakeholder interviews, process workshops, requirements documentation, backlog refinement support, acceptance criteria authoring, sprint demo observation
+
+---
+
+**AI Business Analyst (AI BA)**
+
+*Purpose*: Define what needs to be built for AI-powered solutions by translating business needs into clear, implementable AI requirements — covering workflows, agents, models, integrations, controls, and test criteria.
+
+*Responsibilities*:
+- Research business problems through analysis, stakeholder interviews, and process discovery
+- Design target business processes, AI workflows, agents, models, and required system integrations
+- Identify AI opportunities, risks, controls, and regulatory requirements
+- Define data inputs, outputs, business rules, human interactions, and external dependencies for AI systems
+- Specify which models, agents, and workflows need to be implemented, and the detailed input/output of all internal and external systems involved
+- Create detailed user stories and acceptance criteria that engineers can implement within a few days
+- Define test and evaluation requirements for AI systems
+
+*Research boundary*: The AI BA researches business problems, requirements, and AI opportunities before implementation begins. The AI Engineer researches technical approaches, model selection, data characteristics, and evaluation methods during implementation. These boundaries must not blur.
+
+*Squad assignment*: Same mobility rules as BA. AI BA and BA may exchange squad positions depending on which phase the squad is in and whether AI or non-AI features dominate.
+
+*Accountability*: The AI BA owns WHAT is required — business requirements, AI workflows, data definitions, controls, and acceptance criteria. Engineering teams own HOW the solution is implemented, including architecture, technology choices, infrastructure, security, and deployment.
+
+*Deliverables*: Business and AI requirements, process and workflow designs, AI agent and model specifications, integration and data requirements, risk and control assessments, test and evaluation requirements for AI systems, epics, features, and user stories
+
+*Soft skills*: Curiosity about AI capabilities and limits, structured thinking, stakeholder communication, ability to bridge business and technical language, attention to regulatory and ethical risk
+
+*Hard skills*: AI system design, prompt engineering concepts, AI workflow and agent specification, business process modelling, requirements writing, data input/output definition, AI risk and control frameworks, regulatory awareness (EU AI Act, sector-specific rules)
+
+*Common activities*: AI opportunity workshops, stakeholder interviews, AI workflow design, agent specification authoring, risk and control assessment, acceptance criteria for AI outputs, backlog refinement support
+
+---
+
+**AI Lead**
+
+*Purpose*: Own the technical design of AI implementations within the team — architectures, platforms, implementation order, and output quality standards — and develop AI engineers through mentoring and pairing.
+
+*Responsibilities*:
+- Design the technical architecture for tests, models, agents, and workflows
+- Define implementation platforms and tooling for AI development
+- Sequence AI implementation work and define quality and monitoring standards for AI outputs
+- Refine user stories related to AI development with sufficient technical detail
+- Mentor AI Engineers through pairing, code review, and knowledge sharing
+- Co-design integrated features with Tech Lead (tiebreaker on AI component decisions)
+
+*Shared across squads*: Yes — the AI Lead connects to all squads in the team.
+
+*Soft skills*: Technical leadership, mentoring, clear communication of complex AI concepts, cross-functional collaboration, pragmatic decision-making
+
+*Hard skills*: ML/AI system architecture, LLM and agent frameworks, model evaluation and observability, MLOps, prompt engineering, AI safety and testing practices, Python, relevant ML libraries
+
+*Common activities*: AI architecture design sessions, technical story refinement, AI code reviews, pairing sessions with AI Engineers, model evaluation design, cross-lead technical alignment with Tech Lead
+
+---
+
+**AI Engineer**
+
+*Purpose*: Implement AI components — tests, models, agents, and workflows — according to the technical design provided by the AI Lead.
+
+*Responsibilities*:
+- Implement models, agents, and AI workflows to specification
+- Build evaluations (evals), regression tests, and datasets for AI systems
+- Research technical approaches, model selection, data characteristics, and evaluation methods during implementation (not business requirements — that is AI BA scope)
+- Perform data analysis to support model development and evaluation
+- Raise technical blockers and edge cases to the AI Lead
+
+*Soft skills*: Curiosity, structured problem-solving, willingness to experiment and discard, attention to evaluation rigour
+
+*Hard skills*: Python, ML frameworks (PyTorch, scikit-learn, or equivalent), LLM and agent frameworks (LangChain, LangGraph, or equivalent), prompt engineering, evaluation design, data analysis, experiment tracking
+
+*Common activities*: Model and agent implementation, eval authoring, dataset creation and curation, data analysis, technical research, code review participation, pairing with AI Lead
+
+---
+
+**Tech Lead**
+
+*Purpose*: Own the technical design of non-AI implementations — services, choreographers, web pages, app pages, CI/CD, monitoring, and incident procedures — and develop engineers through mentoring and pairing.
+
+*Responsibilities*:
+- Design technical architecture for services, choreographers, web pages, and mobile app pages
+- Define monitoring, alerting, and Change Management procedures integrated with CI/CD
+- Define and maintain Incident Management procedures
+- Sequence engineering implementation work
+- Refine user stories related to engineering with sufficient technical detail
+- Mentor Engineers through pairing, code review, and knowledge sharing
+- Co-design integrated features with AI Lead (tiebreaker on system boundary decisions)
+- Escalate to Solution Architect when an Epic requires new cross-system standards or integrations; escalate to Principal Engineer when new engineering standards are needed
+
+*Shared across squads*: Yes — the Tech Lead connects to all squads in the team.
+
+*Soft skills*: Technical leadership, mentoring, structured communication, cross-functional collaboration, pragmatic decision-making under uncertainty
+
+*Hard skills*: Software architecture, API design, event-driven systems, CI/CD pipelines, observability and alerting, incident management, security engineering basics, relevant languages and frameworks used by the team
+
+*Common activities*: Architecture design sessions, technical story refinement, code reviews, pairing sessions with Engineers, incident post-mortems, CI/CD pipeline design, cross-lead technical alignment with AI Lead
+
+---
+
+**Backend Engineer**
+
+*Purpose*: Implement server-side software components — APIs, business workflows, batch processes, event-driven integrations, and database access layers.
+
+*Responsibilities*:
+- Design and implement RESTful and event-driven APIs
+- Build business logic, workflows, and batch processing components
+- Develop database access layers and manage schema migrations
+- Implement integrations with external systems and third-party services
+- Support incident investigation for backend services
+
+*Hard skills*: Backend languages (Java, Go, Python, Node.js, or equivalent), API design, SQL and NoSQL databases, event-driven systems, containerisation
+
+*Common activities*: API implementation, data layer development, external integration work, schema migrations, code review participation, incident support
+
+---
+
+**Frontend Engineer**
+
+*Purpose*: Implement user-facing software components — web applications, mobile apps, and UI interactions.
+
+*Responsibilities*:
+- Build web pages, single-page applications, and responsive UI components
+- Implement mobile app screens and navigation flows (where applicable)
+- Integrate frontend with backend APIs and services
+- Ensure accessibility, performance, and cross-browser or cross-platform compatibility
+- Collaborate with UX Designers on interaction and visual design implementation
+
+*Hard skills*: HTML/CSS, modern frontend frameworks (React, Vue, Angular, or equivalent), mobile development (React Native, Flutter, or equivalent where applicable), API integration, browser and mobile performance tooling
+
+*Common activities*: UI component implementation, API integration, accessibility and performance testing, mobile screen development, code review participation
+
+---
+
+**DevOps/Infra Engineer**
+
+*Purpose*: Own the delivery pipeline and cloud infrastructure that enables teams to ship and run software reliably — covering both CI/CD automation and cloud provisioning.
+
+*Responsibilities*:
+- Build and maintain CI/CD pipelines, deployment automation, and release procedures including blue/green deployments and automated rollouts
+- Design and provision cloud infrastructure using templates and infrastructure-as-code blueprints
+- Manage networking, connectivity, certificates, and platform-level security controls
+- Define validation scripts and deployment checks that gate production releases
+- Monitor infrastructure health and respond to platform-level incidents
+
+*Hard skills*: CI/CD tooling (GitHub Actions, GitLab CI, or equivalent), cloud platforms (AWS, Azure, GCP, or equivalent), infrastructure-as-code (Terraform, Pulumi, or equivalent), containerisation and orchestration (Docker, Kubernetes), networking fundamentals
+
+*Common activities*: Pipeline authoring and maintenance, cloud resource provisioning, infrastructure monitoring, deployment procedure definition, certificate and connectivity management, incident response for platform issues
+
+---
+
+**Full Stack Engineer**
+
+*Purpose*: Implement non-AI software components across the full stack — APIs, workflows, web pages, mobile apps, CI/CD pipelines, database access, and event-based flows. Suited to teams and contexts where frontend and backend work are tightly coupled or where a generalist profile is preferred over specialisation.
+
+*Responsibilities*:
+- Implement services, APIs, database access layers, event-based flows, and non-AI workflows
+- Build and maintain CI/CD pipelines
+- Implement web pages, mobile app screens, and frontend components
+- Write and maintain scripts and automation for platform and operational needs
+- Support AI Engineers with software engineering knowledge gaps (e.g., API integration, data pipelines, infrastructure)
+
+*Soft skills*: Breadth of technical knowledge, pragmatism, collaborative problem-solving, ownership of delivered quality
+
+*Hard skills*: Full stack development (frontend and backend), API design and implementation, database access (SQL and NoSQL), event-driven systems, CI/CD tooling, containerisation, scripting, mobile development (where applicable)
+
+*Common activities*: Feature implementation, API and data layer development, CI/CD pipeline work, code review participation, pairing with AI Engineers, frontend development, incident support
+
+#### 02-specialists
+
+Specialists are professionals with focused domain expertise who contribute to specific phases of product delivery. They MAY be shared across multiple product teams or embedded within a specific team when the scope or duration of work justifies it. Teams SHOULD plan specialist involvement proactively — engaging them ahead of the phases where their input is needed rather than reactively.
+
+| Specialist | Purpose | Typical engagement |
+|---|---|---|
+| UX Designer | Design user interactions, information architecture, and visual language for user-facing features | Embedded for user-facing feature phases; shared otherwise |
+| Tester / QA Specialist | Define test strategies, execute exploratory and structured testing, and validate acceptance criteria beyond automated test coverage | Embedded during high-complexity delivery phases; shared for periodic quality reviews |
+| Communication Specialist | Author internal and external communications, release announcements, and user-facing documentation | Shared; engaged at release and major milestone points |
+| Journalist / Technical Writer | Produce structured content — user guides, API documentation, internal knowledge bases | Shared or embedded when documentation volume is significant |
+| Business SME (Subject Matter Expert) | Validate requirements and processes against business domain knowledge; bridge between business stakeholders and product teams | Shared; engaged during requirements and validation phases |
+
+## References
+
+- [`_core-adr-policy-016`](../../../_core/adrs/principles/016-policy-subjects.md) — Policy subjects: BDR operations subject definition
+- [`_core-adr-policy-017`](../../../_core/adrs/principles/017-policy-numbering-ranges.md) — Policy numbering: BDR operations block 401–500
+- [`agentme-bdr-001`](../principles/001-company-organizational-levels.md) — Company organisational levels: Group, Company, and Business Unit definitions
+- [`agentme-bdr-002`](../principles/002-okr-framework.md) — OKR framework: Strategic, Tactical, and Operational OKR definitions
+- [`agentme-bdr-003`](../principles/003-product-delivery-value-flow.md) — Product delivery value flow: end-to-end chain from Strategic OKRs to fulfilled Tactical OKRs
+- [`agentme-bdr-402`](402-digital-product-roles.md) — Digital product roles (org & cross-team): PM, Principal Engineer, Solution Architect, and team structure context
+- [`agentme-bdr-403`](403-product-team-composition.md) — Team composition models, squad dynamics, and known structural gaps

package/.xdrs/agentme/bdrs/principles/001-company-organizational-levels.md

@@ -0,0 +1,61 @@
+---
+name: agentme-bdr-policy-001-company-organizational-levels
+description: Defines the Group, Company, and Business Unit taxonomy used to describe how organisations are structured. Use when referencing org levels, structuring teams, or assigning OKR ownership.
+apply-to: All contexts that reference company organizational structure
+valid-from: 2026-08-30
+---
+
+# agentme-bdr-policy-001: Company organizational levels
+
+## Context and Problem Statement
+
+Policies for teams, OKRs, and product structures reference organisational levels — Group, Company, and Business Unit — without a shared definition. Without a common taxonomy, documents use these terms inconsistently, leading to ambiguity about who sets which goals, who owns which teams, and how accountability flows.
+
+How should the organisational hierarchy above the product team be defined so that all agentme policies can reference it consistently?
+
+## Decision Outcome
+
+**A three-level taxonomy — Group, Company, and Business Unit — with an optional product team layer below**
+
+### Details
+
+#### 01-group-definition
+
+A Group is the parent entity that owns or controls one or more Companies.
+
+- A Group MUST own or fund at least one Company.
+- The Group layer is OPTIONAL. A standalone Company with no parent entity operates without a Group.
+- Groups typically hold consolidated financial and governance responsibility across their Companies but do not operate products directly.
+
+#### 02-company-definition
+
+A Company is a legal entity that operates independently within its jurisdiction.
+
+- A Company MUST be a registered legal entity with its own compliance and legal obligations.
+- A Company MAY exist without a parent Group.
+- A Company MAY contain one or more Business Units, or operate as a single undivided entity.
+- Strategic OKRs MAY be set at the Company level when the Company operates without Business Units.
+
+#### 03-business-unit-definition
+
+A Business Unit (BU) is an internal division of a Company that operates with a distinct product portfolio, market focus, or organisational boundary.
+
+- A Business Unit is NOT a separate legal entity. It shares the legal, financial, and compliance structure of its parent Company.
+- The Business Unit layer is OPTIONAL. A Company with a single undivided focus operates without Business Units.
+- A Business Unit MUST have clearly defined scope boundaries and ownership so that OKRs, teams, and accountability are unambiguous.
+- Strategic and Tactical OKRs MAY be set at the Business Unit level.
+
+#### 04-product-teams-inside-business-units
+
+Product teams are cross-functional execution units that sit inside a Business Unit (or directly inside a Company when no Business Unit layer exists).
+
+- A product team MUST be accountable for a defined product scope — an API, a business process, or a platform consumed by others.
+- Product teams implement Tactical OKR work through epics, sprints, and kanban flows. They do NOT set Tactical OKRs; Tactical OKRs are set at the Group, Company, or Business Unit level.
+- Product teams MAY define Operational OKRs for day-to-day execution tracking. See `agentme-bdr-002` for the full OKR framework.
+- Org-level and cross-team role definitions — including Product Manager, Principal Engineer, and Solution Architect — are in `agentme-bdr-402`. Team-level and specialist role definitions are in `agentme-bdr-404`.
+
+## References
+
+- [`agentme-bdr-002`](002-okr-framework.md) — OKR framework: Strategic, Tactical, and Operational OKR definitions
+- [`agentme-bdr-402`](../operations/402-digital-product-roles.md) — Digital product roles (org & cross-team): PM, Principal Engineer, and Solution Architect definitions
+- [`agentme-bdr-404`](../operations/404-team-roles-and-specialists.md) — Digital product roles (team & specialists): PO, PjM, BA, AI BA, AI Lead, AI Engineer, Tech Lead, engineers, and specialists

package/.xdrs/agentme/bdrs/principles/002-okr-framework.md

@@ -0,0 +1,74 @@
+---
+name: agentme-bdr-policy-002-okr-framework
+description: Defines the Strategic, Tactical, and Operational OKR framework. Use when setting, reviewing, or connecting OKRs to org levels, teams, or epics.
+apply-to: All contexts where OKRs are set, tracked, or referenced
+valid-from: 2026-08-30
+---
+
+# agentme-bdr-policy-002: OKR framework
+
+## Context and Problem Statement
+
+Teams and Business Units set goals using OKRs (Objectives and Key Results), but without a defined framework the term is applied inconsistently — timeframes vary, ownership is blurry, and the connection between strategic intent and daily execution is lost.
+
+How should OKRs be structured, owned, and connected across organisational levels so that strategy is traceable to execution?
+
+## Decision Outcome
+
+**A three-level OKR framework — Strategic, Tactical, and Operational — with defined ownership, timeframes, and connection rules**
+
+### Details
+
+#### 01-objective-characteristics
+
+An Objective defines WHERE the organisation wants to go.
+
+- Objectives MUST be qualitative, inspirational, and actionable — they state a desired direction, not a metric.
+- Objectives MUST be time-bound: each Objective MUST have a deadline; the timeframe is defined per OKR level (see rules 04–06).
+- Each Objective MUST have at least one Key Result.
+
+#### 02-key-result-characteristics
+
+A Key Result measures HOW FAR the Objective has been achieved.
+
+- Key Results MUST be quantitative and outcome-focused — they measure results, not activities.
+- Key Results SHOULD be set aggressively: a score of 0.7 out of 1.0 at cycle end is considered a strong result.
+- Key Results MUST be independently verifiable by any team member without subjective interpretation.
+
+#### 03-framework-characteristics
+
+- **Transparent**: all OKRs at every level MUST be visible to all members of the organisation.
+- **Bidirectional**: lower-level OKRs are informed by higher-level OKRs, and learnings from lower levels flow upward to inform the next cycle.
+- **Frequent**: OKR progress MUST be reviewed at a cadence appropriate to each level (see rules 04–06).
+- **Divorced from compensation**: OKR scores MUST NOT be used as direct inputs to performance reviews, bonuses, or compensation decisions. Using OKRs for compensation destroys the honesty required for accurate grading.
+
+#### 04-strategic-okrs
+
+Strategic OKRs define the long-term direction of the organisation.
+
+- **Timeframe**: annual or multi-quarter cycles.
+- **Owners**: Group, Company, or Business Unit level. See `agentme-bdr-001` for org level definitions.
+- **Downstream coverage**: every Strategic OKR MUST have at least one Tactical OKR that contributes to it. A Strategic OKR with no downstream Tactical coverage MUST have the coverage gap explicitly documented as a conscious decision.
+
+#### 05-tactical-okrs
+
+Tactical OKRs translate strategic direction into quarterly execution goals.
+
+- **Timeframe**: quarterly cycles.
+- **Owners**: Group, Company, or Business Unit level only. Product teams do NOT set Tactical OKRs — they execute against them.
+- **Strategic coverage**: all active Strategic OKRs MUST have at least one Tactical OKR contributing to them in each quarter. Undocumented gaps MUST be flagged for resolution.
+- **Connection to epics**: Tactical OKRs connect directly to Epics. The relationship is many-to-many: one Tactical OKR MAY drive multiple Epics; one Epic MAY contribute to multiple Tactical OKRs. See `agentme-bdr-401` for the epic planning policy.
+
+#### 06-operational-okrs
+
+Operational OKRs track day-to-day execution and business-as-usual (BAU) stability.
+
+- **Timeframe**: short-term cycles — day-to-day or weekly.
+- **Owners**: product teams or individual contributors.
+- **Tactical connection**: Operational OKRs SHOULD be connected to the unit's Tactical OKRs. An Operational OKR with no Tactical connection is allowed when the absence is a conscious and documented decision.
+- **Epic connection**: Operational OKRs are NOT directly linked to epics. Epics connect to Tactical OKRs, not Operational OKRs.
+
+## References
+
+- [`agentme-bdr-001`](001-company-organizational-levels.md) — Company organisational levels: Group, Company, and Business Unit definitions
+- [`agentme-bdr-401`](../operations/401-epic-feature-story-planning.md) — Epic / Feature / User Story planning: epic structure and OKR connection rule

package/.xdrs/agentme/bdrs/principles/003-product-delivery-value-flow.md

@@ -0,0 +1,90 @@
+---
+name: agentme-bdr-policy-003-product-delivery-value-flow
+description: Defines the end-to-end product delivery value chain — how roles, artifacts, and decisions connect from Strategic OKRs through to fulfilled Tactical OKRs. Use as the authoritative reference for understanding how the pieces of the agentme framework fit together.
+apply-to: All contexts where understanding the full delivery flow is needed — strategy, planning, onboarding, skill design, and system engineering processes
+valid-from: 2026-08-30
+---
+
+# agentme-bdr-policy-003: Product delivery value flow
+
+## Context and Problem Statement
+
+The agentme framework defines organisational levels (`agentme-bdr-001`), OKR structure (`agentme-bdr-002`), delivery artefacts (`agentme-bdr-401`), and roles (`agentme-bdr-402` and `agentme-bdr-404`) as independent policies. Without a connecting document, the relationships between these concepts remain implicit — creating gaps in how practitioners understand who hands off what to whom, and how a fulfilled Tactical OKR connects back to the decisions made at the strategic level.
+
+How do roles, artefacts, and decisions connect from Strategic OKRs all the way to measurable outcomes that fulfil Tactical OKRs?
+
+## Decision Outcome
+
+**A defined end-to-end value delivery chain mapping each role's inputs and outputs, the artefacts produced at each stage, and the feedback loop that closes when Tactical OKRs are fulfilled**
+
+### Details
+
+#### 01-value-chain-stages
+
+The delivery value chain consists of the following ordered stages. Each stage MUST produce its designated artefact before the next stage begins. Teams MUST NOT skip stages unless stage 5 (architecture) is explicitly inapplicable per the conditions in `02-stage-notes`.
+
+| Stage | Role | Input | Output / Artefact |
+|---|---|---|---|
+| 1 — Strategic direction | Group / Company / BU | Business context, market signals | Strategic OKRs (annual or multi-quarter) |
+| 2 — Tactical planning | Product Manager (PM) | Strategic OKRs | Tactical OKRs (quarterly) + prioritised Epics |
+| 3 — Epic definition | Product Owner (PO) | Tactical OKRs | Epics scoped and accepted by the team |
+| 4 — Requirements | Business Analyst (BA) or AI BA | Epics | Features + refined User Stories with acceptance criteria |
+| 5 — Architecture (conditional) | Solution Architect | Epic requirements | Architectural Blueprints |
+| 6 — Technical refinement | Tech Lead / AI Lead | User Stories + Blueprints | Technically refined Stories ready for implementation |
+| 7 — Implementation | Engineers (Backend, Frontend, DevOps/Infra, Full Stack, AI) | Refined Stories | Code, models, deployments |
+| 8 — Production | Product team | Deployments | Measurable outcomes in production |
+| 9 — Outcome measurement | Product Owner (PO) + PM | Measurable outcomes | Progress against Tactical OKR Key Results |
+
+#### 02-stage-notes
+
+**Stage 1 — Strategic direction**: Strategic OKRs are set at the Group, Company, or Business Unit level. See `agentme-bdr-001` for organisational level definitions and `agentme-bdr-002` for OKR characteristics.
+
+**Stage 2 — Tactical planning**: The Product Manager (PM) translates Strategic OKRs into quarterly Tactical OKRs and communicates them to Product Owners (POs). The PM also prioritises which Epics should be executed to contribute to those OKRs. Tactical OKRs are owned at the organisation level, not by product teams. See `agentme-bdr-002`.
+
+**Stage 3 — Epic definition**: The Product Owner (PO) accepts Tactical OKRs and Epics as the team's delivery mandate, scopes them within the team's capacity, and owns the team backlog. See `agentme-bdr-401` for the Epic / Feature / User Story planning structure.
+
+**Stage 4 — Requirements**: The Business Analyst (BA) or AI Business Analyst (AI BA) decomposes Epics into Features and User Stories with testable acceptance criteria. Their work is directly connected to the Tactical OKR objectives — requirements MUST trace to the changes in processes or systems needed to achieve those objectives.
+
+**Stage 5 — Architecture (conditional)**: The Solution Architect is engaged when an Epic requires new cross-system standards, new platform adoptions, integrations with external systems, or solutions with significant security or compliance concerns. When none of those conditions apply, Stage 5 is skipped and teams proceed directly from User Stories to technical refinement.
+
+**Stage 6 — Technical refinement**: The Tech Lead (for non-AI components) and AI Lead (for AI components) add technical detail to User Stories and Architectural Blueprints so that Engineers can implement them without ambiguity.
+
+**Stage 7 — Implementation**: Engineers implement the refined Stories, producing code, models, agents, and deployments. Engineer sub-types are defined in `agentme-bdr-404`.
+
+**Stage 8 — Production**: Deployments reach production. The product team monitors outcomes against the acceptance criteria defined in User Stories and the Key Results of the Tactical OKRs.
+
+**Stage 9 — Outcome measurement**: The PO and PM review measurable production outcomes against the Tactical OKR Key Results. When Key Results are met, the Tactical OKR is considered fulfilled. Learnings from the cycle inform the next Strategic OKR planning round, closing the feedback loop.
+
+#### 03-parallel-support-roles
+
+The following roles operate in parallel alongside the main value chain. Teams MUST engage these roles at the stages where their contribution is listed. They SHOULD be involved proactively rather than reactively to avoid rework.
+
+| Role | Parallel contribution |
+|---|---|
+| Project Manager (PjM) | Cross-squad and cross-team dependency coordination; stakeholder management; unblocking delivery at all stages |
+| Principal Engineer | Engineering standards, platform guidance, and mentoring that inform stages 5–7 |
+| Specialists (UX Designer, Tester, Business SME, etc.) | Embedded or shared support at specific stages — UX at stage 4 and 6; Testers at stages 7–8; Business SME at stages 3–4 |
+
+See `agentme-bdr-402` for org-level and cross-team role definitions and `agentme-bdr-404` for team-level and specialist role definitions.
+
+#### 04-operational-okrs-parallel-track
+
+Product teams MAY define Operational OKRs for day-to-day execution tracking. Operational OKRs run in parallel with the delivery chain — they reflect the team's BAU stability and operational health, not the feature delivery flow. They are NOT connected to individual Epics or User Stories. See `agentme-bdr-002` for the full OKR framework.
+
+#### 05-feedback-loop
+
+When Stage 9 confirms that Tactical OKR Key Results are met, the feedback loop closes:
+
+- Fulfilled Tactical OKRs are reported to the Group, Company, or Business Unit level
+- Learnings about what worked and what did not MUST be captured and fed into the next Strategic OKR cycle
+- The next Strategic OKR cycle begins Stage 1 again, informed by the outcomes of the completed cycle
+
+An unfulfilled Tactical OKR at cycle end MUST be explicitly reviewed — either carried forward with a documented gap, redesigned, or dropped. Silent rollovers are not acceptable. See `agentme-bdr-002` for OKR cycle governance.
+
+## References
+
+- [`agentme-bdr-001`](001-company-organizational-levels.md) — Company organisational levels: Group, Company, and Business Unit definitions
+- [`agentme-bdr-002`](002-okr-framework.md) — OKR framework: Strategic, Tactical, and Operational OKR definitions and rules
+- [`agentme-bdr-401`](../operations/401-epic-feature-story-planning.md) — Epic / Feature / User Story planning: structure and OKR connection rules
+- [`agentme-bdr-402`](../operations/402-digital-product-roles.md) — Digital product roles (org & cross-team): PM, Principal Engineer, and Solution Architect definitions
+- [`agentme-bdr-404`](../operations/404-team-roles-and-specialists.md) — Digital product roles (team & specialists): full role definitions for all team-level roles and specialists referenced in this policy

package/.xdrs/agentme/edrs/index.md

@@ -9,7 +9,7 @@ Propose changes via pull request. All changes must be verified for clarity and n
 Foundational standards, principles, and guidelines.
 
 - [150-refine-plan-mode](principles/skills/150-refine-plan-mode/SKILL.md) - **Refine plan mode** — MANDATORY skill for ANY planning activity (plan, design, propose, outline, draft, brainstorm, architect). Read and follow in full before any execution begins. Must be read from XDRS even when not in `.agents/skills`. *(skill)*
-- [151-refine-user-story](principles/skills/151-refine-user-story/SKILL.md) - **Refine user stories** — Refine, elaborate, study or develop the contents of a user story used to create a unit of work for an agile team. Runs a structured 7-phase refinement process: understand the request, qualify requirements, research context, review consistency, validate visually, challenge from 9 user-perspective angles, and produce a ready-to-implement story. *(skill)*
+- [151-refine-user-story](principles/skills/151-refine-user-story/SKILL.md) - **Refine user stories** — Refine, elaborate, study or develop the contents of a user story used to create a unit of work for an agile team. Runs a structured 10-phase refinement process: understand the request, qualify requirements, research context, review consistency, validate visually, challenge from 9 user-perspective angles (Phase 6), challenge from 8 implementer-perspective angles (Phase 7), produce a ready-to-implement story (Phase 8), and run a final readiness double-check (Phase 9). *(skill)*
 - [agentme-edr-012](principles/012-continuous-xdr-enrichment.md) - **Continuous xdr improvement policy** - Promote recurring delivery lessons into reusable XDRs
 - [agentme-edr-016](principles/016-cross-language-module-structure.md) - **Cross-language module structure** - Organize modules consistently across supported languages
 - [agentme-edr-017](principles/017-skill-testing.md) - **skill testing** - Mandates a `SKILL.test.md` co-located with every skill in scopes that follow agentme; defines test scenario format (trigger, expected behaviour, assertions) and requires execution before merging any skill change *(includes skill: [200-run-skill-tests](application/skills/200-run-skill-tests/SKILL.md))*