Skip to content

Role Workflows and User Stories

Overview

Each user group interacts with the same Unified Multimodal Knowledge Base (UMKB), but from a different operational angle. They use different tools, contribute different artifact types, and run different simulation styles. The platform must support these differences while preserving a shared governance model.

Shared Touchpoint: Contribution Lifecycle

All contributions (files, tickets, comments, runtime facts, decisions) pass through a common lifecycle:

  1. Ingest from source tool.
  2. Chunk using source-specific profile.
  3. Vectorize in PostgreSQL pgvector.
  4. Link entities and edges in Neo4j.
  5. Assign or refresh Leiden community membership.
  6. Label lifecycle state (latest, active, stale, outdated, incomplete, archived, oldest_snapshot) after LLM inspection + deterministic checks.
  7. Trigger governance and proactive maintenance actions when policy gaps or staleness are detected.

1) Developer

Primary tools/artifacts: GitHub PRs, source files, commit messages, test reports.
Typical simulations: PR-scope blast radius and dependency impact.

Workflow

  1. Opens PR with code changes and intent description.
  2. Receives governance checks and rationale linked to ADRs/incidents.
  3. Reviews detected drift or policy gaps for changed modules.
  4. Runs what-if simulation for dependency or service-call changes.
  5. Responds to delegated update requests when files/comments are marked stale or incomplete.
  6. Merges once violations are resolved or approved via exception flow.

User Story DEV-US-01

As a Developer, I want immediate policy feedback with linked rationale on my PR so that I can fix structural issues before merge.

Acceptance criteria: 1. Given a PR introduces a forbidden service dependency, when governance runs, then the PR is blocked with a plain-English explanation and linked ADR. 2. Given the change affects high-criticality services, when blast radius is computed, then impacted services are ranked and shown in the PR context. 3. Given the developer pushes a fix commit, when checks rerun, then violation status updates automatically.

2) Business Analyst

Primary tools/artifacts: Jira stories, epics, acceptance criteria docs, process documentation.
Typical simulations: Business-rule enforcement and policy-gap impact.

Workflow

  1. Creates or updates business rules in stories/epics.
  2. Queries the graph to confirm which services implement each rule.
  3. Reviews policy coverage and missing rule enforcement.
  4. Triggers simulation for rule changes across affected services.
  5. Responds to governance prompts for incomplete business rule traceability.
  6. Validates curated updates before policy activation.

User Story BA-US-01

As a Business Analyst, I want to verify that each critical business rule is mapped to enforceable policy and service behavior so that compliance is testable.

Acceptance criteria: 1. Given a business rule query, when retrieval runs, then linked services, ADRs, and existing policies are returned. 2. Given no matching policy exists, when post-mortem or repeated gap is detected, then a policy-gap alert is created for architect review. 3. Given BA submits missing rationale, when curator processing completes, then the artifact state changes from incomplete to latest.

3) Solutions Architect

Primary tools/artifacts: ADRs, architecture diagrams, integration contracts, target-state proposals.
Typical simulations: Service decomposition and policy change forecast.

Workflow

  1. Drafts target-state architecture options.
  2. Runs simulation on candidate topology changes.
  3. Compares policy and blast-radius deltas between options.
  4. Reviews Leiden communities to confirm boundary alignment.
  5. Publishes approved architecture decision as ADR.
  6. Monitors proactive alerts for drift from approved target state.

User Story SA-US-01

As a Solutions Architect, I want to simulate architectural options before implementation so that I can choose the lowest-risk target design.

Acceptance criteria: 1. Given a proposed service split, when simulation executes, then policy violations before/after are shown. 2. Given community boundaries conflict with intended domains, when analysis runs, then misalignment is flagged. 3. Given the architect selects an option, when ADR is published, then affected policies and ownership links are updated.

4) Enterprise Architect

Primary tools/artifacts: capability maps, domain standards, enterprise principles, cross-program architecture docs.
Typical simulations: portfolio-level domain and policy impact.

Workflow

  1. Reviews cross-domain risk and coupling trends.
  2. Defines enterprise-level policy packs and constraints.
  3. Validates policy impact with portfolio simulation.
  4. Tracks stale architectural artifacts by domain.
  5. Delegates remediation to domain owners and architects.
  6. Reviews executive digest for posture and investment priorities.

User Story EA-US-01

As an Enterprise Architect, I want portfolio-wide architectural risk visibility so that I can enforce standards consistently across domains.

Acceptance criteria: 1. Given a domain policy proposal, when simulation runs, then newly failing services are listed by severity and owner. 2. Given a stale architecture document backlog, when proactive scan runs, then domain-level remediation tasks are created. 3. Given quarterly review, when digest is generated, then risk trends and policy adoption metrics are included.

5) Product Owner

Primary tools/artifacts: sprint backlog, epics, acceptance criteria, release priorities.
Typical simulations: epic impact and delivery-risk estimation.

Workflow

  1. Defines epics and scope.
  2. Maps epics to impacted services and dependencies.
  3. Reviews architectural constraints and policy blockers.
  4. Simulates implementation scenarios for sprint planning.
  5. Negotiates scope with engineering using structural evidence.
  6. Tracks unresolved governance items affecting sprint readiness.

User Story PO-US-01

As a Product Owner, I want architectural impact for each epic before sprint commitment so that estimates are realistic.

Acceptance criteria: 1. Given an epic, when impact analysis runs, then affected services and owners are returned. 2. Given a high-coupling area, when sprint planning occurs, then risk and likely delays are shown. 3. Given stale/incomplete backlog artifacts, when detected, then remediation requests are assigned before sprint start.

6) DevOps Engineer

Primary tools/artifacts: Terraform, Kubernetes manifests, deployment configs, CI/CD pipelines.
Typical simulations: infrastructure change blast radius.

Workflow

  1. Prepares infra/deployment changes.
  2. Runs runtime and declared-state drift checks.
  3. Simulates infra mutation impact before apply.
  4. Executes deploy with governance guardrails.
  5. Reviews proactive alerts for undeclared runtime behavior.
  6. Updates runbooks/config docs flagged as stale.

User Story DEVOPS-US-01

As a DevOps Engineer, I want declared-vs-runtime drift detection tied to ownership so that I can remediate infra risk quickly.

Acceptance criteria: 1. Given a host has undeclared listeners, when runtime inspection runs, then drift alert and owner routing occur automatically. 2. Given a Terraform change, when simulation runs, then affected services are listed before apply. 3. Given remediation is confirmed, when update is applied, then alert status is moved to resolved with audit trace.

7) SRE

Primary tools/artifacts: incident timelines, observability events, on-call notes, reliability runbooks.
Typical simulations: incident time-window diff and resilience scenarios.

Workflow

  1. Investigates incident using temporal graph diff.
  2. Correlates runtime changes with policy and architecture context.
  3. Identifies stale runbooks or missing incident-to-policy links.
  4. Assigns corrective actions to service owners.
  5. Verifies remediation and policy updates.
  6. Tracks reliability trend in weekly posture review.

User Story SRE-US-01

As an SRE, I want pre-incident structural change visibility so that I can identify probable causes faster.

Acceptance criteria: 1. Given an incident timestamp, when temporal diff query runs, then relevant graph changes are returned within the requested window. 2. Given repeated incident pattern without policy mapping, when detected, then policy-gap recommendation is created. 3. Given runbook references stale architecture, when validated, then a delegated update task is issued.

8) Product Manager

Primary tools/artifacts: roadmap themes, release goals, business outcomes, investment proposals.
Typical simulations: roadmap feasibility and option trade-off.

Workflow

  1. Defines roadmap outcomes and candidate initiatives.
  2. Requests structural feasibility simulation for major bets.
  3. Reviews dependency bottlenecks and governance debt.
  4. Chooses sequencing based on architectural risk and capacity.
  5. Monitors execution health through periodic digests.
  6. Replans when proactive signals show rising structural risk.

User Story PM-US-01

As a Product Manager, I want roadmap feasibility simulation with architectural constraints so that commitments are realistic.

Acceptance criteria: 1. Given a candidate initiative, when simulation runs, then prerequisite architecture work is listed. 2. Given high policy debt in impacted domains, when planning review occurs, then schedule risk is quantified. 3. Given leadership review, when digest is generated, then initiative risk posture is visible.

9) Platform Engineer

Primary tools/artifacts: internal platform modules, shared libraries, build pipelines, platform standards.
Typical simulations: dependency upgrade and platform migration impact.

Workflow

  1. Proposes platform/library version changes.
  2. Runs dependency and license impact analysis.
  3. Simulates migration path across consuming services.
  4. Publishes platform guidance and implementation templates.
  5. Resolves stale platform docs and examples flagged by governance.
  6. Monitors adoption and unresolved policy exceptions.

User Story PE-US-01

As a Platform Engineer, I want transitive dependency impact before platform upgrades so that rollout plans avoid breakage.

Acceptance criteria: 1. Given a library upgrade proposal, when simulation runs, then direct and transitive consumers are listed. 2. Given license or policy conflict, when governance evaluates, then blocking and exception paths are explicit. 3. Given template docs are outdated, when proactive maintenance flags them, then assigned updates are tracked to closure.

10) Security Engineer

Primary tools/artifacts: security policies, CVE reports, threat models, incident findings.
Typical simulations: CVE propagation and attack-surface pathing.

Workflow

  1. Defines structural security policies.
  2. Monitors CVE ingestion and dependency blast radius.
  3. Investigates ghost services and unauthorized runtime behavior.
  4. Simulates threat-path changes under proposed mitigations.
  5. Assigns remediation tasks to accountable owners.
  6. Tracks closure and compliance posture in audit outputs.

User Story SEC-US-01

As a Security Engineer, I want CVE blast radius linked to ownership so that mitigation starts immediately.

Acceptance criteria: 1. Given a new CVE affecting a package, when ingestion classifies relevance, then affected services are identified. 2. Given impacted services, when ownership traversal runs, then responsible users are assigned remediation tasks. 3. Given mitigation updates are merged, when governance re-checks, then risk posture reflects current state.

11) Scrum Master

Primary tools/artifacts: sprint board, retrospective notes, impediment logs, team process docs.
Typical simulations: sprint health and debt trend scenarios.

Workflow

  1. Closes sprint and triggers structural retro generation.
  2. Reviews violation delta, drift trend, and memory-gap count.
  3. Highlights blocked remediation items by team.
  4. Facilitates action planning with engineering/product roles.
  5. Tracks completion of assigned governance tasks.
  6. Measures next sprint improvement against baseline.

User Story SM-US-01

As a Scrum Master, I want sprint retros with structural evidence so that process actions target real architecture bottlenecks.

Acceptance criteria: 1. Given sprint close, when report generation runs, then violation and drift deltas are published. 2. Given unresolved stale/incomplete artifacts, when report is prepared, then owner and SLA status are included. 3. Given next sprint start, when backlog is reviewed, then unresolved critical governance tasks are visible.

12) Project Manager

Primary tools/artifacts: delivery plan, milestone tracker, dependency map, status reports.
Typical simulations: timeline risk under structural constraints.

Workflow

  1. Builds cross-team project timeline and dependencies.
  2. Queries architecture impact for critical milestones.
  3. Detects governance debt that can delay milestones.
  4. Routes follow-up actions to accountable teams.
  5. Tracks closure progress and residual risk.
  6. Updates stakeholders with evidence-based delivery confidence.

User Story PJM-US-01

As a Project Manager, I want milestone risk visibility from architecture and governance signals so that delivery commitments stay credible.

Acceptance criteria: 1. Given a milestone touching multiple domains, when impact analysis runs, then dependency bottlenecks are listed. 2. Given unresolved policy violations in critical paths, when risk is calculated, then timeline confidence is adjusted. 3. Given remediation completion, when status refresh runs, then milestone risk rating is updated.

13) Executive

Primary tools/artifacts: portfolio KPIs, risk dashboards, quarterly strategy docs, board reporting.
Typical simulations: portfolio scenario and investment-option analysis.

Workflow

  1. Reviews monthly/quarterly governance posture digest.
  2. Compares domains by risk, drift velocity, and policy compliance.
  3. Evaluates investment options (remediation vs feature acceleration).
  4. Requests simulation for major structural decisions.
  5. Approves policy posture targets and accountability expectations.
  6. Tracks trend movement over subsequent reporting periods.

User Story EXE-US-01

As an Executive, I want portfolio-level architecture risk and governance trend visibility so that I can fund the right structural priorities.

Acceptance criteria: 1. Given monthly reporting, when digest is generated, then domain risk trend and policy posture are summarized. 2. Given a major investment decision, when scenario simulation runs, then expected risk reduction and delivery impact are shown. 3. Given accountability review, when stale governance backlog exceeds threshold, then escalation owners are explicit.