{ "id": "engineering-capacity-os-v3", "title": "Engineering Capacity Operating System Research", "display_title": "Engineering Capacity Operating System", "version": "3.0", "schema_version": "3.0.0", "status": "canonical_research_node", "human_route": "https://engineering.teamstation.dev/research/engineering-operating-system", "json_route": "https://engineering.teamstation.dev/api/research/engineering-operating-system", "json_static_route": "https://engineering.teamstation.dev/api/research/engineering-operating-system.json", "markdown_route": "https://engineering.teamstation.dev/api/research/engineering-operating-system.md", "skill_route": "https://engineering.teamstation.dev/api/research/engineering-operating-system.skill.md", "question_api_route": "https://engineering.teamstation.dev/api/research/questions", "thesis": "Modern engineering capacity is distributed across people, teams, vendors, geographies, platforms, and AI agents. Engineering Capacity OS is a research model for deciding how that capacity should be structured, governed, measured, and improved without exposing private engineering data.", "subtitle": "A location-agnostic research model for structuring, governing, measuring, and improving distributed engineering capacity across teams, partners, platforms, and AI agents.", "executive_opening": [ "Engineering teams are no longer defined only by employees, offices, or vendors. Modern capacity is distributed across internal teams, external partners, global talent, platforms, and AI agents.", "Engineering Capacity OS helps CTOs, CIOs, and VPs of Engineering decide where engineering work should live, which workflows can be safely delegated, which controls must exist before capacity is scaled, and which telemetry is trustworthy enough to govern the system.", "This page is not a staffing recommendation, vendor thesis, or location thesis. It is a research artifact for evaluating how engineering capacity should be structured, measured, and governed." ], "positioning": { "category": "location_agnostic_engineering_capacity_model", "north_star": "Engineering capacity is no longer a location decision. It is an operating-system decision.", "primary_thesis": "Modern engineering capacity is distributed across people, teams, vendors, geographies, platforms, and AI agents.", "not_a": [ "staffing landing page", "nearshore sales page", "vendor recommendation", "location thesis", "outsourcing funnel" ], "model_boundary": "The model evaluates capacity topology based on operating evidence rather than assuming a sourcing answer.", "supporting_statement": "The model does not assume that engineering work should be centralized, nearshore, offshore, outsourced, insourced, or automated. It treats each option as a capacity topology that must be tested against evidence: skill fit, knowledge availability, execution determinism, telemetry trust, governance, security, cost, and delivery risk.", "executive_clarification": "The right intervention may be internal hiring, distributed team design, nearshore pods, offshore delivery, platform investment, AI-assisted workflows, vendor consolidation, process redesign, or no capacity expansion until bottlenecks are resolved." }, "audience_personas": [ "CTO", "CIO", "VP Engineering", "Platform Leader", "DevOps Leader", "AI Governance Leader" ], "persona_paths": [ { "persona": "CTO", "focus": [ "capacity constraints", "architecture ownership", "delivery speed and quality", "AI-assisted SDLC readiness", "work allocation decisions" ] }, { "persona": "CIO", "focus": [ "governance", "security", "auditability", "vendor and policy risk", "cost and data exposure boundaries" ] }, { "persona": "VP Engineering", "focus": [ "team topology", "review queues", "execution consistency", "CI/CD variance", "distributed delivery flow" ] }, { "persona": "Platform Leader", "focus": [ "paved roads", "service ownership", "developer experience bottlenecks", "execution harness readiness" ] }, { "persona": "DevOps Leader", "focus": [ "pipeline determinism", "deployment reproducibility", "environment controls", "rollback readiness" ] }, { "persona": "AI Governance Leader", "focus": [ "agent tool permissions", "retrieval boundaries", "human approval gates", "audit and rollback controls" ] } ], "primary_use_cases": [ "build_distributed_capacity_strategy", "improve_existing_capacity_topology", "assess_agentic_sdlc_readiness", "diagnose_engineering_capacity", "evaluate_governance_security_and_ip_risk", "determine_capacity_absorption_readiness" ], "use_case_paths": [ "Build or revise a distributed capacity strategy.", "Decide what work should remain internal, external, distributed, or AI-assisted.", "Diagnose whether engineering bottlenecks are caused by capacity, execution, knowledge, telemetry, or governance.", "Assess whether agentic SDLC workflows are safe to introduce.", "Evaluate whether the system can absorb more capacity before adding headcount or partners." ], "location_agnostic_positioning": { "title": "This model is location-agnostic", "body": [ "Engineering Capacity OS does not assume that engineering work should be centralized, nearshore, offshore, outsourced, insourced, or automated. It treats each option as a capacity topology that must be tested against evidence: skill fit, knowledge availability, execution determinism, telemetry trust, governance, security, cost, and delivery risk.", "The right answer may be internal hiring, distributed internal teams, external partners, nearshore pods, offshore delivery, platform investment, AI-assisted workflows, vendor consolidation, or no capacity expansion until bottlenecks are resolved." ] }, "system_model": { "formula": "Engineering Performance(t) = f(C, T, K, D, O, A, L, G) -> {Speed, Quality, Cost, Risk, Value}", "display_formula": "Engineering Performance(t) = f(C, T, K, D, O, A, L, G) -> {Speed, Quality, Cost, Risk, Value}", "plain_language": "Engineering performance is a function of usable capacity, capacity topology, explicit knowledge, execution determinism, trusted telemetry, agentic action, adaptive learning, and governance. The output is not only speed. It includes quality, cost, risk, and business value.", "terms": { "C": "Capacity intelligence", "T": "Distributed capacity topology", "K": "Knowledge and architecture memory", "D": "Execution determinism", "O": "Observability and telemetry", "A": "Agentic action", "L": "Learning and adaptive control loops", "G": "Governance" }, "outcomes": [ "speed", "quality", "cost", "risk", "business_value" ] }, "operating_layers": [ "capacity_intelligence", "distributed_capacity_topology", "knowledge_architecture_memory", "execution_harness", "decision_grade_telemetry", "governed_agentic_sdlc", "governed_adaptive_control_loops" ], "operating_layer_definitions": [ { "id": "capacity_intelligence", "label": "Capacity Intelligence", "notation": "C", "definition": "Models usable engineering capacity after cognitive load, role fit, review constraints, interruptions, skill distribution, decision latency, and organizational bottlenecks are accounted for.", "purpose": [ "Move beyond headcount.", "Identify real available capacity.", "Distinguish staffing problems from system bottlenecks.", "Prevent leaders from adding capacity into an unabsorbable system." ], "key_question": "How much usable engineering capacity exists after load, constraints, and fit are accounted for?", "evidence_examples": [ "active WIP", "review queue age", "incident interruption load", "role-to-work fit", "decision wait time" ], "related_diagnostic_report": "Capacity Constraint Map" }, { "id": "distributed_capacity_topology", "label": "Distributed Capacity Topology", "notation": "T", "definition": "Defines how engineering work is allocated across internal teams, external partners, contractors, global talent, platform teams, and AI agents based on skill fit, ownership, time-zone overlap, knowledge requirements, security boundaries, governance, and delivery risk.", "purpose": [ "Make the model location-agnostic.", "Treat internal hiring, external partners, nearshore, offshore, platform investment, and AI agents as topology choices.", "Determine where work should live based on evidence.", "Clarify ownership and access boundaries." ], "key_question": "Which capacity topology best fits the work, risk, knowledge, governance, and performance requirements of the engineering system?", "evidence_examples": [ "workstream complexity", "ownership requirements", "time-zone overlap", "security boundary", "ramp curve" ], "related_diagnostic_report": "Capacity Topology Readiness Report" }, { "id": "knowledge_architecture_memory", "label": "Knowledge and Architecture Memory", "notation": "K", "definition": "Captures codebase context, architecture decisions, product intent, service ownership, runbooks, incidents, standards, constraints, and domain knowledge so distributed humans and AI agents can act safely.", "purpose": [ "Reduce tribal knowledge dependency.", "Improve onboarding speed.", "Make distributed execution safer.", "Improve AI-agent context quality." ], "key_question": "Does the engineering system have enough explicit knowledge for distributed contributors and AI agents to make safe, high-quality decisions?", "evidence_examples": [ "ADRs", "service ownership maps", "runbooks", "incident reviews", "documentation freshness" ], "related_diagnostic_report": "Knowledge and Architecture Memory Report" }, { "id": "execution_harness", "label": "Execution Harness / SDLC Control Plane", "notation": "D", "definition": "The deterministic SDLC control plane that governs how work moves from idea to production through CI/CD, workflow rules, deployment pipelines, quality gates, environment controls, review paths, and release processes.", "purpose": [ "Standardize execution.", "Reduce pipeline variance.", "Make distributed delivery reproducible.", "Make AI-assisted work governable." ], "key_question": "How consistently does the SDLC produce reproducible outcomes across teams, services, locations, partners, and agentic workflows?", "evidence_examples": [ "pipeline templates", "deployment success rate", "manual overrides", "rollback records", "environment drift" ], "related_diagnostic_report": "Execution Determinism Report" }, { "id": "decision_grade_telemetry", "label": "Decision-Grade Engineering Telemetry", "notation": "O", "definition": "Identifies which engineering signals are trusted enough to guide operating decisions about capacity, execution, quality, risk, cost, and system degradation.", "purpose": [ "Separate decision-grade signals from dashboard noise.", "Detect degradation.", "Compare capacity topology performance.", "Govern AI-assisted workflows." ], "key_question": "Which engineering signals are trusted enough to govern the system?", "evidence_examples": [ "cycle-time distribution", "queue time", "change failure rate", "review latency", "quality drift" ], "related_diagnostic_report": "Engineering Capacity OS Diagnostic" }, { "id": "governed_agentic_sdlc", "label": "Governed Agentic SDLC", "notation": "A", "definition": "Coordinates AI-assisted engineering workflows where agents execute bounded tasks under validation, approval, audit, security, and rollback constraints.", "purpose": [ "Identify safe agent workflows.", "Define human approval boundaries.", "Prevent agents from amplifying rework.", "Validate AI-generated engineering actions." ], "key_question": "Which engineering workflows can agents safely execute today, and under what human, technical, and governance constraints?", "evidence_examples": [ "agent tool calls", "AI-generated PR outcomes", "human override rate", "approval boundary hits", "rework signal" ], "related_diagnostic_report": "Agent Delegation Safety Matrix" }, { "id": "governed_adaptive_control_loops", "label": "Governed Adaptive Control Loops", "notation": "L", "definition": "Allows the engineering system to learn from telemetry, detect inefficiency, recommend workflow changes, and modify execution behavior only under explicit governance, approval, rollback, and audit constraints.", "purpose": [ "Support adaptive workflow optimization.", "Prevent recursive automation failures.", "Ensure workflow modification is governed.", "Keep learning loops reversible and auditable." ], "key_question": "Can the engineering system improve its own execution behavior based on evidence without creating uncontrolled automation risk?", "evidence_examples": [ "workflow rule changes", "optimization experiments", "post-change deltas", "rollback triggers", "audit records" ], "related_diagnostic_report": "Governed Adaptive Control Loop Review" } ], "cross_cutting_constraints": [ { "id": "governance_security_audit_rollback", "label": "Governance, Security, Audit, and Rollback", "definition": "Authority, approval, access control, policy, auditability, rollback, human override, partner access boundaries, agent tool permissions, security constraints, IP protection, decision records, exception handling, and stop conditions.", "executive_question": "Who has the authority to change the engineering system, how is that change validated, and how can it be reversed?" }, { "id": "failure_mode_register", "label": "Failure Mode Register", "definition": "Hidden queues, review bottlenecks, architecture decision latency, pipeline drift, documentation drift, context loss, agent-generated rework, incentive mismatch, time-zone delay, security access overreach, recursive automation loops, conflicting optimization goals, telemetry blind spots, governance lag, and local optimization harming global performance.", "executive_question": "What breaks first when capacity, distribution, or automation increases?" }, { "id": "cost_value_risk_economics", "label": "Cost, Value, and Risk Economics", "definition": "Evaluation of tradeoffs across cost, quality, risk, speed, and business value instead of treating speed as the only performance dimension.", "executive_question": "Which capacity topology produces the best balance of speed, quality, cost, risk, and business value?" } ], "domains": [ "capacity_intelligence", "distributed_capacity_topology", "knowledge_architecture_memory", "execution_harness", "decision_grade_telemetry", "governed_agentic_sdlc", "governed_adaptive_control_loops", "governance_security_failure_modes" ], "research_domains": [ { "domain": "capacity_intelligence", "label": "Capacity Intelligence" }, { "domain": "distributed_capacity_topology", "label": "Distributed Capacity Topology" }, { "domain": "knowledge_architecture_memory", "label": "Knowledge and Architecture Memory" }, { "domain": "execution_harness", "label": "Execution Harness / SDLC Control Plane" }, { "domain": "decision_grade_telemetry", "label": "Decision-Grade Engineering Telemetry" }, { "domain": "governed_agentic_sdlc", "label": "Governed Agentic SDLC" }, { "domain": "governed_adaptive_control_loops", "label": "Governed Adaptive Control Loops" }, { "domain": "governance_security_failure_modes", "label": "Governance, Security, and Failure Modes" } ], "capacity_topology_patterns": [ { "id": "centralized_internal_engineering", "label": "Centralized internal engineering", "definition": "Best when strategic IP, architecture authority, and high-context product work require tight internal ownership.", "best_fit_conditions": [ "clear internal ownership", "direct architecture control", "sensitive product context" ], "risk_indicators": [ "internal queues already saturated", "specialists overloaded" ], "required_controls": [ "ownership map", "review capacity", "decision rights" ], "evidence_required_before_scaling": [ "capacity constraints", "review queue age", "architecture decision latency" ] }, { "id": "distributed_internal_engineering", "label": "Distributed internal engineering", "definition": "Best when internal teams can operate across locations with shared standards, documentation, and execution harnesses.", "best_fit_conditions": [ "strong documentation", "clear service ownership", "time-zone coordination rituals" ], "risk_indicators": [ "handoff latency", "documentation drift" ], "required_controls": [ "operating agreements", "shared CI/CD gates", "decision rituals" ], "evidence_required_before_scaling": [ "cycle time by team", "handoff delay", "documentation freshness" ] }, { "id": "staff_augmentation", "label": "Contributor capacity model", "definition": "Best for bounded tasks where internal ownership, review, and architecture authority remain clear.", "best_fit_conditions": [ "clear task boundaries", "available review capacity", "low ownership ambiguity" ], "risk_indicators": [ "review queues saturated", "ambiguous requirements" ], "required_controls": [ "access policy", "review path", "definition of done" ], "evidence_required_before_scaling": [ "PR correction rate", "ramp time", "review queue age" ] }, { "id": "external_partner", "label": "External engineering partner", "definition": "Best when a partner can own bounded outcomes under explicit governance, telemetry, and exit controls.", "best_fit_conditions": [ "bounded workstream", "defined outcome", "clear governance" ], "risk_indicators": [ "incentive mismatch", "weak exit path" ], "required_controls": [ "operating agreement", "telemetry baseline", "exit plan" ], "evidence_required_before_scaling": [ "delivery outcomes", "quality metrics", "access audit" ] }, { "id": "nearshore_pod", "label": "Nearshore pod", "definition": "Best when collaboration overlap matters and work can be distributed with clear ownership, test coverage, and access boundaries.", "best_fit_conditions": [ "collaboration overlap needed", "documentation sufficient", "review authority available" ], "risk_indicators": [ "tribal architecture knowledge", "unclear production access" ], "required_controls": [ "service ownership map", "access policy", "CI/CD gates", "exit plan" ], "evidence_required_before_scaling": [ "cycle time by work type", "review age", "deployment success", "documentation completeness" ] }, { "id": "offshore_pod", "label": "Offshore pod", "definition": "Best for well-specified work with low synchronous decision dependency and mature execution controls.", "best_fit_conditions": [ "low ambiguity", "strong async documentation", "clear acceptance tests" ], "risk_indicators": [ "decision latency tolerance low", "incident response needs high" ], "required_controls": [ "async rituals", "test gates", "handoff rules" ], "evidence_required_before_scaling": [ "handoff delay", "blocked time", "test reliability" ] }, { "id": "managed_vendor_team", "label": "Managed vendor team", "definition": "Best when a bounded capability can be delegated with service-level evidence, auditability, and reversible ownership.", "best_fit_conditions": [ "clear outcome boundary", "vendor governance mature", "performance telemetry exists" ], "risk_indicators": [ "opaque delivery", "unclear IP provenance" ], "required_controls": [ "audit rights", "IP controls", "service continuity plan" ], "evidence_required_before_scaling": [ "SLOs", "defect rate", "exception logs", "provenance records" ] }, { "id": "platform_led_capacity", "label": "Platform-led capacity model", "definition": "Best when bottlenecks are caused by tooling, paved roads, CI/CD variance, and developer experience constraints.", "best_fit_conditions": [ "many teams blocked by same platform gap", "high manual toil" ], "risk_indicators": [ "platform roadmap detached from product needs" ], "required_controls": [ "platform telemetry", "service catalog", "standard templates" ], "evidence_required_before_scaling": [ "developer wait time", "pipeline variance", "manual intervention" ] }, { "id": "build_operate_transfer", "label": "Build-operate-transfer", "definition": "Best when an external group can establish a capability and transfer ownership after knowledge, controls, and evidence mature.", "best_fit_conditions": [ "defined transfer target", "knowledge plan", "governance plan" ], "risk_indicators": [ "transfer criteria vague", "documentation weak" ], "required_controls": [ "transfer checklist", "ownership map", "access revocation plan" ], "evidence_required_before_scaling": [ "knowledge completeness", "ownership readiness", "exit plan" ] }, { "id": "ai_assisted_internal_team", "label": "AI-assisted internal team", "definition": "Best when internal teams retain judgment while agents reduce documentation, test generation, review preparation, or workflow routing costs.", "best_fit_conditions": [ "strong validation", "clear tool policy", "human ownership" ], "risk_indicators": [ "AI rework invisible", "prompt policy unclear" ], "required_controls": [ "approved tools", "audit logs", "human gates" ], "evidence_required_before_scaling": [ "agent tool calls", "correction rate", "failed validations" ] }, { "id": "ai_assisted_external_team", "label": "AI-assisted external team", "definition": "Best when external contributors use approved AI under strict retrieval, access, audit, and validation controls.", "best_fit_conditions": [ "approved tools by contributor class", "safe retrieval index", "clear review authority" ], "risk_indicators": [ "data exposure risk", "unverified PR provenance" ], "required_controls": [ "AI policy", "retrieval boundary", "audit requirements" ], "evidence_required_before_scaling": [ "tool usage logs", "PR provenance", "access classes" ] }, { "id": "human_agent_hybrid_delivery", "label": "Human-agent hybrid delivery system", "definition": "Best when humans and agents operate as one controlled delivery system with explicit approval, telemetry, and rollback boundaries.", "best_fit_conditions": [ "bounded agent actions", "decision-grade telemetry", "rollback ready" ], "risk_indicators": [ "recursive automation", "weak stop conditions" ], "required_controls": [ "agent action policy", "stop conditions", "rollback authority" ], "evidence_required_before_scaling": [ "human override rate", "quality drift", "policy exceptions" ] } ], "readiness_scorecard": { "title": "Capacity Topology Readiness Scorecard", "dimensions": [ { "id": "capacity_reality", "label": "Capacity Reality", "description": "Whether usable capacity is known beyond headcount." }, { "id": "topology_fit", "label": "Topology Fit", "description": "Whether work allocation fits skill, ownership, time-zone, risk, and knowledge needs." }, { "id": "knowledge_transfer_readiness", "label": "Knowledge Transfer Readiness", "description": "Whether context can move without tribal bottlenecks." }, { "id": "execution_determinism", "label": "Execution Determinism", "description": "Whether CI/CD and SDLC flows are standardized and reproducible." }, { "id": "telemetry_trust", "label": "Telemetry Trust", "description": "Whether metrics are good enough for operating decisions." }, { "id": "agent_delegation_safety", "label": "Agent Delegation Safety", "description": "Whether AI workflows can be bounded, validated, audited, and reversed." }, { "id": "governance_completeness", "label": "Governance Completeness", "description": "Whether access, approval, audit, security, and rollback are controlled." }, { "id": "upside_potential", "label": "Upside Potential", "description": "Whether the system can compound productivity gains safely." } ], "classifications": [ "not_ready_to_scale_capacity", "ready_for_internal_process_repair_only", "ready_for_bounded_contributor_capacity", "ready_for_distributed_team_execution", "ready_for_external_partner_or_pod_ownership", "ready_for_ai_assisted_distributed_delivery", "ready_for_governed_adaptive_optimization" ] }, "private_engineering_evidence_model": { "title": "Private Engineering Evidence Model", "definition": "Engineering Capacity OS diagnostics are designed to run inside the organization's own environment using approved MCP-connected systems, aggregate exports, metadata, summaries, or redacted evidence packs.", "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "workflow": [ { "step": "select", "definition": "Choose one operating decision and the smallest relevant analysis boundary." }, { "step": "constrain", "definition": "Set privacy, source, time-window, aggregation, and redaction boundaries before retrieval." }, { "step": "retrieve", "definition": "Use approved MCP-connected systems or aggregate exports for summarized evidence only." }, { "step": "classify", "definition": "Mark evidence as observed, modeled, directional, or unknown." }, { "step": "analyze", "definition": "Map evidence to capacity, topology, knowledge, execution, telemetry, agentic, adaptive-loop, and governance layers." }, { "step": "report", "definition": "Produce an internal diagnostic report with confidence tier, gaps, risks, and one safe next action." } ], "evidence_classes": { "observed": "Directly measured by an approved source system.", "modeled": "Inferred from multiple signals.", "directional": "Weak but useful trend evidence.", "unknown": "Insufficient evidence." }, "recommended_source_categories": [ "Jira / Linear / Azure DevOps", "GitHub / GitLab / Bitbucket", "CI/CD systems", "deployment systems", "pull requests and review queues", "incident systems", "observability dashboards", "architecture documentation", "runbooks", "service ownership maps", "agent tool-call logs", "calendar or collaboration metadata only if approved and aggregated" ], "no_mcp_workflow": [ { "step": "export", "definition": "Pull aggregate snapshots from work tracking, source control, CI/CD, incident, review, deployment, documentation, and agent systems." }, { "step": "redact", "definition": "Remove secrets, customer identifiers, raw source code, private logs, HR records, personal details, and sensitive proprietary records." }, { "step": "summarize", "definition": "Convert exports into counts, distributions, time windows, queue ages, failure rates, and short redacted examples." }, { "step": "analyze", "definition": "Paste the evidence pack and AI Diagnostic Protocol into an LLM approved for internal analysis." }, { "step": "validate", "definition": "Treat the output as a hypothesis until a leader checks source systems, confidence, and missing instrumentation." } ] }, "manual_evidence_pack_template": { "title": "Engineering Capacity OS Manual Evidence Pack", "sections": [ "Operating decision", "Analysis boundary", "Current capacity topology", "Aggregate evidence", "Redacted examples", "Missing instrumentation", "Known caveats", "Requested report type" ], "operating_decision_examples": [ "Should we add more engineers or fix bottlenecks first?", "Which workstreams can be distributed safely?", "Which work should remain internal?", "Which workflows can be AI-assisted?", "Is our engineering system ready to absorb external capacity?", "Is our telemetry good enough to govern distributed delivery?" ], "aggregate_evidence_fields": [ "work-in-progress counts", "cycle time distribution", "review queue age", "review correction rate", "CI/CD pass rate", "deployment frequency", "rollback or failure events", "incident interruption load", "architecture documentation status", "service ownership clarity", "runbook completeness", "onboarding duration", "agent tool-call count", "agent-generated PR outcomes", "human approval events", "policy exceptions", "access exceptions", "external contributor access classes" ] }, "report_templates": [ { "id": "engineering_capacity_os_diagnostic", "title": "Engineering Capacity OS Diagnostic", "use_for": "Broad operating assessment.", "includes": [ "operating decision", "included teams/services", "time window", "current capacity topology", "capacity findings", "knowledge readiness findings", "execution harness findings", "telemetry trust findings", "agentic SDLC readiness", "adaptive control-loop readiness", "governance/security/IP findings", "failure mode register", "scorecard results", "confidence tiers", "safe next actions" ] }, { "id": "capacity_topology_readiness_report", "title": "Capacity Topology Readiness Report", "use_for": "Deciding where work should live.", "includes": [ "current topology", "candidate topology options", "workstream allocation map", "internal ownership requirements", "external/distributed ownership candidates", "AI-assisted workflow candidates", "required controls", "risks", "exit paths", "recommendation with confidence" ] }, { "id": "knowledge_architecture_memory_report", "title": "Knowledge and Architecture Memory Report", "use_for": "Evaluating distributed or AI-assisted readiness.", "includes": [ "architecture documentation status", "service ownership maps", "tribal knowledge risk", "runbook maturity", "incident memory", "documentation drift", "AI retrieval safety", "onboarding readiness", "recommended knowledge interventions" ] }, { "id": "execution_determinism_report", "title": "Execution Determinism Report", "use_for": "Evaluating whether the SDLC can absorb more capacity.", "includes": [ "pipeline standardization", "manual overrides", "deployment reproducibility", "review queue health", "environment drift", "failure concentration", "governance gaps", "scaling risks" ] }, { "id": "agent_delegation_safety_matrix", "title": "Agent Delegation Safety Matrix", "use_for": "Deciding which workflows agents can safely support.", "includes": [ "safe now", "human-gated", "unsafe", "insufficiently instrumented", "validation method", "approval requirement", "rollback path", "audit evidence", "data exposure risk", "blast radius" ] }, { "id": "governance_security_ip_control_report", "title": "Governance, Security, and IP Control Report", "use_for": "CIO, security, and executive governance concerns.", "includes": [ "access boundaries", "vendor/partner access", "agent tool permissions", "IP provenance", "policy exceptions", "audit completeness", "production approval controls", "rollback authority", "data exposure risks", "exit readiness" ] } ], "research_participation": { "title": "Research Validation Paths", "description": "A location-agnostic research program for engineering leaders validating distributed capacity, AI-assisted SDLC, telemetry, governance, and sourcing topology models.", "invitation": "The model is validated from leader-controlled evidence only: internal MCP analysis, redacted aggregate evidence packs, structured interview notes, anonymized pattern submissions, or benchmark packets using non-sensitive operating metrics.", "source_model": [ "Internal MCP: the leader runs the questions inside their own environment and keeps raw evidence private.", "Manual evidence pack: the leader exports aggregate counts, distributions, time windows, queue ages, and redacted examples.", "Structured interview: the leader describes the operating decision, current topology, constraints, and missing telemetry.", "Anonymized pattern: the leader contributes a generalized capacity, governance, telemetry, or agentic SDLC pattern with identifiers removed.", "Benchmark packet: only aggregate, non-sensitive measures are compared across participating organizations." ], "privacy_commitment": [ "No source code required.", "No secrets required.", "No customer data required.", "No raw logs required.", "No employee-level performance data required.", "Aggregate metrics and redacted examples are sufficient." ], "participation_modes": [ { "id": "use_public_diagnostic", "label": "Use the public diagnostic internally" }, { "id": "submit_anonymized_feedback", "label": "Submit anonymized feedback on the model" }, { "id": "join_research_interview", "label": "Join a structured research interview" }, { "id": "contribute_anonymized_pattern", "label": "Contribute an anonymized capacity or governance pattern" }, { "id": "join_benchmark_cohort", "label": "Join a benchmark cohort using aggregate, non-sensitive evidence" } ], "contribution_fields": { "role": [ "CTO", "CIO", "VP Engineering", "Platform leader", "DevOps leader", "AI governance leader", "Other" ], "organization_size": [ "<50 engineers", "50-200 engineers", "200-1,000 engineers", "1,000+ engineers" ], "current_capacity_model": [ "Mostly internal", "Distributed internal", "Contributor capacity model", "External partner", "Nearshore partner", "Offshore partner", "Managed vendor team", "Platform-heavy model", "AI-assisted workflows", "Hybrid" ], "primary_challenge": [ "Capacity constraints", "Review bottlenecks", "Delivery inconsistency", "CI/CD variance", "Governance risk", "AI delegation safety", "Knowledge transfer", "Cost pressure", "Quality degradation", "Partner performance", "Other" ], "privacy_confirmation": "No source code, secrets, customer data, raw logs, or employee-level performance data requested." } }, "privacy_safety_classes": { "allowed": [ "aggregate metrics", "metadata", "summaries", "redacted examples", "approved internal MCP signals" ], "not_requested": [ "source code", "secrets", "customer data", "raw logs", "HR records", "private messages", "individual employee performance data", "proprietary records" ] }, "llm_prompt_templates": [ { "title": "Engineering Capacity OS Diagnostic", "prompt": "Using only approved internal MCP-accessible aggregate data or a redacted evidence pack, generate an Engineering Capacity OS diagnostic for the last 90 days. Do not assume the answer is hiring, nearshore, offshore, outsourcing, insourcing, platform investment, vendor replacement, or AI automation. Evaluate evidence first. Map findings to capacity_intelligence, distributed_capacity_topology, knowledge_architecture_memory, execution_harness, decision_grade_telemetry, governed_agentic_sdlc, governed_adaptive_control_loops, and governance_security_failure_modes. For each finding include evidence class, source system, time window, confidence tier, operational risk, missing evidence, and one safe next action. Do not expose source code, secrets, customer data, raw logs, private messages, or individual employee performance data." }, { "title": "Capacity Topology Readiness", "prompt": "Analyze which capacity topology best fits the selected workstreams. Compare internal ownership, distributed internal teams, contributor capacity, external partners, nearshore pods, offshore pods, platform investment, AI-assisted workflows, and human-agent hybrid delivery. Use aggregate evidence only. Return readiness scorecard results, required controls, risk flags, exit paths, confidence tier, and the safest next action." }, { "title": "Agent Delegation Safety", "prompt": "Analyze which SDLC workflows can be safely delegated to agents today. Use aggregate signals for PR outcomes, review latency, CI/CD failures, rollback events, tool-call logs, approval records, and incident correlation. Classify each workflow as safe_now, human_gated, unsafe, or insufficiently_instrumented. Explain validation method, approval requirement, rollback path, audit evidence, data exposure risk, blast radius, and missing controls." }, { "title": "Generate answer cards from internal MCP evidence", "prompt": "Use the Engineering Capacity OS question bank and answer-card schema. Select the requested domain and operating decision. Query only approved internal MCP sources for aggregate metadata, summaries, counts, distributions, time windows, and redacted examples. Do not retrieve source code, secrets, customer records, raw private messages, payroll data, legal records, or individual employee performance records. For each selected question, produce an answer card with question_id, domain, doctrine_answer, evidence_summary, observed_state, confidence, source_classes, missing_evidence, risk_flags, recommended_report_section, and next_safe_action. Mark unknown when evidence is insufficient. Do not force recommendations." } ], "llm_retrieval_metadata": { "canonical_summary": "Engineering Capacity OS is a location-agnostic model for structuring, governing, measuring, and improving engineering capacity across teams, partners, platforms, and AI agents.", "primary_audience": [ "CTO", "CIO", "VP Engineering" ], "primary_use_cases": [ "distributed capacity strategy", "agentic SDLC readiness", "engineering governance", "capacity topology diagnosis" ], "content_type": "research_artifact", "not_marketing_page": true, "privacy_boundary": "aggregate and redacted evidence only", "structured_metadata": [ "engineering systems", "capacity intelligence", "agentic SDLC", "telemetry-driven engineering", "distributed capacity topology", "answer-card-schema", "workflow-report-system", "private-mcp-diagnostics", "evidence-bound-answer-cards" ] }, "question_index": [ { "id": "capacity-001", "domain": "capacity_intelligence", "question": "How much usable engineering capacity exists after cognitive load, review load, interruptions, and role fit are accounted for?", "why_it_matters": "Headcount does not represent usable capacity when the system loses time to queues, incidents, meetings, or poor work fit.", "validation_signal": "Compare committed work, completed work, active WIP, review queue age, incident interruption load, and role-to-work fit over the same window.", "persona_relevance": [ "CTO", "VP Engineering" ], "use_cases": [ "diagnose_engineering_capacity", "determine_capacity_absorption_readiness" ], "required_sources": [ "Jira or Linear", "GitHub or GitLab", "incident system", "calendar metadata if approved and aggregated" ], "minimum_evidence": [ "active WIP", "completed work", "review queue age", "incident interruptions" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Capacity Reality", "Telemetry Trust" ], "risk_flags": [ "hidden_capacity_loss", "review_bottleneck" ], "recommended_report_type": "Engineering Capacity OS Diagnostic", "intent": "diagnostic", "level": "cto", "tags": [ "capacity", "headcount", "cognitive-load" ], "related_concepts": [ "available_capacity", "review_capacity", "role_fit" ], "doctrine_answer": "Usable capacity is committed delivery capacity minus time lost to active WIP, review queues, incidents, interruptions, meetings, and role mismatch over the same measurement window; headcount alone is not capacity.", "answer_card_template": { "answer_type": "capacity_constraint_answer", "good_answer_pattern": "A strong answer directly answers: \"How much usable engineering capacity exists after cognitive load, review load, interruptions, and role fit are accounted for?\" Validation method: Compare committed work, completed work, active WIP, review queue age, incident interruption load, and role-to-work fit over the same window. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Capacity Reality, Telemetry Trust.", "common_failure_pattern": "A weak answer gives a generic capacity intelligence diagnosis instead of proving this question with Jira or Linear, GitHub or GitLab, incident system, and related approved sources. It misses the operating risk: Headcount does not represent usable capacity when the system loses time to queues, incidents, meetings, or poor work fit.", "recommended_report_section": "Engineering Capacity OS Diagnostic", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "capacity-002", "domain": "capacity_intelligence", "question": "Which roles or decision points create the current capacity constraint?", "why_it_matters": "Adding contributors does not help if the bottleneck is architecture review, product decision latency, release approval, or a specialized reviewer.", "validation_signal": "Locate queues by role dependency and compare queue time against reviewer availability, decision age, and approval latency.", "persona_relevance": [ "CTO", "VP Engineering" ], "use_cases": [ "diagnose_engineering_capacity", "determine_capacity_absorption_readiness" ], "required_sources": [ "work tracker", "pull request system", "architecture decision records", "approval workflow" ], "minimum_evidence": [ "queue by role", "approval latency", "reviewer availability", "decision age" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Capacity Reality", "Execution Determinism" ], "risk_flags": [ "decision_latency", "role_bottleneck" ], "recommended_report_type": "Capacity Constraint Map", "intent": "diagnostic", "level": "cto", "tags": [ "constraints", "roles", "decision-latency" ], "related_concepts": [ "bottleneck_role", "decision_authority" ], "doctrine_answer": "The current capacity constraint is the role or decision gate whose queue time and demand exceed its available review or approval capacity, regardless of how many contributors exist upstream.", "answer_card_template": { "answer_type": "capacity_constraint_answer", "good_answer_pattern": "A strong answer directly answers: \"Which roles or decision points create the current capacity constraint?\" Validation method: Locate queues by role dependency and compare queue time against reviewer availability, decision age, and approval latency. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Capacity Reality, Execution Determinism.", "common_failure_pattern": "A weak answer gives a generic capacity intelligence diagnosis instead of proving this question with work tracker, pull request system, architecture decision records, and related approved sources. It misses the operating risk: Adding contributors does not help if the bottleneck is architecture review, product decision latency, release approval, or a specialized reviewer.", "recommended_report_section": "Capacity Constraint Map", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "capacity-003", "domain": "capacity_intelligence", "question": "What percentage of capacity is lost to context switching and fragmented ownership?", "why_it_matters": "Fragmented work creates apparent activity while reducing throughput, quality, and learning.", "validation_signal": "Measure active work items per contributor, handoff count, interrupted work, incident load, and cycle-time variance.", "persona_relevance": [ "VP Engineering", "Platform Leader" ], "use_cases": [ "diagnose_engineering_capacity" ], "required_sources": [ "work tracker", "incident system", "calendar metadata if approved and aggregated" ], "minimum_evidence": [ "active work per contributor", "handoff count", "interruption count", "cycle-time variance" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Capacity Reality", "Upside Potential" ], "risk_flags": [ "context_switching", "ownership_fragmentation" ], "recommended_report_type": "Engineering Capacity OS Diagnostic", "intent": "diagnostic", "level": "engineering_lead", "tags": [ "context-switching", "focus", "ownership" ], "related_concepts": [ "cognitive_load", "work_fragmentation" ], "doctrine_answer": "Context-switching loss is the share of available engineering time consumed by work transitions, interrupted tasks, handoffs, and fragmented ownership rather than completed flow.", "answer_card_template": { "answer_type": "capacity_constraint_answer", "good_answer_pattern": "A strong answer directly answers: \"What percentage of capacity is lost to context switching and fragmented ownership?\" Validation method: Measure active work items per contributor, handoff count, interrupted work, incident load, and cycle-time variance. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Capacity Reality, Upside Potential.", "common_failure_pattern": "A weak answer gives a generic capacity intelligence diagnosis instead of proving this question with work tracker, incident system, calendar metadata if approved and aggregated. It misses the operating risk: Fragmented work creates apparent activity while reducing throughput, quality, and learning.", "recommended_report_section": "Engineering Capacity OS Diagnostic", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "capacity-004", "domain": "capacity_intelligence", "question": "Which work types consume scarce senior review or architecture capacity?", "why_it_matters": "Capacity expansion can overload senior reviewers and turn more contributors into slower delivery.", "validation_signal": "Classify PRs, design reviews, escalations, and rework by work type and senior-review dependency.", "persona_relevance": [ "CTO", "VP Engineering" ], "use_cases": [ "determine_capacity_absorption_readiness", "improve_existing_capacity_topology" ], "required_sources": [ "pull request system", "architecture reviews", "work tracker" ], "minimum_evidence": [ "review dependency", "review queue age", "rework rate", "senior reviewer load" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Capacity Reality", "Topology Fit" ], "risk_flags": [ "senior_review_saturation", "architecture_constraint" ], "recommended_report_type": "Capacity Topology Readiness Report", "intent": "diagnostic", "level": "cto", "tags": [ "review", "architecture", "capacity" ], "related_concepts": [ "review_capacity", "architecture_authority" ], "doctrine_answer": "Work types with high architectural ambiguity, cross-service impact, security exposure, or weak test boundaries consume the most scarce senior review capacity and should be ranked by measured review demand.", "answer_card_template": { "answer_type": "capacity_constraint_answer", "good_answer_pattern": "A strong answer directly answers: \"Which work types consume scarce senior review or architecture capacity?\" Validation method: Classify PRs, design reviews, escalations, and rework by work type and senior-review dependency. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Capacity Reality, Topology Fit.", "common_failure_pattern": "A weak answer gives a generic capacity intelligence diagnosis instead of proving this question with pull request system, architecture reviews, work tracker. It misses the operating risk: Capacity expansion can overload senior reviewers and turn more contributors into slower delivery.", "recommended_report_section": "Capacity Topology Readiness Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "capacity-005", "domain": "capacity_intelligence", "question": "Is the engineering system ready to absorb additional contributors without increasing queue time?", "why_it_matters": "New capacity can create negative throughput if onboarding, review, knowledge, and release systems are not ready.", "validation_signal": "Compare onboarding duration, PR correction rate, review queue age, test reliability, deployment frequency, and incident load before scaling.", "persona_relevance": [ "CTO", "CIO", "VP Engineering" ], "use_cases": [ "determine_capacity_absorption_readiness", "build_distributed_capacity_strategy" ], "required_sources": [ "work tracker", "pull request system", "CI/CD", "deployment system", "incident system" ], "minimum_evidence": [ "onboarding duration", "review queue age", "PR correction rate", "deployment success" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Capacity Reality", "Knowledge Transfer Readiness", "Execution Determinism" ], "risk_flags": [ "unabsorbable_capacity", "queue_growth" ], "recommended_report_type": "Capacity Topology Readiness Report", "intent": "diagnostic", "level": "cto", "tags": [ "absorption", "scaling", "queue-time" ], "related_concepts": [ "capacity_absorption", "onboarding" ], "doctrine_answer": "The system is ready for more contributors only when onboarding, knowledge access, review capacity, test reliability, and release controls can absorb the marginal work without increasing queue age or rework.", "answer_card_template": { "answer_type": "capacity_constraint_answer", "good_answer_pattern": "A strong answer directly answers: \"Is the engineering system ready to absorb additional contributors without increasing queue time?\" Validation method: Compare onboarding duration, PR correction rate, review queue age, test reliability, deployment frequency, and incident load before scaling. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Capacity Reality, Knowledge Transfer Readiness, Execution Determinism.", "common_failure_pattern": "A weak answer gives a generic capacity intelligence diagnosis instead of proving this question with work tracker, pull request system, CI/CD, and related approved sources. It misses the operating risk: New capacity can create negative throughput if onboarding, review, knowledge, and release systems are not ready.", "recommended_report_section": "Capacity Topology Readiness Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "capacity-006", "domain": "capacity_intelligence", "question": "What capacity is blocked by missing decisions rather than missing people?", "why_it_matters": "Many capacity problems are decision-system problems: unclear priority, product ambiguity, architecture approval, or governance delay.", "validation_signal": "Identify blocked work items by blocker class and compare blocked time caused by people availability, technical dependency, policy, or decision latency.", "persona_relevance": [ "CTO", "CIO", "VP Engineering" ], "use_cases": [ "diagnose_engineering_capacity", "evaluate_governance_security_and_ip_risk" ], "required_sources": [ "work tracker", "decision records", "architecture records", "approval workflow" ], "minimum_evidence": [ "blocked reason", "decision wait time", "approval age", "priority changes" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Capacity Reality", "Governance Completeness" ], "risk_flags": [ "decision_latency", "ambiguous_priority" ], "recommended_report_type": "Engineering Capacity OS Diagnostic", "intent": "diagnostic", "level": "cto", "tags": [ "blocked-work", "decisions", "governance" ], "related_concepts": [ "decision_latency", "blocked_capacity" ], "doctrine_answer": "Decision-blocked capacity is the delivery time lost to unresolved priority, product, architecture, policy, or approval decisions; it must be separated from shortages in contributor availability.", "answer_card_template": { "answer_type": "capacity_constraint_answer", "good_answer_pattern": "A strong answer directly answers: \"What capacity is blocked by missing decisions rather than missing people?\" Validation method: Identify blocked work items by blocker class and compare blocked time caused by people availability, technical dependency, policy, or decision latency. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Capacity Reality, Governance Completeness.", "common_failure_pattern": "A weak answer gives a generic capacity intelligence diagnosis instead of proving this question with work tracker, decision records, architecture records, and related approved sources. It misses the operating risk: Many capacity problems are decision-system problems: unclear priority, product ambiguity, architecture approval, or governance delay.", "recommended_report_section": "Engineering Capacity OS Diagnostic", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "capacity-007", "domain": "capacity_intelligence", "question": "Which skills are scarce enough to determine capacity topology decisions?", "why_it_matters": "Topology decisions should follow scarce skills, knowledge concentration, review authority, and risk boundaries rather than location preference.", "validation_signal": "Map workstream demand to skill supply, review capacity, architecture knowledge, and validated contributor readiness.", "persona_relevance": [ "CTO", "VP Engineering" ], "use_cases": [ "build_distributed_capacity_strategy", "improve_existing_capacity_topology" ], "required_sources": [ "work tracker", "skills inventory", "service ownership map", "pull request system" ], "minimum_evidence": [ "skill demand", "skill supply", "review dependency", "ownership concentration" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Capacity Reality", "Topology Fit" ], "risk_flags": [ "scarce_skill_constraint", "knowledge_concentration" ], "recommended_report_type": "Capacity Topology Readiness Report", "intent": "diagnostic", "level": "cto", "tags": [ "skills", "topology", "scarcity" ], "related_concepts": [ "skill_fit", "topology_fit" ], "doctrine_answer": "A skill is topology-determining when demand for that skill, knowledge, or approval authority repeatedly exceeds validated supply and creates a measurable queue or risk boundary.", "answer_card_template": { "answer_type": "capacity_constraint_answer", "good_answer_pattern": "A strong answer directly answers: \"Which skills are scarce enough to determine capacity topology decisions?\" Validation method: Map workstream demand to skill supply, review capacity, architecture knowledge, and validated contributor readiness. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Capacity Reality, Topology Fit.", "common_failure_pattern": "A weak answer gives a generic capacity intelligence diagnosis instead of proving this question with work tracker, skills inventory, service ownership map, and related approved sources. It misses the operating risk: Topology decisions should follow scarce skills, knowledge concentration, review authority, and risk boundaries rather than location preference.", "recommended_report_section": "Capacity Topology Readiness Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "capacity-008", "domain": "capacity_intelligence", "question": "Which capacity constraints should be repaired before any sourcing, hiring, or automation decision is made?", "why_it_matters": "A poor system can absorb hiring, partners, or AI agents and still produce worse delivery behavior.", "validation_signal": "Rank constraints by queue impact, quality impact, risk impact, reversibility, and required controls.", "persona_relevance": [ "CTO", "CIO", "VP Engineering" ], "use_cases": [ "diagnose_engineering_capacity", "determine_capacity_absorption_readiness", "build_distributed_capacity_strategy" ], "required_sources": [ "work tracker", "pull request system", "CI/CD", "incident system", "architecture records" ], "minimum_evidence": [ "queue impact", "quality impact", "risk impact", "control gaps" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Capacity Reality", "Upside Potential", "Governance Completeness" ], "risk_flags": [ "premature_scaling", "automation_amplifies_bottleneck" ], "recommended_report_type": "Engineering Capacity OS Diagnostic", "intent": "diagnostic", "level": "cto", "tags": [ "repair-before-scale", "capacity", "risk" ], "related_concepts": [ "system_bottleneck", "capacity_repair" ], "doctrine_answer": "Repair the constraints with the greatest demonstrated queue, quality, and risk impact before adding people, partners, or agents, especially review bottlenecks, decision latency, missing knowledge, and unreliable execution controls.", "answer_card_template": { "answer_type": "capacity_constraint_answer", "good_answer_pattern": "A strong answer directly answers: \"Which capacity constraints should be repaired before any sourcing, hiring, or automation decision is made?\" Validation method: Rank constraints by queue impact, quality impact, risk impact, reversibility, and required controls. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Capacity Reality, Upside Potential, Governance Completeness.", "common_failure_pattern": "A weak answer gives a generic capacity intelligence diagnosis instead of proving this question with work tracker, pull request system, CI/CD, and related approved sources. It misses the operating risk: A poor system can absorb hiring, partners, or AI agents and still produce worse delivery behavior.", "recommended_report_section": "Engineering Capacity OS Diagnostic", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "topology-001", "domain": "distributed_capacity_topology", "question": "Which engineering workstreams are safest to distribute beyond the current core team?", "why_it_matters": "Not all work has the same knowledge, security, coordination, or ownership requirements.", "validation_signal": "Compare workstream complexity, dependency count, review requirements, incident risk, and knowledge availability.", "persona_relevance": [ "CTO", "VP Engineering", "CIO" ], "use_cases": [ "build_distributed_capacity_strategy", "improve_existing_capacity_topology" ], "required_sources": [ "work tracker", "service ownership map", "incident system", "architecture documentation" ], "minimum_evidence": [ "workstream complexity", "dependency count", "review requirements", "knowledge availability" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Topology Fit", "Knowledge Transfer Readiness", "Governance Completeness" ], "risk_flags": [ "unsafe_distribution", "knowledge_gap" ], "recommended_report_type": "Capacity Topology Readiness Report", "intent": "diagnostic", "level": "cto", "tags": [ "topology", "distribution", "workstreams" ], "related_concepts": [ "workstream_allocation", "distributed_capacity" ], "doctrine_answer": "The safest workstreams to distribute are low-coupling, explicitly documented, testable, observable, access-bounded, reversible, and supported by sufficient internal review and escalation capacity.", "answer_card_template": { "answer_type": "capacity_topology_answer", "good_answer_pattern": "A strong answer directly answers: \"Which engineering workstreams are safest to distribute beyond the current core team?\" Validation method: Compare workstream complexity, dependency count, review requirements, incident risk, and knowledge availability. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Topology Fit, Knowledge Transfer Readiness, Governance Completeness.", "common_failure_pattern": "A weak answer gives a generic distributed capacity topology diagnosis instead of proving this question with work tracker, service ownership map, incident system, and related approved sources. It misses the operating risk: Not all work has the same knowledge, security, coordination, or ownership requirements.", "recommended_report_section": "Capacity Topology Readiness Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "topology-002", "domain": "distributed_capacity_topology", "question": "Which workstreams should remain internally owned?", "why_it_matters": "Some work requires direct architectural, product, security, or customer-context control.", "validation_signal": "Identify work tied to strategic IP, high-risk systems, sensitive data, architecture authority, or irreversible production impact.", "persona_relevance": [ "CTO", "CIO" ], "use_cases": [ "build_distributed_capacity_strategy", "evaluate_governance_security_and_ip_risk" ], "required_sources": [ "architecture records", "security classification", "service ownership map", "incident system" ], "minimum_evidence": [ "IP sensitivity", "production impact", "data sensitivity", "architecture authority" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Topology Fit", "Governance Completeness" ], "risk_flags": [ "ip_exposure", "loss_of_architecture_control" ], "recommended_report_type": "Governance, Security, and IP Control Report", "intent": "diagnostic", "level": "cto", "tags": [ "internal-ownership", "risk", "security" ], "related_concepts": [ "internal_control", "ownership_boundary" ], "doctrine_answer": "Work should remain internally owned when it controls strategic architecture, sensitive data, security authority, customer context, regulated decisions, critical IP, or irreversible production impact.", "answer_card_template": { "answer_type": "capacity_topology_answer", "good_answer_pattern": "A strong answer directly answers: \"Which workstreams should remain internally owned?\" Validation method: Identify work tied to strategic IP, high-risk systems, sensitive data, architecture authority, or irreversible production impact. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Topology Fit, Governance Completeness.", "common_failure_pattern": "A weak answer gives a generic distributed capacity topology diagnosis instead of proving this question with architecture records, security classification, service ownership map, and related approved sources. It misses the operating risk: Some work requires direct architectural, product, security, or customer-context control.", "recommended_report_section": "Governance, Security, and IP Control Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "topology-003", "domain": "distributed_capacity_topology", "question": "Which capacity topology best matches each workstream?", "why_it_matters": "Internal hiring, external partners, nearshore, offshore, platform investment, and AI agents solve different constraints.", "validation_signal": "Map workstreams to skill fit, ownership requirements, time-zone needs, governance constraints, and performance evidence.", "persona_relevance": [ "CTO", "CIO", "VP Engineering" ], "use_cases": [ "build_distributed_capacity_strategy", "improve_existing_capacity_topology" ], "required_sources": [ "work tracker", "skills inventory", "service ownership map", "security policy", "delivery telemetry" ], "minimum_evidence": [ "skill fit", "ownership requirements", "timezone needs", "governance constraints" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Topology Fit", "Capacity Reality", "Governance Completeness" ], "risk_flags": [ "topology_mismatch", "coordination_cost" ], "recommended_report_type": "Capacity Topology Readiness Report", "intent": "diagnostic", "level": "cto", "tags": [ "topology-fit", "allocation", "strategy" ], "related_concepts": [ "capacity_topology", "sourcing_topology" ], "doctrine_answer": "The correct topology is selected per workstream by matching skill scarcity, ownership depth, coordination latency, security boundary, review capacity, execution determinism, and telemetry coverage to the available operating model.", "answer_card_template": { "answer_type": "capacity_topology_answer", "good_answer_pattern": "A strong answer directly answers: \"Which capacity topology best matches each workstream?\" Validation method: Map workstreams to skill fit, ownership requirements, time-zone needs, governance constraints, and performance evidence. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Topology Fit, Capacity Reality, Governance Completeness.", "common_failure_pattern": "A weak answer gives a generic distributed capacity topology diagnosis instead of proving this question with work tracker, skills inventory, service ownership map, and related approved sources. It misses the operating risk: Internal hiring, external partners, nearshore, offshore, platform investment, and AI agents solve different constraints.", "recommended_report_section": "Capacity Topology Readiness Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "topology-004", "domain": "distributed_capacity_topology", "question": "Where does time-zone overlap materially affect cycle time?", "why_it_matters": "Distributed capacity fails when decision latency exceeds the work's coordination tolerance.", "validation_signal": "Compare blocked time, handoff delay, review latency, meeting dependency, and incident response requirements across work classes.", "persona_relevance": [ "CTO", "VP Engineering", "Platform Leader" ], "use_cases": [ "build_distributed_capacity_strategy", "improve_existing_capacity_topology", "diagnose_delivery_latency" ], "required_sources": [ "Jira or Linear", "GitHub or GitLab", "calendar metadata if approved and aggregated", "incident system" ], "minimum_evidence": [ "blocked time", "handoff delay", "review latency", "incident response requirements" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Topology Fit", "Telemetry Trust", "Governance Completeness" ], "risk_flags": [ "decision_latency", "handoff_delay", "incident_response_risk" ], "recommended_report_type": "Capacity Topology Readiness Report", "intent": "diagnostic", "level": "cto", "tags": [ "timezone", "cycle-time", "distributed" ], "related_concepts": [ "coordination_tolerance", "handoff_delay" ], "doctrine_answer": "Time-zone overlap materially affects cycle time when work requires same-window architecture decisions, rapid review, coordinated releases, customer response, or incident control; asynchronous work with explicit interfaces is less sensitive.", "answer_card_template": { "answer_type": "capacity_topology_answer", "good_answer_pattern": "A strong answer directly answers: \"Where does time-zone overlap materially affect cycle time?\" Validation method: Compare blocked time, handoff delay, review latency, meeting dependency, and incident response requirements across work classes. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Topology Fit, Telemetry Trust, Governance Completeness.", "common_failure_pattern": "A weak answer gives a generic distributed capacity topology diagnosis instead of proving this question with Jira or Linear, GitHub or GitLab, calendar metadata if approved and aggregated, and related approved sources. It misses the operating risk: Distributed capacity fails when decision latency exceeds the work's coordination tolerance.", "recommended_report_section": "Capacity Topology Readiness Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "topology-005", "domain": "distributed_capacity_topology", "question": "What review capacity must exist before adding distributed contributors?", "why_it_matters": "Additional contributors can increase bottlenecks if review and architecture authority do not scale.", "validation_signal": "Compare PR volume, review queue age, reviewer availability, correction rate, and approval latency before and after capacity changes.", "persona_relevance": [ "CTO", "VP Engineering" ], "use_cases": [ "determine_capacity_absorption_readiness", "improve_existing_capacity_topology" ], "required_sources": [ "pull request system", "work tracker", "architecture reviews" ], "minimum_evidence": [ "PR volume", "review queue age", "reviewer availability", "correction rate" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Capacity Reality", "Topology Fit", "Execution Determinism" ], "risk_flags": [ "review_saturation", "correction_load" ], "recommended_report_type": "Capacity Topology Readiness Report", "intent": "diagnostic", "level": "cto", "tags": [ "review-capacity", "contributors", "scaling" ], "related_concepts": [ "review_capacity", "distributed_contributors" ], "doctrine_answer": "Distributed contributors should be added only after reviewer availability and architecture authority can meet a defined review service level without increasing correction rate, approval latency, or queue age.", "answer_card_template": { "answer_type": "capacity_topology_answer", "good_answer_pattern": "A strong answer directly answers: \"What review capacity must exist before adding distributed contributors?\" Validation method: Compare PR volume, review queue age, reviewer availability, correction rate, and approval latency before and after capacity changes. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Capacity Reality, Topology Fit, Execution Determinism.", "common_failure_pattern": "A weak answer gives a generic distributed capacity topology diagnosis instead of proving this question with pull request system, work tracker, architecture reviews. It misses the operating risk: Additional contributors can increase bottlenecks if review and architecture authority do not scale.", "recommended_report_section": "Capacity Topology Readiness Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "topology-006", "domain": "distributed_capacity_topology", "question": "Which systems or services are ready for external or distributed ownership?", "why_it_matters": "Ownership requires knowledge, test coverage, runbooks, telemetry, and clear escalation paths.", "validation_signal": "Score each service by documentation quality, incident history, test reliability, deployment reproducibility, and ownership clarity.", "persona_relevance": [ "CTO", "CIO", "VP Engineering", "Platform Leader" ], "use_cases": [ "improve_existing_capacity_topology", "evaluate_governance_security_and_ip_risk" ], "required_sources": [ "service catalog", "runbooks", "CI/CD", "deployment system", "incident system" ], "minimum_evidence": [ "documentation quality", "test reliability", "deployment reproducibility", "ownership clarity" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Topology Fit", "Knowledge Transfer Readiness", "Execution Determinism" ], "risk_flags": [ "ownership_ambiguity", "service_transfer_risk" ], "recommended_report_type": "Knowledge and Architecture Memory Report", "intent": "diagnostic", "level": "cto", "tags": [ "ownership", "services", "distributed" ], "related_concepts": [ "service_ownership", "external_ownership" ], "doctrine_answer": "A service is ready for distributed ownership when ownership is explicit and current documentation, tests, deployment controls, telemetry, runbooks, escalation paths, and rollback procedures make operation reproducible.", "answer_card_template": { "answer_type": "capacity_topology_answer", "good_answer_pattern": "A strong answer directly answers: \"Which systems or services are ready for external or distributed ownership?\" Validation method: Score each service by documentation quality, incident history, test reliability, deployment reproducibility, and ownership clarity. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Topology Fit, Knowledge Transfer Readiness, Execution Determinism.", "common_failure_pattern": "A weak answer gives a generic distributed capacity topology diagnosis instead of proving this question with service catalog, runbooks, CI/CD, and related approved sources. It misses the operating risk: Ownership requires knowledge, test coverage, runbooks, telemetry, and clear escalation paths.", "recommended_report_section": "Knowledge and Architecture Memory Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "topology-007", "domain": "distributed_capacity_topology", "question": "What access should each contributor type have?", "why_it_matters": "Capacity topology creates security and IP exposure if access is not role- and risk-based.", "validation_signal": "Map contributor types to repository, environment, data, secrets, deployment, and production permissions.", "persona_relevance": [ "CIO", "CTO", "AI Governance Leader" ], "use_cases": [ "evaluate_governance_security_and_ip_risk", "improve_existing_capacity_topology" ], "required_sources": [ "identity provider", "repository permissions", "deployment permissions", "security policy" ], "minimum_evidence": [ "access class", "repository scope", "environment permission", "production authority" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Governance Completeness", "Topology Fit" ], "risk_flags": [ "access_overreach", "ip_exposure", "production_risk" ], "recommended_report_type": "Governance, Security, and IP Control Report", "intent": "diagnostic", "level": "cio", "tags": [ "access", "permissions", "security" ], "related_concepts": [ "access_boundary", "contributor_type" ], "doctrine_answer": "Each contributor type should receive the least repository, environment, data, secret, deployment, and production access required for its approved work, with time bounds, auditability, and revocation.", "answer_card_template": { "answer_type": "capacity_topology_answer", "good_answer_pattern": "A strong answer directly answers: \"What access should each contributor type have?\" Validation method: Map contributor types to repository, environment, data, secrets, deployment, and production permissions. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Governance Completeness, Topology Fit.", "common_failure_pattern": "A weak answer gives a generic distributed capacity topology diagnosis instead of proving this question with identity provider, repository permissions, deployment permissions, and related approved sources. It misses the operating risk: Capacity topology creates security and IP exposure if access is not role- and risk-based.", "recommended_report_section": "Governance, Security, and IP Control Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "topology-008", "domain": "distributed_capacity_topology", "question": "What is the ramp curve from onboarding to independent contribution?", "why_it_matters": "Capacity is not real until contributors can produce safely without excessive supervision.", "validation_signal": "Measure time to first accepted PR, time to independent task completion, review correction rate, and escalation frequency.", "persona_relevance": [ "VP Engineering", "CTO" ], "use_cases": [ "determine_capacity_absorption_readiness", "improve_existing_capacity_topology" ], "required_sources": [ "work tracker", "pull request system", "onboarding records", "escalation logs" ], "minimum_evidence": [ "time to first accepted PR", "independent task completion", "correction rate", "escalation frequency" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Knowledge Transfer Readiness", "Capacity Reality" ], "risk_flags": [ "slow_ramp", "supervision_overhead" ], "recommended_report_type": "Knowledge and Architecture Memory Report", "intent": "diagnostic", "level": "engineering_lead", "tags": [ "onboarding", "ramp", "independence" ], "related_concepts": [ "ramp_curve", "independent_contribution" ], "doctrine_answer": "The ramp curve is the measured progression from access and context acquisition to first accepted change, independent task completion, production-safe contribution, and ownership with declining correction and escalation rates.", "answer_card_template": { "answer_type": "capacity_topology_answer", "good_answer_pattern": "A strong answer directly answers: \"What is the ramp curve from onboarding to independent contribution?\" Validation method: Measure time to first accepted PR, time to independent task completion, review correction rate, and escalation frequency. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Knowledge Transfer Readiness, Capacity Reality.", "common_failure_pattern": "A weak answer gives a generic distributed capacity topology diagnosis instead of proving this question with work tracker, pull request system, onboarding records, and related approved sources. It misses the operating risk: Capacity is not real until contributors can produce safely without excessive supervision.", "recommended_report_section": "Knowledge and Architecture Memory Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "topology-009", "domain": "distributed_capacity_topology", "question": "Which communication rituals reduce decision latency?", "why_it_matters": "Distributed systems need explicit coordination mechanisms.", "validation_signal": "Compare blocked states, decision wait time, rework, handoff delay, and meeting load before and after ritual changes.", "persona_relevance": [ "VP Engineering", "Platform Leader" ], "use_cases": [ "diagnose_delivery_latency", "improve_existing_capacity_topology" ], "required_sources": [ "work tracker", "decision records", "calendar metadata if approved and aggregated", "pull request system" ], "minimum_evidence": [ "blocked states", "decision wait time", "handoff delay", "meeting load" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Topology Fit", "Telemetry Trust" ], "risk_flags": [ "coordination_overhead", "meeting_load" ], "recommended_report_type": "Capacity Topology Readiness Report", "intent": "diagnostic", "level": "engineering_lead", "tags": [ "rituals", "coordination", "latency" ], "related_concepts": [ "decision_latency", "operating_rituals" ], "doctrine_answer": "Useful communication rituals reduce decision latency by making ownership, decision records, handoffs, escalation windows, and unresolved blockers explicit without adding more meeting load than the delay they remove.", "answer_card_template": { "answer_type": "capacity_topology_answer", "good_answer_pattern": "A strong answer directly answers: \"Which communication rituals reduce decision latency?\" Validation method: Compare blocked states, decision wait time, rework, handoff delay, and meeting load before and after ritual changes. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Topology Fit, Telemetry Trust.", "common_failure_pattern": "A weak answer gives a generic distributed capacity topology diagnosis instead of proving this question with work tracker, decision records, calendar metadata if approved and aggregated, and related approved sources. It misses the operating risk: Distributed systems need explicit coordination mechanisms.", "recommended_report_section": "Capacity Topology Readiness Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "topology-010", "domain": "distributed_capacity_topology", "question": "What is the exit path if a capacity topology underperforms?", "why_it_matters": "Governance requires reversibility, not only rollout plans.", "validation_signal": "Verify ownership transfer, documentation continuity, access removal, IP control, work reassignment, and service continuity plans.", "persona_relevance": [ "CIO", "CTO" ], "use_cases": [ "evaluate_governance_security_and_ip_risk", "build_distributed_capacity_strategy" ], "required_sources": [ "contracts or operating agreements", "access policy", "service ownership map", "documentation inventory" ], "minimum_evidence": [ "exit plan", "access removal", "ownership transfer", "service continuity" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Governance Completeness", "Topology Fit" ], "risk_flags": [ "irreversible_topology", "continuity_risk" ], "recommended_report_type": "Governance, Security, and IP Control Report", "intent": "diagnostic", "level": "cio", "tags": [ "exit-plan", "governance", "reversibility" ], "related_concepts": [ "exit_readiness", "reversibility" ], "doctrine_answer": "A governed exit path preserves service continuity through documented ownership transfer, knowledge capture, access revocation, IP confirmation, work reassignment, and rollback or replacement triggers defined before rollout.", "answer_card_template": { "answer_type": "capacity_topology_answer", "good_answer_pattern": "A strong answer directly answers: \"What is the exit path if a capacity topology underperforms?\" Validation method: Verify ownership transfer, documentation continuity, access removal, IP control, work reassignment, and service continuity plans. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Governance Completeness, Topology Fit.", "common_failure_pattern": "A weak answer gives a generic distributed capacity topology diagnosis instead of proving this question with contracts or operating agreements, access policy, service ownership map, and related approved sources. It misses the operating risk: Governance requires reversibility, not only rollout plans.", "recommended_report_section": "Governance, Security, and IP Control Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "knowledge-001", "domain": "knowledge_architecture_memory", "question": "Which parts of the engineering system depend on tribal knowledge?", "why_it_matters": "Tribal knowledge limits distributed execution and safe AI assistance.", "validation_signal": "Identify repeated escalations, undocumented decisions, onboarding blockers, and work items requiring specific individuals.", "persona_relevance": [ "CTO", "VP Engineering", "Platform Leader" ], "use_cases": [ "improve_existing_capacity_topology", "assess_agentic_sdlc_readiness", "determine_capacity_absorption_readiness" ], "required_sources": [ "work tracker", "service ownership map", "documentation inventory", "incident system" ], "minimum_evidence": [ "repeated escalation", "undocumented decision", "onboarding blocker", "individual dependency" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Knowledge Transfer Readiness", "Topology Fit" ], "risk_flags": [ "tribal_knowledge", "single_point_of_context" ], "recommended_report_type": "Knowledge and Architecture Memory Report", "intent": "diagnostic", "level": "cto", "tags": [ "knowledge", "tribal-knowledge", "architecture" ], "related_concepts": [ "explicit_knowledge", "knowledge_dependency" ], "doctrine_answer": "Tribal-knowledge dependencies are system areas where delivery, review, deployment, or incident response repeatedly requires specific individuals because the necessary decisions, constraints, or procedures are not durable artifacts.", "answer_card_template": { "answer_type": "knowledge_memory_answer", "good_answer_pattern": "A strong answer directly answers: \"Which parts of the engineering system depend on tribal knowledge?\" Validation method: Identify repeated escalations, undocumented decisions, onboarding blockers, and work items requiring specific individuals. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Knowledge Transfer Readiness, Topology Fit.", "common_failure_pattern": "A weak answer gives a generic knowledge architecture memory diagnosis instead of proving this question with work tracker, service ownership map, documentation inventory, and related approved sources. It misses the operating risk: Tribal knowledge limits distributed execution and safe AI assistance.", "recommended_report_section": "Knowledge and Architecture Memory Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "knowledge-002", "domain": "knowledge_architecture_memory", "question": "How current are architecture decision records?", "why_it_matters": "Distributed contributors and agents need explicit architectural intent.", "validation_signal": "Compare architecture records against current services, dependencies, incidents, and recent implementation choices.", "persona_relevance": [ "CTO", "Platform Leader" ], "use_cases": [ "improve_existing_capacity_topology", "assess_agentic_sdlc_readiness" ], "required_sources": [ "architecture decision records", "service catalog", "repository history", "incident reviews" ], "minimum_evidence": [ "ADR freshness", "service dependency match", "recent decision coverage", "incident linkage" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Knowledge Transfer Readiness", "Governance Completeness" ], "risk_flags": [ "architecture_drift", "stale_decision_memory" ], "recommended_report_type": "Knowledge and Architecture Memory Report", "intent": "diagnostic", "level": "cto", "tags": [ "adr", "architecture", "documentation" ], "related_concepts": [ "architecture_memory", "decision_record" ], "doctrine_answer": "Architecture decision records are current only when they still match deployed services, dependencies, constraints, ownership, and recent implementation and incident evidence; document age alone does not establish validity.", "answer_card_template": { "answer_type": "knowledge_memory_answer", "good_answer_pattern": "A strong answer directly answers: \"How current are architecture decision records?\" Validation method: Compare architecture records against current services, dependencies, incidents, and recent implementation choices. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Knowledge Transfer Readiness, Governance Completeness.", "common_failure_pattern": "A weak answer gives a generic knowledge architecture memory diagnosis instead of proving this question with architecture decision records, service catalog, repository history, and related approved sources. It misses the operating risk: Distributed contributors and agents need explicit architectural intent.", "recommended_report_section": "Knowledge and Architecture Memory Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "knowledge-003", "domain": "knowledge_architecture_memory", "question": "Which services have clear ownership maps?", "why_it_matters": "Ownership ambiguity creates delays, rework, and incident risk.", "validation_signal": "Verify each service has named owners, escalation paths, review authorities, and support expectations.", "persona_relevance": [ "CTO", "VP Engineering", "Platform Leader" ], "use_cases": [ "improve_existing_capacity_topology", "diagnose_engineering_capacity" ], "required_sources": [ "service catalog", "ownership map", "incident system", "pull request system" ], "minimum_evidence": [ "named owner", "escalation path", "review authority", "support expectation" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Knowledge Transfer Readiness", "Governance Completeness" ], "risk_flags": [ "ownership_ambiguity", "incident_delay" ], "recommended_report_type": "Knowledge and Architecture Memory Report", "intent": "diagnostic", "level": "cto", "tags": [ "ownership", "service-map", "runbooks" ], "related_concepts": [ "service_ownership", "escalation_path" ], "doctrine_answer": "A clear service ownership map names the accountable owner, review authority, operational responder, escalation path, and support expectation for every production service and critical dependency.", "answer_card_template": { "answer_type": "knowledge_memory_answer", "good_answer_pattern": "A strong answer directly answers: \"Which services have clear ownership maps?\" Validation method: Verify each service has named owners, escalation paths, review authorities, and support expectations. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Knowledge Transfer Readiness, Governance Completeness.", "common_failure_pattern": "A weak answer gives a generic knowledge architecture memory diagnosis instead of proving this question with service catalog, ownership map, incident system, and related approved sources. It misses the operating risk: Ownership ambiguity creates delays, rework, and incident risk.", "recommended_report_section": "Knowledge and Architecture Memory Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "knowledge-004", "domain": "knowledge_architecture_memory", "question": "What knowledge must a contributor have before production-impacting work?", "why_it_matters": "Unsafe delegation often starts with insufficient context.", "validation_signal": "Define required service knowledge, system constraints, tests, deployment process, incident history, and approval boundaries.", "persona_relevance": [ "CTO", "CIO", "VP Engineering" ], "use_cases": [ "improve_existing_capacity_topology", "evaluate_governance_security_and_ip_risk" ], "required_sources": [ "runbooks", "deployment procedures", "test strategy", "incident reviews", "approval policy" ], "minimum_evidence": [ "required knowledge checklist", "deployment process", "incident history", "approval boundary" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Knowledge Transfer Readiness", "Governance Completeness" ], "risk_flags": [ "unsafe_delegation", "production_impact" ], "recommended_report_type": "Knowledge and Architecture Memory Report", "intent": "diagnostic", "level": "cto", "tags": [ "production", "delegation", "knowledge" ], "related_concepts": [ "production_readiness", "approval_boundary" ], "doctrine_answer": "Before production-impacting work, a contributor needs verified knowledge of service behavior, architecture constraints, data sensitivity, tests, deployment and rollback procedures, incident history, and approval boundaries.", "answer_card_template": { "answer_type": "knowledge_memory_answer", "good_answer_pattern": "A strong answer directly answers: \"What knowledge must a contributor have before production-impacting work?\" Validation method: Define required service knowledge, system constraints, tests, deployment process, incident history, and approval boundaries. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Knowledge Transfer Readiness, Governance Completeness.", "common_failure_pattern": "A weak answer gives a generic knowledge architecture memory diagnosis instead of proving this question with runbooks, deployment procedures, test strategy, and related approved sources. It misses the operating risk: Unsafe delegation often starts with insufficient context.", "recommended_report_section": "Knowledge and Architecture Memory Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "knowledge-005", "domain": "knowledge_architecture_memory", "question": "Which knowledge sources are safe for AI retrieval?", "why_it_matters": "Agentic workflows need context without exposing secrets, customer data, or sensitive records.", "validation_signal": "Classify documentation, tickets, code references, runbooks, logs, and incidents by sensitivity and retrieval permission.", "persona_relevance": [ "CIO", "AI Governance Leader", "Platform Leader" ], "use_cases": [ "assess_agentic_sdlc_readiness", "evaluate_governance_security_and_ip_risk" ], "required_sources": [ "documentation system", "security classification", "AI tool policy", "identity provider" ], "minimum_evidence": [ "sensitivity class", "retrieval permission", "redaction rule", "audit requirement" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Agent Delegation Safety", "Governance Completeness" ], "risk_flags": [ "data_exposure", "unsafe_ai_retrieval" ], "recommended_report_type": "Agent Delegation Safety Matrix", "intent": "diagnostic", "level": "cio", "tags": [ "ai-retrieval", "privacy", "knowledge" ], "related_concepts": [ "retrieval_boundary", "privacy_class" ], "doctrine_answer": "AI retrieval should be limited to approved, access-controlled knowledge whose sensitivity is classified and whose content excludes secrets, customer records, privileged logs, and other data outside the agent's task boundary.", "answer_card_template": { "answer_type": "knowledge_memory_answer", "good_answer_pattern": "A strong answer directly answers: \"Which knowledge sources are safe for AI retrieval?\" Validation method: Classify documentation, tickets, code references, runbooks, logs, and incidents by sensitivity and retrieval permission. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Agent Delegation Safety, Governance Completeness.", "common_failure_pattern": "A weak answer gives a generic knowledge architecture memory diagnosis instead of proving this question with documentation system, security classification, AI tool policy, and related approved sources. It misses the operating risk: Agentic workflows need context without exposing secrets, customer data, or sensitive records.", "recommended_report_section": "Agent Delegation Safety Matrix", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "knowledge-006", "domain": "knowledge_architecture_memory", "question": "Where does documentation drift create delivery risk?", "why_it_matters": "Outdated documentation causes incorrect decisions by humans and agents.", "validation_signal": "Compare documented procedures against actual deployment paths, incident response steps, code ownership, and pipeline behavior.", "persona_relevance": [ "VP Engineering", "Platform Leader", "AI Governance Leader" ], "use_cases": [ "diagnose_engineering_capacity", "assess_agentic_sdlc_readiness" ], "required_sources": [ "documentation system", "CI/CD", "deployment system", "incident system" ], "minimum_evidence": [ "documented procedure", "actual procedure", "drift instance", "risk impact" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Knowledge Transfer Readiness", "Execution Determinism" ], "risk_flags": [ "documentation_drift", "agent_error" ], "recommended_report_type": "Knowledge and Architecture Memory Report", "intent": "diagnostic", "level": "engineering_lead", "tags": [ "documentation-drift", "risk", "agents" ], "related_concepts": [ "doc_freshness", "procedure_drift" ], "doctrine_answer": "Documentation drift creates delivery risk wherever documented ownership, deployment, recovery, architecture, or policy no longer matches observed system behavior and can cause a human or agent to take an invalid action.", "answer_card_template": { "answer_type": "knowledge_memory_answer", "good_answer_pattern": "A strong answer directly answers: \"Where does documentation drift create delivery risk?\" Validation method: Compare documented procedures against actual deployment paths, incident response steps, code ownership, and pipeline behavior. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Knowledge Transfer Readiness, Execution Determinism.", "common_failure_pattern": "A weak answer gives a generic knowledge architecture memory diagnosis instead of proving this question with documentation system, CI/CD, deployment system, and related approved sources. It misses the operating risk: Outdated documentation causes incorrect decisions by humans and agents.", "recommended_report_section": "Knowledge and Architecture Memory Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "knowledge-007", "domain": "knowledge_architecture_memory", "question": "How are incidents converted into durable system memory?", "why_it_matters": "Learning requires failures to update rules, tests, runbooks, and agent instructions.", "validation_signal": "Verify incident outcomes produced updated tests, documentation, alerts, workflow rules, or governance constraints.", "persona_relevance": [ "CTO", "Platform Leader", "VP Engineering" ], "use_cases": [ "diagnose_engineering_capacity", "assess_agentic_sdlc_readiness" ], "required_sources": [ "incident system", "runbooks", "test suite", "workflow rules", "agent instructions" ], "minimum_evidence": [ "incident outcome", "updated test", "updated runbook", "new workflow rule" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Knowledge Transfer Readiness", "Upside Potential" ], "risk_flags": [ "repeat_failure", "learning_gap" ], "recommended_report_type": "Knowledge and Architecture Memory Report", "intent": "diagnostic", "level": "cto", "tags": [ "incidents", "learning", "memory" ], "related_concepts": [ "incident_memory", "durable_learning" ], "doctrine_answer": "An incident becomes durable system memory only when verified lessons update executable controls such as tests, alerts, runbooks, ownership, architecture records, workflow rules, or agent instructions.", "answer_card_template": { "answer_type": "knowledge_memory_answer", "good_answer_pattern": "A strong answer directly answers: \"How are incidents converted into durable system memory?\" Validation method: Verify incident outcomes produced updated tests, documentation, alerts, workflow rules, or governance constraints. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Knowledge Transfer Readiness, Upside Potential.", "common_failure_pattern": "A weak answer gives a generic knowledge architecture memory diagnosis instead of proving this question with incident system, runbooks, test suite, and related approved sources. It misses the operating risk: Learning requires failures to update rules, tests, runbooks, and agent instructions.", "recommended_report_section": "Knowledge and Architecture Memory Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "knowledge-008", "domain": "knowledge_architecture_memory", "question": "What evidence proves a distributed contributor is ready for ownership?", "why_it_matters": "Ownership should be evidence-based, not tenure-based.", "validation_signal": "Review accepted work, correction rate, service understanding, incident handling, deployment success, and escalation behavior.", "persona_relevance": [ "VP Engineering", "CTO" ], "use_cases": [ "improve_existing_capacity_topology", "determine_capacity_absorption_readiness" ], "required_sources": [ "pull request system", "work tracker", "incident system", "deployment system" ], "minimum_evidence": [ "accepted work", "correction rate", "deployment success", "escalation behavior" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Knowledge Transfer Readiness", "Topology Fit" ], "risk_flags": [ "premature_ownership", "service_risk" ], "recommended_report_type": "Capacity Topology Readiness Report", "intent": "diagnostic", "level": "engineering_lead", "tags": [ "ownership-readiness", "distributed", "evidence" ], "related_concepts": [ "ownership_readiness", "evidence_based_delegation" ], "doctrine_answer": "Ownership readiness is demonstrated by accepted work, accurate system explanations, reliable deployments, low correction rates, sound incident behavior, and appropriate escalation across a representative evidence window.", "answer_card_template": { "answer_type": "knowledge_memory_answer", "good_answer_pattern": "A strong answer directly answers: \"What evidence proves a distributed contributor is ready for ownership?\" Validation method: Review accepted work, correction rate, service understanding, incident handling, deployment success, and escalation behavior. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Knowledge Transfer Readiness, Topology Fit.", "common_failure_pattern": "A weak answer gives a generic knowledge architecture memory diagnosis instead of proving this question with pull request system, work tracker, incident system, and related approved sources. It misses the operating risk: Ownership should be evidence-based, not tenure-based.", "recommended_report_section": "Capacity Topology Readiness Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "execution-001", "domain": "execution_harness", "question": "How standardized are CI/CD pipelines across teams, services, and contributor types?", "why_it_matters": "Distributed and AI-assisted capacity requires reproducible execution, not local delivery customs.", "validation_signal": "Compare pipeline templates, required gates, deployment paths, manual overrides, and exception frequency.", "persona_relevance": [ "CTO", "VP Engineering", "DevOps Leader" ], "use_cases": [ "determine_capacity_absorption_readiness", "improve_existing_capacity_topology" ], "required_sources": [ "CI/CD", "deployment system", "repository templates", "exception logs" ], "minimum_evidence": [ "pipeline template", "required gate", "manual override", "exception frequency" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Execution Determinism", "Governance Completeness" ], "risk_flags": [ "pipeline_variance", "manual_override" ], "recommended_report_type": "Execution Determinism Report", "intent": "diagnostic", "level": "cto", "tags": [ "ci-cd", "standardization", "execution" ], "related_concepts": [ "execution_harness", "pipeline_standardization" ], "doctrine_answer": "CI/CD is standardized when teams and contributor types use versioned pipeline templates, required quality and approval gates, consistent deployment paths, controlled exceptions, and equivalent audit evidence.", "answer_card_template": { "answer_type": "execution_control_answer", "good_answer_pattern": "A strong answer directly answers: \"How standardized are CI/CD pipelines across teams, services, and contributor types?\" Validation method: Compare pipeline templates, required gates, deployment paths, manual overrides, and exception frequency. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Execution Determinism, Governance Completeness.", "common_failure_pattern": "A weak answer gives a generic execution harness diagnosis instead of proving this question with CI/CD, deployment system, repository templates, and related approved sources. It misses the operating risk: Distributed and AI-assisted capacity requires reproducible execution, not local delivery customs.", "recommended_report_section": "Execution Determinism Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "execution-002", "domain": "execution_harness", "question": "Where does execution variance enter the delivery system?", "why_it_matters": "Variance hides inside local workflow differences, skipped gates, environment drift, and undocumented release paths.", "validation_signal": "Trace delivery flows by team and identify manual steps, skipped gates, divergent templates, and environment-specific behavior.", "persona_relevance": [ "VP Engineering", "DevOps Leader", "Platform Leader" ], "use_cases": [ "diagnose_engineering_capacity", "determine_capacity_absorption_readiness" ], "required_sources": [ "CI/CD", "deployment system", "work tracker", "environment inventory" ], "minimum_evidence": [ "manual step", "skipped gate", "template divergence", "environment drift" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Execution Determinism", "Telemetry Trust" ], "risk_flags": [ "execution_drift", "environment_drift" ], "recommended_report_type": "Execution Determinism Report", "intent": "diagnostic", "level": "engineering_lead", "tags": [ "variance", "delivery", "environment" ], "related_concepts": [ "execution_variance", "environment_drift" ], "doctrine_answer": "Execution variance enters wherever teams use divergent templates, manual steps, skipped gates, environment-specific behavior, undocumented release paths, or ungoverned overrides that change outcomes for equivalent work.", "answer_card_template": { "answer_type": "execution_control_answer", "good_answer_pattern": "A strong answer directly answers: \"Where does execution variance enter the delivery system?\" Validation method: Trace delivery flows by team and identify manual steps, skipped gates, divergent templates, and environment-specific behavior. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Execution Determinism, Telemetry Trust.", "common_failure_pattern": "A weak answer gives a generic execution harness diagnosis instead of proving this question with CI/CD, deployment system, work tracker, and related approved sources. It misses the operating risk: Variance hides inside local workflow differences, skipped gates, environment drift, and undocumented release paths.", "recommended_report_section": "Execution Determinism Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "execution-003", "domain": "execution_harness", "question": "Which SDLC controls are system-enforced versus manually enforced?", "why_it_matters": "Manual enforcement breaks under scale, distribution, and agentic speed.", "validation_signal": "Classify each SDLC control as automated, policy-enforced, manually enforced, or undocumented.", "persona_relevance": [ "CIO", "CTO", "DevOps Leader" ], "use_cases": [ "evaluate_governance_security_and_ip_risk", "determine_capacity_absorption_readiness" ], "required_sources": [ "CI/CD", "policy documentation", "repository settings", "approval workflow" ], "minimum_evidence": [ "control class", "automation status", "manual gate", "undocumented exception" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Execution Determinism", "Governance Completeness" ], "risk_flags": [ "manual_control_failure", "policy_drift" ], "recommended_report_type": "Execution Determinism Report", "intent": "diagnostic", "level": "cio", "tags": [ "controls", "automation", "governance" ], "related_concepts": [ "system_enforcement", "manual_control" ], "doctrine_answer": "A control is system-enforced when the delivery platform automatically applies and records it; a policy, checklist, or reviewer habit is manually enforced and should not be treated as deterministic control.", "answer_card_template": { "answer_type": "execution_control_answer", "good_answer_pattern": "A strong answer directly answers: \"Which SDLC controls are system-enforced versus manually enforced?\" Validation method: Classify each SDLC control as automated, policy-enforced, manually enforced, or undocumented. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Execution Determinism, Governance Completeness.", "common_failure_pattern": "A weak answer gives a generic execution harness diagnosis instead of proving this question with CI/CD, policy documentation, repository settings, and related approved sources. It misses the operating risk: Manual enforcement breaks under scale, distribution, and agentic speed.", "recommended_report_section": "Execution Determinism Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "execution-004", "domain": "execution_harness", "question": "How reproducible are production deployments across services?", "why_it_matters": "A topology can scale only when deployments behave as governed system states.", "validation_signal": "Compare deployment inputs, environment state, approval paths, rollback readiness, and post-deploy outcomes across services.", "persona_relevance": [ "CTO", "DevOps Leader", "Platform Leader" ], "use_cases": [ "determine_capacity_absorption_readiness", "evaluate_governance_security_and_ip_risk" ], "required_sources": [ "deployment system", "CI/CD", "environment inventory", "rollback records" ], "minimum_evidence": [ "deployment input", "approval path", "rollback record", "post-deploy outcome" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Execution Determinism", "Governance Completeness" ], "risk_flags": [ "deployment_non_reproducibility", "rollback_gap" ], "recommended_report_type": "Execution Determinism Report", "intent": "diagnostic", "level": "cto", "tags": [ "deployment", "reproducibility", "rollback" ], "related_concepts": [ "deployment_determinism", "release_path" ], "doctrine_answer": "Production deployments are reproducible when equivalent versioned inputs, environment state, approvals, and pipeline rules produce consistent releases with tested rollback paths and explainable outcomes across services.", "answer_card_template": { "answer_type": "execution_control_answer", "good_answer_pattern": "A strong answer directly answers: \"How reproducible are production deployments across services?\" Validation method: Compare deployment inputs, environment state, approval paths, rollback readiness, and post-deploy outcomes across services. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Execution Determinism, Governance Completeness.", "common_failure_pattern": "A weak answer gives a generic execution harness diagnosis instead of proving this question with deployment system, CI/CD, environment inventory, and related approved sources. It misses the operating risk: A topology can scale only when deployments behave as governed system states.", "recommended_report_section": "Execution Determinism Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "execution-005", "domain": "execution_harness", "question": "Where do pipeline failures originate most frequently?", "why_it_matters": "Failure concentration reveals weak execution stages before capacity increases amplify them.", "validation_signal": "Classify failed pipeline runs by stage, owner, cause class, recovery path, and recurrence.", "persona_relevance": [ "VP Engineering", "DevOps Leader" ], "use_cases": [ "diagnose_engineering_capacity", "determine_capacity_absorption_readiness" ], "required_sources": [ "CI/CD", "incident system", "deployment system" ], "minimum_evidence": [ "failure stage", "cause class", "recovery path", "recurrence" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Execution Determinism", "Telemetry Trust" ], "risk_flags": [ "pipeline_failure_concentration", "recovery_gap" ], "recommended_report_type": "Execution Determinism Report", "intent": "diagnostic", "level": "engineering_lead", "tags": [ "pipeline-failure", "root-cause", "ci-cd" ], "related_concepts": [ "failure_origin", "build_stage" ], "doctrine_answer": "The dominant pipeline failure origin is the stage and cause class with the highest recurring failure burden after runs are classified by build, test, security, approval, environment, deployment, and recovery behavior.", "answer_card_template": { "answer_type": "execution_control_answer", "good_answer_pattern": "A strong answer directly answers: \"Where do pipeline failures originate most frequently?\" Validation method: Classify failed pipeline runs by stage, owner, cause class, recovery path, and recurrence. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Execution Determinism, Telemetry Trust.", "common_failure_pattern": "A weak answer gives a generic execution harness diagnosis instead of proving this question with CI/CD, incident system, deployment system. It misses the operating risk: Failure concentration reveals weak execution stages before capacity increases amplify them.", "recommended_report_section": "Execution Determinism Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "execution-006", "domain": "execution_harness", "question": "Who defines and changes execution rules in the SDLC?", "why_it_matters": "Execution rule ownership is required before distributed teams or agents can safely modify workflows.", "validation_signal": "Map SDLC execution rules to owners, approval authority, change process, and audit record.", "persona_relevance": [ "CTO", "CIO", "DevOps Leader" ], "use_cases": [ "evaluate_governance_security_and_ip_risk", "assess_agentic_sdlc_readiness" ], "required_sources": [ "policy documentation", "CI/CD config", "audit logs", "change management records" ], "minimum_evidence": [ "rule owner", "approval authority", "change process", "audit record" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Execution Determinism", "Governance Completeness" ], "risk_flags": [ "rule_ownership_gap", "unaudited_change" ], "recommended_report_type": "Governance, Security, and IP Control Report", "intent": "diagnostic", "level": "cto", "tags": [ "execution-rules", "ownership", "audit" ], "related_concepts": [ "rule_owner", "execution_policy" ], "doctrine_answer": "Execution rules require named owners, authorized approvers, versioned change records, audit history, exception handling, and rollback authority before teams or agents can modify them safely.", "answer_card_template": { "answer_type": "execution_control_answer", "good_answer_pattern": "A strong answer directly answers: \"Who defines and changes execution rules in the SDLC?\" Validation method: Map SDLC execution rules to owners, approval authority, change process, and audit record. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Execution Determinism, Governance Completeness.", "common_failure_pattern": "A weak answer gives a generic execution harness diagnosis instead of proving this question with policy documentation, CI/CD config, audit logs, and related approved sources. It misses the operating risk: Execution rule ownership is required before distributed teams or agents can safely modify workflows.", "recommended_report_section": "Governance, Security, and IP Control Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "execution-007", "domain": "execution_harness", "question": "How are workflow standards propagated across teams?", "why_it_matters": "Scaling requires controlled propagation of standards rather than informal copying.", "validation_signal": "Compare documented standards with templates, automated checks, rollout records, and exception logs.", "persona_relevance": [ "VP Engineering", "Platform Leader", "DevOps Leader" ], "use_cases": [ "determine_capacity_absorption_readiness", "improve_existing_capacity_topology" ], "required_sources": [ "repository templates", "CI/CD", "documentation", "exception logs" ], "minimum_evidence": [ "standard template", "automated check", "rollout record", "exception" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Execution Determinism", "Knowledge Transfer Readiness" ], "risk_flags": [ "standard_drift", "local_execution_variance" ], "recommended_report_type": "Execution Determinism Report", "intent": "diagnostic", "level": "engineering_lead", "tags": [ "standards", "propagation", "workflow" ], "related_concepts": [ "workflow_standard", "policy_enforcement" ], "doctrine_answer": "Workflow standards propagate reliably through versioned templates, automated checks, controlled rollout, conformance telemetry, and explicit exception records rather than documentation and informal copying alone.", "answer_card_template": { "answer_type": "execution_control_answer", "good_answer_pattern": "A strong answer directly answers: \"How are workflow standards propagated across teams?\" Validation method: Compare documented standards with templates, automated checks, rollout records, and exception logs. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Execution Determinism, Knowledge Transfer Readiness.", "common_failure_pattern": "A weak answer gives a generic execution harness diagnosis instead of proving this question with repository templates, CI/CD, documentation, and related approved sources. It misses the operating risk: Scaling requires controlled propagation of standards rather than informal copying.", "recommended_report_section": "Execution Determinism Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "execution-008", "domain": "execution_harness", "question": "What is the cost of pipeline inconsistency?", "why_it_matters": "Inconsistency converts capacity into waiting, rework, release risk, and operational overhead.", "validation_signal": "Compare cycle time, failed runs, manual intervention, rollback events, and rework by pipeline class.", "persona_relevance": [ "CIO", "CTO", "DevOps Leader" ], "use_cases": [ "diagnose_engineering_capacity", "build_distributed_capacity_strategy" ], "required_sources": [ "CI/CD", "deployment system", "work tracker", "incident system" ], "minimum_evidence": [ "cycle time by pipeline class", "failed run rate", "manual intervention", "rollback event" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Execution Determinism", "Cost/Value/Risk Economics" ], "risk_flags": [ "pipeline_inconsistency_cost", "release_risk" ], "recommended_report_type": "Execution Determinism Report", "intent": "diagnostic", "level": "cio", "tags": [ "cost", "pipeline", "inconsistency" ], "related_concepts": [ "pipeline_cost", "release_risk" ], "doctrine_answer": "Pipeline inconsistency costs the engineering system the measured cycle time, failed runs, manual intervention, rework, rollback exposure, and release delay attributable to divergent execution paths.", "answer_card_template": { "answer_type": "execution_control_answer", "good_answer_pattern": "A strong answer directly answers: \"What is the cost of pipeline inconsistency?\" Validation method: Compare cycle time, failed runs, manual intervention, rollback events, and rework by pipeline class. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Execution Determinism, Cost/Value/Risk Economics.", "common_failure_pattern": "A weak answer gives a generic execution harness diagnosis instead of proving this question with CI/CD, deployment system, work tracker, and related approved sources. It misses the operating risk: Inconsistency converts capacity into waiting, rework, release risk, and operational overhead.", "recommended_report_section": "Execution Determinism Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "execution-009", "domain": "execution_harness", "question": "Which execution paths are safe for AI-assisted or external contributors?", "why_it_matters": "Delegation safety depends on deterministic test, review, approval, deployment, and rollback paths.", "validation_signal": "Classify execution paths by test reliability, approval boundary, production impact, auditability, and rollback readiness.", "persona_relevance": [ "CTO", "CIO", "AI Governance Leader", "DevOps Leader" ], "use_cases": [ "assess_agentic_sdlc_readiness", "improve_existing_capacity_topology", "evaluate_governance_security_and_ip_risk" ], "required_sources": [ "CI/CD", "deployment system", "policy documentation", "audit logs" ], "minimum_evidence": [ "test reliability", "approval boundary", "production impact", "rollback readiness" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Execution Determinism", "Agent Delegation Safety", "Governance Completeness" ], "risk_flags": [ "unsafe_execution_path", "agent_blast_radius" ], "recommended_report_type": "Agent Delegation Safety Matrix", "intent": "diagnostic", "level": "cto", "tags": [ "ai", "external-contributors", "execution-path" ], "related_concepts": [ "safe_delegation", "approval_path" ], "doctrine_answer": "An execution path is safe for AI-assisted or external contribution only when permissions are bounded and tests, review, approval, deployment, audit, and rollback controls constrain the path's blast radius.", "answer_card_template": { "answer_type": "execution_control_answer", "good_answer_pattern": "A strong answer directly answers: \"Which execution paths are safe for AI-assisted or external contributors?\" Validation method: Classify execution paths by test reliability, approval boundary, production impact, auditability, and rollback readiness. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Execution Determinism, Agent Delegation Safety, Governance Completeness.", "common_failure_pattern": "A weak answer gives a generic execution harness diagnosis instead of proving this question with CI/CD, deployment system, policy documentation, and related approved sources. It misses the operating risk: Delegation safety depends on deterministic test, review, approval, deployment, and rollback paths.", "recommended_report_section": "Agent Delegation Safety Matrix", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "execution-010", "domain": "execution_harness", "question": "What breaks in execution when delivery volume increases?", "why_it_matters": "Volume exposes weak gates, slow reviews, unstable environments, and fragile deployment paths.", "validation_signal": "Compare failure rates, queue times, environment conflicts, rollback events, and approval latency before and after volume changes.", "persona_relevance": [ "CTO", "VP Engineering", "DevOps Leader" ], "use_cases": [ "determine_capacity_absorption_readiness", "diagnose_engineering_capacity" ], "required_sources": [ "CI/CD", "deployment system", "pull request system", "work tracker" ], "minimum_evidence": [ "volume change", "failure rate", "queue time", "environment conflict" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Execution Determinism", "Capacity Reality" ], "risk_flags": [ "volume_degradation", "execution_saturation" ], "recommended_report_type": "Execution Determinism Report", "intent": "diagnostic", "level": "cto", "tags": [ "volume", "scaling", "execution" ], "related_concepts": [ "delivery_volume", "execution_saturation" ], "doctrine_answer": "When delivery volume rises, the first execution failures appear at gates whose service capacity does not scale, including review, tests, environments, approvals, deployment concurrency, and rollback handling.", "answer_card_template": { "answer_type": "execution_control_answer", "good_answer_pattern": "A strong answer directly answers: \"What breaks in execution when delivery volume increases?\" Validation method: Compare failure rates, queue times, environment conflicts, rollback events, and approval latency before and after volume changes. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Execution Determinism, Capacity Reality.", "common_failure_pattern": "A weak answer gives a generic execution harness diagnosis instead of proving this question with CI/CD, deployment system, pull request system, and related approved sources. It misses the operating risk: Volume exposes weak gates, slow reviews, unstable environments, and fragile deployment paths.", "recommended_report_section": "Execution Determinism Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "telemetry-001", "domain": "decision_grade_telemetry", "question": "Which engineering signals are trusted enough to govern capacity topology decisions?", "why_it_matters": "Topology decisions require evidence that explains delivery behavior, not dashboard activity.", "validation_signal": "Inventory metrics used for decisions and classify each by source reliability, freshness, coverage, and decision history.", "persona_relevance": [ "CTO", "CIO", "VP Engineering" ], "use_cases": [ "build_distributed_capacity_strategy", "diagnose_engineering_capacity" ], "required_sources": [ "work tracker", "CI/CD", "deployment system", "incident system", "observability dashboards" ], "minimum_evidence": [ "metric source", "freshness", "coverage", "decision history" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Telemetry Trust", "Governance Completeness" ], "risk_flags": [ "dashboard_noise", "low_signal_decision" ], "recommended_report_type": "Engineering Capacity OS Diagnostic", "intent": "diagnostic", "level": "cto", "tags": [ "telemetry", "decision-grade", "metrics" ], "related_concepts": [ "telemetry_trust", "decision_signal" ], "doctrine_answer": "A signal is trusted for topology governance only when its source, definition, freshness, coverage, aggregation, known bias, and history of decision use are documented and tied to delivery outcomes.", "answer_card_template": { "answer_type": "telemetry_trust_answer", "good_answer_pattern": "A strong answer directly answers: \"Which engineering signals are trusted enough to govern capacity topology decisions?\" Validation method: Inventory metrics used for decisions and classify each by source reliability, freshness, coverage, and decision history. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Telemetry Trust, Governance Completeness.", "common_failure_pattern": "A weak answer gives a generic decision grade telemetry diagnosis instead of proving this question with work tracker, CI/CD, deployment system, and related approved sources. It misses the operating risk: Topology decisions require evidence that explains delivery behavior, not dashboard activity.", "recommended_report_section": "Engineering Capacity OS Diagnostic", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "telemetry-002", "domain": "decision_grade_telemetry", "question": "Which signals correlate with delivery success rather than activity volume?", "why_it_matters": "Activity metrics can increase while speed, quality, cost, risk, and business value degrade.", "validation_signal": "Compare candidate metrics with delivery outcomes, escaped defects, rework, cycle time, incident impact, and business milestones.", "persona_relevance": [ "CTO", "CIO", "VP Engineering" ], "use_cases": [ "diagnose_engineering_capacity", "build_distributed_capacity_strategy" ], "required_sources": [ "work tracker", "quality system", "incident system", "product milestones", "deployment system" ], "minimum_evidence": [ "metric correlation", "defect signal", "cycle time", "business milestone" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Telemetry Trust", "Cost/Value/Risk Economics" ], "risk_flags": [ "vanity_metric", "activity_bias" ], "recommended_report_type": "Engineering Capacity OS Diagnostic", "intent": "diagnostic", "level": "cto", "tags": [ "metrics", "outcomes", "value" ], "related_concepts": [ "outcome_metric", "activity_metric" ], "doctrine_answer": "Outcome signals are metrics that demonstrate a stable relationship with delivery speed, quality, cost, risk, reliability, or business milestones; activity counts without that relationship are not decision-grade evidence.", "answer_card_template": { "answer_type": "telemetry_trust_answer", "good_answer_pattern": "A strong answer directly answers: \"Which signals correlate with delivery success rather than activity volume?\" Validation method: Compare candidate metrics with delivery outcomes, escaped defects, rework, cycle time, incident impact, and business milestones. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Telemetry Trust, Cost/Value/Risk Economics.", "common_failure_pattern": "A weak answer gives a generic decision grade telemetry diagnosis instead of proving this question with work tracker, quality system, incident system, and related approved sources. It misses the operating risk: Activity metrics can increase while speed, quality, cost, risk, and business value degrade.", "recommended_report_section": "Engineering Capacity OS Diagnostic", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "telemetry-003", "domain": "decision_grade_telemetry", "question": "How real-time is delivery visibility for leaders?", "why_it_matters": "Slow telemetry creates delayed intervention and makes adaptive control unsafe.", "validation_signal": "Measure reporting latency for work state, review queues, CI/CD failures, deployment outcomes, incidents, and agent actions.", "persona_relevance": [ "CTO", "CIO", "Platform Leader" ], "use_cases": [ "diagnose_engineering_capacity", "assess_agentic_sdlc_readiness" ], "required_sources": [ "work tracker", "pull request system", "CI/CD", "deployment system", "incident system", "agent tool logs" ], "minimum_evidence": [ "reporting latency", "refresh interval", "coverage gap", "stale metric" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Telemetry Trust", "Agent Delegation Safety" ], "risk_flags": [ "stale_visibility", "late_intervention" ], "recommended_report_type": "Engineering Capacity OS Diagnostic", "intent": "diagnostic", "level": "cto", "tags": [ "real-time", "visibility", "telemetry" ], "related_concepts": [ "telemetry_freshness", "delivery_visibility" ], "doctrine_answer": "Delivery visibility is real-time only to the degree that reporting latency remains below the intervention window for work queues, reviews, pipeline failures, deployments, incidents, and agent actions.", "answer_card_template": { "answer_type": "telemetry_trust_answer", "good_answer_pattern": "A strong answer directly answers: \"How real-time is delivery visibility for leaders?\" Validation method: Measure reporting latency for work state, review queues, CI/CD failures, deployment outcomes, incidents, and agent actions. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Telemetry Trust, Agent Delegation Safety.", "common_failure_pattern": "A weak answer gives a generic decision grade telemetry diagnosis instead of proving this question with work tracker, pull request system, CI/CD, and related approved sources. It misses the operating risk: Slow telemetry creates delayed intervention and makes adaptive control unsafe.", "recommended_report_section": "Engineering Capacity OS Diagnostic", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "telemetry-004", "domain": "decision_grade_telemetry", "question": "Where are queues invisible to current dashboards?", "why_it_matters": "Hidden queues are a common cause of false capacity conclusions.", "validation_signal": "Compare work tracker states, PR waiting time, approval wait, dependency wait, incident interruption, and blocked comments against dashboard coverage.", "persona_relevance": [ "VP Engineering", "Platform Leader" ], "use_cases": [ "diagnose_engineering_capacity", "determine_capacity_absorption_readiness" ], "required_sources": [ "work tracker", "pull request system", "approval workflow", "incident system" ], "minimum_evidence": [ "hidden wait", "approval wait", "dependency wait", "dashboard coverage" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Telemetry Trust", "Capacity Reality" ], "risk_flags": [ "hidden_queue", "misdiagnosed_capacity" ], "recommended_report_type": "Engineering Capacity OS Diagnostic", "intent": "diagnostic", "level": "engineering_lead", "tags": [ "queues", "dashboard", "visibility" ], "related_concepts": [ "hidden_queue", "queue_time" ], "doctrine_answer": "A queue is invisible when work waits for review, approval, dependencies, decisions, environments, or incident recovery without a distinct timestamped state in the leadership telemetry model.", "answer_card_template": { "answer_type": "telemetry_trust_answer", "good_answer_pattern": "A strong answer directly answers: \"Where are queues invisible to current dashboards?\" Validation method: Compare work tracker states, PR waiting time, approval wait, dependency wait, incident interruption, and blocked comments against dashboard coverage. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Telemetry Trust, Capacity Reality.", "common_failure_pattern": "A weak answer gives a generic decision grade telemetry diagnosis instead of proving this question with work tracker, pull request system, approval workflow, and related approved sources. It misses the operating risk: Hidden queues are a common cause of false capacity conclusions.", "recommended_report_section": "Engineering Capacity OS Diagnostic", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "telemetry-005", "domain": "decision_grade_telemetry", "question": "Which telemetry detects quality degradation after capacity, topology, or AI changes?", "why_it_matters": "A capacity intervention is weak if it increases speed while degrading quality or risk.", "validation_signal": "Track defect escape, failed tests, review correction rate, reverts, incidents, rollback events, and customer-impacting defects after change.", "persona_relevance": [ "CTO", "CIO", "VP Engineering", "AI Governance Leader" ], "use_cases": [ "assess_agentic_sdlc_readiness", "improve_existing_capacity_topology", "evaluate_governance_security_and_ip_risk" ], "required_sources": [ "quality system", "pull request system", "CI/CD", "incident system", "deployment system" ], "minimum_evidence": [ "defect escape", "review correction", "revert", "rollback", "incident" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Telemetry Trust", "Agent Delegation Safety", "Cost/Value/Risk Economics" ], "risk_flags": [ "quality_degradation", "ai_rework" ], "recommended_report_type": "Agent Delegation Safety Matrix", "intent": "diagnostic", "level": "cto", "tags": [ "quality", "degradation", "ai" ], "related_concepts": [ "quality_signal", "degradation_detection" ], "doctrine_answer": "Quality degradation after a capacity or AI change is detected through changes in failed tests, review corrections, reverts, escaped defects, incidents, rollback events, and customer impact against a pre-change baseline.", "answer_card_template": { "answer_type": "telemetry_trust_answer", "good_answer_pattern": "A strong answer directly answers: \"Which telemetry detects quality degradation after capacity, topology, or AI changes?\" Validation method: Track defect escape, failed tests, review correction rate, reverts, incidents, rollback events, and customer-impacting defects after change. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Telemetry Trust, Agent Delegation Safety, Cost/Value/Risk Economics.", "common_failure_pattern": "A weak answer gives a generic decision grade telemetry diagnosis instead of proving this question with quality system, pull request system, CI/CD, and related approved sources. It misses the operating risk: A capacity intervention is weak if it increases speed while degrading quality or risk.", "recommended_report_section": "Agent Delegation Safety Matrix", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "telemetry-006", "domain": "decision_grade_telemetry", "question": "What telemetry compares topology performance without exposing individual employee data?", "why_it_matters": "Leaders need topology evidence while avoiding surveillance and individual performance misuse.", "validation_signal": "Aggregate cycle time, queue time, deployment success, defect rate, incident interruption, and rework by workstream or team-level topology.", "persona_relevance": [ "CIO", "CTO", "VP Engineering" ], "use_cases": [ "build_distributed_capacity_strategy", "evaluate_governance_security_and_ip_risk" ], "required_sources": [ "work tracker", "CI/CD", "deployment system", "incident system" ], "minimum_evidence": [ "aggregate cycle time", "team-level queue time", "topology class", "defect rate" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Telemetry Trust", "Governance Completeness" ], "risk_flags": [ "privacy_violation", "bad_benchmark" ], "recommended_report_type": "Capacity Topology Readiness Report", "intent": "diagnostic", "level": "cio", "tags": [ "privacy", "topology", "benchmark" ], "related_concepts": [ "aggregate_telemetry", "privacy_boundary" ], "doctrine_answer": "Topology performance should be compared with aggregated workstream or team-level flow, quality, deployment, incident, and rework signals, never individual surveillance or employee ranking.", "answer_card_template": { "answer_type": "telemetry_trust_answer", "good_answer_pattern": "A strong answer directly answers: \"What telemetry compares topology performance without exposing individual employee data?\" Validation method: Aggregate cycle time, queue time, deployment success, defect rate, incident interruption, and rework by workstream or team-level topology. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Telemetry Trust, Governance Completeness.", "common_failure_pattern": "A weak answer gives a generic decision grade telemetry diagnosis instead of proving this question with work tracker, CI/CD, deployment system, and related approved sources. It misses the operating risk: Leaders need topology evidence while avoiding surveillance and individual performance misuse.", "recommended_report_section": "Capacity Topology Readiness Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "telemetry-007", "domain": "decision_grade_telemetry", "question": "Which metrics should trigger governance review before scaling automation?", "why_it_matters": "Agentic and adaptive systems need stop conditions before local optimizations harm global performance.", "validation_signal": "Define thresholds for failed validations, reverted changes, policy exceptions, human overrides, incident correlation, and quality drift.", "persona_relevance": [ "CIO", "AI Governance Leader", "CTO" ], "use_cases": [ "assess_agentic_sdlc_readiness", "evaluate_governance_security_and_ip_risk" ], "required_sources": [ "agent tool logs", "CI/CD", "policy exception logs", "incident system", "pull request system" ], "minimum_evidence": [ "validation failure threshold", "human override rate", "policy exception", "quality drift" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Telemetry Trust", "Agent Delegation Safety", "Governance Completeness" ], "risk_flags": [ "automation_without_stop_condition", "recursive_degradation" ], "recommended_report_type": "Governance, Security, and IP Control Report", "intent": "diagnostic", "level": "cio", "tags": [ "governance", "automation", "stop-condition" ], "related_concepts": [ "stop_condition", "governance_trigger" ], "doctrine_answer": "Governance review should trigger when agent or automation telemetry crosses predefined limits for failed validation, reverts, policy exceptions, human overrides, quality drift, incident correlation, or unbounded actions.", "answer_card_template": { "answer_type": "telemetry_trust_answer", "good_answer_pattern": "A strong answer directly answers: \"Which metrics should trigger governance review before scaling automation?\" Validation method: Define thresholds for failed validations, reverted changes, policy exceptions, human overrides, incident correlation, and quality drift. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Telemetry Trust, Agent Delegation Safety, Governance Completeness.", "common_failure_pattern": "A weak answer gives a generic decision grade telemetry diagnosis instead of proving this question with agent tool logs, CI/CD, policy exception logs, and related approved sources. It misses the operating risk: Agentic and adaptive systems need stop conditions before local optimizations harm global performance.", "recommended_report_section": "Governance, Security, and IP Control Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "telemetry-008", "domain": "decision_grade_telemetry", "question": "Which signals are missing but necessary for the next operating decision?", "why_it_matters": "A responsible model should mark unknowns instead of inventing certainty.", "validation_signal": "Compare the decision to required sources, available evidence, confidence tier, and missing instrumentation.", "persona_relevance": [ "CTO", "CIO", "VP Engineering" ], "use_cases": [ "build_distributed_capacity_strategy", "diagnose_engineering_capacity", "evaluate_governance_security_and_ip_risk" ], "required_sources": [ "research question evidence inventory", "metric catalog", "source-system inventory" ], "minimum_evidence": [ "required evidence", "available evidence", "missing instrumentation", "confidence tier" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Telemetry Trust", "Governance Completeness" ], "risk_flags": [ "false_confidence", "missing_instrumentation" ], "recommended_report_type": "Engineering Capacity OS Diagnostic", "intent": "diagnostic", "level": "cto", "tags": [ "missing-data", "confidence", "instrumentation" ], "related_concepts": [ "unknown_evidence", "confidence_tier" ], "doctrine_answer": "A necessary signal is missing when the pending decision requires an evidence class that has no reliable source, insufficient coverage, excessive latency, or an unknown definition; the correct result is an instrumentation gap, not an inferred fact.", "answer_card_template": { "answer_type": "telemetry_trust_answer", "good_answer_pattern": "A strong answer directly answers: \"Which signals are missing but necessary for the next operating decision?\" Validation method: Compare the decision to required sources, available evidence, confidence tier, and missing instrumentation. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Telemetry Trust, Governance Completeness.", "common_failure_pattern": "A weak answer gives a generic decision grade telemetry diagnosis instead of proving this question with research question evidence inventory, metric catalog, source-system inventory. It misses the operating risk: A responsible model should mark unknowns instead of inventing certainty.", "recommended_report_section": "Engineering Capacity OS Diagnostic", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "agent-001", "domain": "governed_agentic_sdlc", "question": "Which agentic workflows reduce onboarding time for distributed contributors?", "why_it_matters": "AI can improve capacity only if it reduces context acquisition cost without increasing rework.", "validation_signal": "Compare onboarding duration, first accepted PR, documentation usage, correction rate, and escalation frequency.", "persona_relevance": [ "CTO", "VP Engineering", "AI Governance Leader" ], "use_cases": [ "assess_agentic_sdlc_readiness", "improve_existing_capacity_topology" ], "required_sources": [ "work tracker", "pull request system", "documentation analytics", "agent tool logs" ], "minimum_evidence": [ "onboarding duration", "first accepted PR", "documentation usage", "correction rate" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Agent Delegation Safety", "Knowledge Transfer Readiness" ], "risk_flags": [ "ai_context_error", "rework_increase" ], "recommended_report_type": "Agent Delegation Safety Matrix", "intent": "diagnostic", "level": "cto", "tags": [ "agents", "onboarding", "distributed" ], "related_concepts": [ "agentic_onboarding", "context_acquisition" ], "doctrine_answer": "Agentic workflows reduce onboarding time when they accelerate safe context retrieval, environment setup, task decomposition, and feedback while first accepted work arrives sooner without higher correction or escalation rates.", "answer_card_template": { "answer_type": "agent_delegation_answer", "good_answer_pattern": "A strong answer directly answers: \"Which agentic workflows reduce onboarding time for distributed contributors?\" Validation method: Compare onboarding duration, first accepted PR, documentation usage, correction rate, and escalation frequency. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Agent Delegation Safety, Knowledge Transfer Readiness.", "common_failure_pattern": "A weak answer gives a generic governed agentic sdlc diagnosis instead of proving this question with work tracker, pull request system, documentation analytics, and related approved sources. It misses the operating risk: AI can improve capacity only if it reduces context acquisition cost without increasing rework.", "recommended_report_section": "Agent Delegation Safety Matrix", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "agent-002", "domain": "governed_agentic_sdlc", "question": "Which AI-generated outputs can distributed teams safely validate?", "why_it_matters": "Validation authority must match skill, context, and risk.", "validation_signal": "Classify outputs by reversibility, test coverage, blast radius, required domain knowledge, and approval path.", "persona_relevance": [ "CTO", "AI Governance Leader", "VP Engineering" ], "use_cases": [ "assess_agentic_sdlc_readiness", "evaluate_governance_security_and_ip_risk" ], "required_sources": [ "agent tool logs", "pull request system", "CI/CD", "approval workflow" ], "minimum_evidence": [ "output type", "reversibility", "test coverage", "approval path" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Agent Delegation Safety", "Governance Completeness" ], "risk_flags": [ "validation_authority_gap", "agent_blast_radius" ], "recommended_report_type": "Agent Delegation Safety Matrix", "intent": "diagnostic", "level": "cto", "tags": [ "ai-output", "validation", "distributed" ], "related_concepts": [ "validation_authority", "blast_radius" ], "doctrine_answer": "AI-generated output is safely validatable when the reviewer has the required domain context and the output is reversible, testable, provenance-marked, bounded in blast radius, and subject to an explicit approval path.", "answer_card_template": { "answer_type": "agent_delegation_answer", "good_answer_pattern": "A strong answer directly answers: \"Which AI-generated outputs can distributed teams safely validate?\" Validation method: Classify outputs by reversibility, test coverage, blast radius, required domain knowledge, and approval path. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Agent Delegation Safety, Governance Completeness.", "common_failure_pattern": "A weak answer gives a generic governed agentic sdlc diagnosis instead of proving this question with agent tool logs, pull request system, CI/CD, and related approved sources. It misses the operating risk: Validation authority must match skill, context, and risk.", "recommended_report_section": "Agent Delegation Safety Matrix", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "agent-003", "domain": "governed_agentic_sdlc", "question": "Which AI tools are allowed for each contributor type?", "why_it_matters": "AI usage creates data exposure, IP, and governance risk.", "validation_signal": "Map contributor type to approved tools, data classes, repository access, prompt policy, and audit requirements.", "persona_relevance": [ "CIO", "AI Governance Leader", "CTO" ], "use_cases": [ "assess_agentic_sdlc_readiness", "evaluate_governance_security_and_ip_risk" ], "required_sources": [ "AI tool policy", "identity provider", "repository permissions", "audit logs" ], "minimum_evidence": [ "approved tool", "data class", "access class", "audit requirement" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Agent Delegation Safety", "Governance Completeness" ], "risk_flags": [ "unauthorized_ai_tool", "data_exposure" ], "recommended_report_type": "Governance, Security, and IP Control Report", "intent": "diagnostic", "level": "cio", "tags": [ "ai-tools", "contributors", "policy" ], "related_concepts": [ "tool_permission", "prompt_policy" ], "doctrine_answer": "Allowed AI tools must be assigned by contributor role, task, data classification, repository boundary, retention policy, permission scope, and audit requirement rather than made universally available.", "answer_card_template": { "answer_type": "agent_delegation_answer", "good_answer_pattern": "A strong answer directly answers: \"Which AI tools are allowed for each contributor type?\" Validation method: Map contributor type to approved tools, data classes, repository access, prompt policy, and audit requirements. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Agent Delegation Safety, Governance Completeness.", "common_failure_pattern": "A weak answer gives a generic governed agentic sdlc diagnosis instead of proving this question with AI tool policy, identity provider, repository permissions, and related approved sources. It misses the operating risk: AI usage creates data exposure, IP, and governance risk.", "recommended_report_section": "Governance, Security, and IP Control Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "agent-004", "domain": "governed_agentic_sdlc", "question": "How are AI-generated PRs reviewed across distributed teams?", "why_it_matters": "AI can increase review burden if review policy is unclear.", "validation_signal": "Track PR provenance, review path, correction rate, test evidence, approval authority, and rollback evidence.", "persona_relevance": [ "CTO", "VP Engineering", "AI Governance Leader" ], "use_cases": [ "assess_agentic_sdlc_readiness", "determine_capacity_absorption_readiness" ], "required_sources": [ "pull request system", "agent tool logs", "CI/CD", "approval workflow" ], "minimum_evidence": [ "PR provenance", "review path", "correction rate", "test evidence" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Agent Delegation Safety", "Execution Determinism" ], "risk_flags": [ "review_burden", "unknown_pr_provenance" ], "recommended_report_type": "Agent Delegation Safety Matrix", "intent": "diagnostic", "level": "cto", "tags": [ "ai-pr", "review", "provenance" ], "related_concepts": [ "pr_provenance", "review_policy" ], "doctrine_answer": "AI-generated pull requests require recorded provenance, automated test evidence, risk-based human review, correction tracking, approval authority, and rollback readiness equivalent to or stronger than human-generated changes.", "answer_card_template": { "answer_type": "agent_delegation_answer", "good_answer_pattern": "A strong answer directly answers: \"How are AI-generated PRs reviewed across distributed teams?\" Validation method: Track PR provenance, review path, correction rate, test evidence, approval authority, and rollback evidence. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Agent Delegation Safety, Execution Determinism.", "common_failure_pattern": "A weak answer gives a generic governed agentic sdlc diagnosis instead of proving this question with pull request system, agent tool logs, CI/CD, and related approved sources. It misses the operating risk: AI can increase review burden if review policy is unclear.", "recommended_report_section": "Agent Delegation Safety Matrix", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "agent-005", "domain": "governed_agentic_sdlc", "question": "What telemetry detects agent-generated rework?", "why_it_matters": "AI productivity claims are weak unless rework is measured.", "validation_signal": "Compare reopened tickets, review corrections, failed tests, reverted commits, escaped defects, and cycle-time impact.", "persona_relevance": [ "CTO", "AI Governance Leader", "VP Engineering" ], "use_cases": [ "assess_agentic_sdlc_readiness", "diagnose_engineering_capacity" ], "required_sources": [ "work tracker", "pull request system", "CI/CD", "quality system", "deployment system" ], "minimum_evidence": [ "reopened ticket", "review correction", "failed test", "reverted commit" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Agent Delegation Safety", "Telemetry Trust" ], "risk_flags": [ "agent_rework", "false_productivity" ], "recommended_report_type": "Agent Delegation Safety Matrix", "intent": "diagnostic", "level": "cto", "tags": [ "agent-rework", "telemetry", "quality" ], "related_concepts": [ "rework_signal", "ai_productivity" ], "doctrine_answer": "Agent-generated rework is detected by linking AI provenance to review corrections, reopened work, failed tests, reverted changes, escaped defects, and downstream cycle-time impact.", "answer_card_template": { "answer_type": "agent_delegation_answer", "good_answer_pattern": "A strong answer directly answers: \"What telemetry detects agent-generated rework?\" Validation method: Compare reopened tickets, review corrections, failed tests, reverted commits, escaped defects, and cycle-time impact. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Agent Delegation Safety, Telemetry Trust.", "common_failure_pattern": "A weak answer gives a generic governed agentic sdlc diagnosis instead of proving this question with work tracker, pull request system, CI/CD, and related approved sources. It misses the operating risk: AI productivity claims are weak unless rework is measured.", "recommended_report_section": "Agent Delegation Safety Matrix", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "agent-006", "domain": "governed_agentic_sdlc", "question": "Which workflows should remain human-gated until trust improves?", "why_it_matters": "Agentic delegation should expand only when validation and governance mature.", "validation_signal": "Identify workflows with high ambiguity, sensitive data, customer impact, production impact, or irreversible consequences.", "persona_relevance": [ "CIO", "CTO", "AI Governance Leader" ], "use_cases": [ "assess_agentic_sdlc_readiness", "evaluate_governance_security_and_ip_risk" ], "required_sources": [ "workflow catalog", "security classification", "incident system", "approval policy" ], "minimum_evidence": [ "ambiguity class", "data sensitivity", "production impact", "approval requirement" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Agent Delegation Safety", "Governance Completeness" ], "risk_flags": [ "unsafe_agent_delegation", "irreversible_action" ], "recommended_report_type": "Agent Delegation Safety Matrix", "intent": "diagnostic", "level": "cio", "tags": [ "human-gated", "agents", "risk" ], "related_concepts": [ "human_gate", "trust_boundary" ], "doctrine_answer": "Workflows with high ambiguity, sensitive data, architecture authority, customer or production impact, weak validation, or irreversible consequences should remain human-gated until evidence demonstrates bounded agent reliability.", "answer_card_template": { "answer_type": "agent_delegation_answer", "good_answer_pattern": "A strong answer directly answers: \"Which workflows should remain human-gated until trust improves?\" Validation method: Identify workflows with high ambiguity, sensitive data, customer impact, production impact, or irreversible consequences. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Agent Delegation Safety, Governance Completeness.", "common_failure_pattern": "A weak answer gives a generic governed agentic sdlc diagnosis instead of proving this question with workflow catalog, security classification, incident system, and related approved sources. It misses the operating risk: Agentic delegation should expand only when validation and governance mature.", "recommended_report_section": "Agent Delegation Safety Matrix", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "adaptive-001", "domain": "governed_adaptive_control_loops", "question": "Can the engineering system recommend workflow changes from telemetry without automatically applying them?", "why_it_matters": "Adaptive control should begin with governed recommendations before self-modifying execution.", "validation_signal": "Verify recommendation source, evidence trail, approval path, rollback path, and post-change measurement.", "persona_relevance": [ "CTO", "CIO", "AI Governance Leader" ], "use_cases": [ "assess_agentic_sdlc_readiness", "evaluate_governance_security_and_ip_risk" ], "required_sources": [ "telemetry platform", "workflow rules", "approval workflow", "audit logs" ], "minimum_evidence": [ "recommendation", "evidence trail", "approval path", "rollback path" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Agent Delegation Safety", "Governance Completeness", "Upside Potential" ], "risk_flags": [ "unapproved_self_modification", "automation_overreach" ], "recommended_report_type": "Governed Adaptive Control Loop Review", "intent": "diagnostic", "level": "cto", "tags": [ "adaptive", "recommendation", "governance" ], "related_concepts": [ "adaptive_control", "governed_recommendation" ], "doctrine_answer": "The system may generate evidence-backed workflow recommendations without applying them; each recommendation must expose its source signals, assumptions, expected effect, approval path, measurement plan, and rollback condition.", "answer_card_template": { "answer_type": "adaptive_control_answer", "good_answer_pattern": "A strong answer directly answers: \"Can the engineering system recommend workflow changes from telemetry without automatically applying them?\" Validation method: Verify recommendation source, evidence trail, approval path, rollback path, and post-change measurement. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Agent Delegation Safety, Governance Completeness, Upside Potential.", "common_failure_pattern": "A weak answer gives a generic governed adaptive control loops diagnosis instead of proving this question with telemetry platform, workflow rules, approval workflow, and related approved sources. It misses the operating risk: Adaptive control should begin with governed recommendations before self-modifying execution.", "recommended_report_section": "Governed Adaptive Control Loop Review", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "adaptive-002", "domain": "governed_adaptive_control_loops", "question": "Which workflow rules can be safely modified under governance?", "why_it_matters": "Not every execution rule should be adaptive; some rules encode security, compliance, or architecture constraints.", "validation_signal": "Classify rules by blast radius, reversibility, policy class, source-system owner, and required approval.", "persona_relevance": [ "CIO", "CTO", "AI Governance Leader", "DevOps Leader" ], "use_cases": [ "assess_agentic_sdlc_readiness", "evaluate_governance_security_and_ip_risk" ], "required_sources": [ "workflow rules", "CI/CD config", "policy documentation", "audit logs" ], "minimum_evidence": [ "rule class", "blast radius", "reversibility", "approval requirement" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Governance Completeness", "Agent Delegation Safety" ], "risk_flags": [ "rule_modification_risk", "policy_bypass" ], "recommended_report_type": "Governed Adaptive Control Loop Review", "intent": "diagnostic", "level": "cio", "tags": [ "workflow-rules", "adaptive", "policy" ], "related_concepts": [ "rule_class", "workflow_modification" ], "doctrine_answer": "Only reversible, observable, low-blast-radius workflow rules may be adaptive by default; security, compliance, architecture, data, and production authority rules require explicit human governance.", "answer_card_template": { "answer_type": "adaptive_control_answer", "good_answer_pattern": "A strong answer directly answers: \"Which workflow rules can be safely modified under governance?\" Validation method: Classify rules by blast radius, reversibility, policy class, source-system owner, and required approval. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Governance Completeness, Agent Delegation Safety.", "common_failure_pattern": "A weak answer gives a generic governed adaptive control loops diagnosis instead of proving this question with workflow rules, CI/CD config, policy documentation, and related approved sources. It misses the operating risk: Not every execution rule should be adaptive; some rules encode security, compliance, or architecture constraints.", "recommended_report_section": "Governed Adaptive Control Loop Review", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "adaptive-003", "domain": "governed_adaptive_control_loops", "question": "How does the system detect when adaptive changes degrade performance?", "why_it_matters": "Learning loops need negative feedback and stop conditions.", "validation_signal": "Monitor quality drift, cycle-time degradation, failed validations, human override rate, incident correlation, and rollback triggers after adaptive changes.", "persona_relevance": [ "CTO", "AI Governance Leader", "Platform Leader" ], "use_cases": [ "assess_agentic_sdlc_readiness", "diagnose_engineering_capacity" ], "required_sources": [ "telemetry platform", "agent tool logs", "CI/CD", "incident system", "rollback records" ], "minimum_evidence": [ "post-change delta", "quality drift", "override rate", "rollback trigger" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Telemetry Trust", "Agent Delegation Safety", "Upside Potential" ], "risk_flags": [ "recursive_degradation", "missing_negative_feedback" ], "recommended_report_type": "Governed Adaptive Control Loop Review", "intent": "diagnostic", "level": "cto", "tags": [ "degradation", "feedback", "adaptive" ], "related_concepts": [ "negative_feedback", "post_change_delta" ], "doctrine_answer": "Adaptive degradation is detected by comparing post-change quality, cycle time, failed validation, override, incident, and rollback signals against baselines and predefined stop conditions.", "answer_card_template": { "answer_type": "adaptive_control_answer", "good_answer_pattern": "A strong answer directly answers: \"How does the system detect when adaptive changes degrade performance?\" Validation method: Monitor quality drift, cycle-time degradation, failed validations, human override rate, incident correlation, and rollback triggers after adaptive changes. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Telemetry Trust, Agent Delegation Safety, Upside Potential.", "common_failure_pattern": "A weak answer gives a generic governed adaptive control loops diagnosis instead of proving this question with telemetry platform, agent tool logs, CI/CD, and related approved sources. It misses the operating risk: Learning loops need negative feedback and stop conditions.", "recommended_report_section": "Governed Adaptive Control Loop Review", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "adaptive-004", "domain": "governed_adaptive_control_loops", "question": "Who can approve, audit, and reverse adaptive changes to the SDLC?", "why_it_matters": "Self-improving systems require explicit authority and reversibility.", "validation_signal": "Map adaptive change classes to approvers, audit logs, rollback authority, exception handling, and stop conditions.", "persona_relevance": [ "CIO", "CTO", "AI Governance Leader" ], "use_cases": [ "assess_agentic_sdlc_readiness", "evaluate_governance_security_and_ip_risk" ], "required_sources": [ "policy documentation", "approval workflow", "audit logs", "rollback records" ], "minimum_evidence": [ "approver", "audit log", "rollback authority", "stop condition" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Governance Completeness", "Agent Delegation Safety" ], "risk_flags": [ "authority_gap", "irreversible_adaptive_change" ], "recommended_report_type": "Governance, Security, and IP Control Report", "intent": "diagnostic", "level": "cio", "tags": [ "approval", "audit", "adaptive" ], "related_concepts": [ "adaptive_authority", "rollback_authority" ], "doctrine_answer": "Every adaptive change class must have named approval authority, immutable audit evidence, an accountable system owner, independent rollback authority, and defined emergency stop conditions.", "answer_card_template": { "answer_type": "adaptive_control_answer", "good_answer_pattern": "A strong answer directly answers: \"Who can approve, audit, and reverse adaptive changes to the SDLC?\" Validation method: Map adaptive change classes to approvers, audit logs, rollback authority, exception handling, and stop conditions. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Governance Completeness, Agent Delegation Safety.", "common_failure_pattern": "A weak answer gives a generic governed adaptive control loops diagnosis instead of proving this question with policy documentation, approval workflow, audit logs, and related approved sources. It misses the operating risk: Self-improving systems require explicit authority and reversibility.", "recommended_report_section": "Governance, Security, and IP Control Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "gov-001", "domain": "governance_security_failure_modes", "question": "Who owns delivery risk for externally or agent-produced work?", "why_it_matters": "Distributed and AI-assisted delivery require clear accountability.", "validation_signal": "Map work ownership to accountable leaders, review authority, approval paths, and incident responsibility.", "persona_relevance": [ "CIO", "CTO", "VP Engineering", "AI Governance Leader" ], "use_cases": [ "evaluate_governance_security_and_ip_risk", "improve_existing_capacity_topology", "assess_agentic_sdlc_readiness" ], "required_sources": [ "ownership map", "approval workflow", "incident system", "contracts or operating agreements" ], "minimum_evidence": [ "accountable owner", "review authority", "approval path", "incident responsibility" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Governance Completeness", "Topology Fit" ], "risk_flags": [ "accountability_gap", "delivery_risk" ], "recommended_report_type": "Governance, Security, and IP Control Report", "intent": "diagnostic", "level": "cio", "tags": [ "accountability", "risk", "external-work" ], "related_concepts": [ "delivery_risk_owner", "accountability" ], "doctrine_answer": "Delivery risk remains owned by the accountable internal leader who authorizes the work and controls acceptance, production approval, and incident response, even when execution is external or agent-assisted.", "answer_card_template": { "answer_type": "governance_failure_answer", "good_answer_pattern": "A strong answer directly answers: \"Who owns delivery risk for externally or agent-produced work?\" Validation method: Map work ownership to accountable leaders, review authority, approval paths, and incident responsibility. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Governance Completeness, Topology Fit.", "common_failure_pattern": "A weak answer gives a generic governance security failure modes diagnosis instead of proving this question with ownership map, approval workflow, incident system, and related approved sources. It misses the operating risk: Distributed and AI-assisted delivery require clear accountability.", "recommended_report_section": "Governance, Security, and IP Control Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "gov-002", "domain": "governance_security_failure_modes", "question": "Which production actions require internal approval?", "why_it_matters": "Production authority must be explicit in distributed systems.", "validation_signal": "Classify deployment, rollback, data migration, configuration, and incident actions by approval requirement.", "persona_relevance": [ "CIO", "CTO", "DevOps Leader" ], "use_cases": [ "evaluate_governance_security_and_ip_risk", "improve_existing_capacity_topology" ], "required_sources": [ "deployment system", "approval workflow", "policy documentation", "audit logs" ], "minimum_evidence": [ "production action", "approval requirement", "approver", "audit record" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Governance Completeness", "Execution Determinism" ], "risk_flags": [ "production_authority_gap", "approval_bypass" ], "recommended_report_type": "Governance, Security, and IP Control Report", "intent": "diagnostic", "level": "cio", "tags": [ "production", "approval", "governance" ], "related_concepts": [ "production_authority", "approval_requirement" ], "doctrine_answer": "Internal approval is required for production actions whose blast radius, data impact, customer effect, irreversibility, or regulatory significance exceeds the organization's predefined authority threshold.", "answer_card_template": { "answer_type": "governance_failure_answer", "good_answer_pattern": "A strong answer directly answers: \"Which production actions require internal approval?\" Validation method: Classify deployment, rollback, data migration, configuration, and incident actions by approval requirement. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Governance Completeness, Execution Determinism.", "common_failure_pattern": "A weak answer gives a generic governance security failure modes diagnosis instead of proving this question with deployment system, approval workflow, policy documentation, and related approved sources. It misses the operating risk: Production authority must be explicit in distributed systems.", "recommended_report_section": "Governance, Security, and IP Control Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "gov-003", "domain": "governance_security_failure_modes", "question": "Which systems are off-limits to external contributors or agents?", "why_it_matters": "Security boundaries must be defined before capacity is distributed.", "validation_signal": "Verify restrictions for sensitive repositories, customer data, secrets, regulated systems, production environments, and privileged tools.", "persona_relevance": [ "CIO", "AI Governance Leader", "CTO" ], "use_cases": [ "evaluate_governance_security_and_ip_risk", "assess_agentic_sdlc_readiness", "improve_existing_capacity_topology" ], "required_sources": [ "security policy", "repository permissions", "identity provider", "data classification" ], "minimum_evidence": [ "restricted system", "access boundary", "data class", "privileged tool" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Governance Completeness", "Agent Delegation Safety" ], "risk_flags": [ "security_boundary_gap", "privileged_access_overreach" ], "recommended_report_type": "Governance, Security, and IP Control Report", "intent": "diagnostic", "level": "cio", "tags": [ "security", "off-limits", "access" ], "related_concepts": [ "security_boundary", "restricted_system" ], "doctrine_answer": "External contributors and agents must be excluded from systems whose data sensitivity, privilege level, regulatory boundary, strategic IP, or production blast radius cannot be contained by least-privilege controls.", "answer_card_template": { "answer_type": "governance_failure_answer", "good_answer_pattern": "A strong answer directly answers: \"Which systems are off-limits to external contributors or agents?\" Validation method: Verify restrictions for sensitive repositories, customer data, secrets, regulated systems, production environments, and privileged tools. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Governance Completeness, Agent Delegation Safety.", "common_failure_pattern": "A weak answer gives a generic governance security failure modes diagnosis instead of proving this question with security policy, repository permissions, identity provider, and related approved sources. It misses the operating risk: Security boundaries must be defined before capacity is distributed.", "recommended_report_section": "Governance, Security, and IP Control Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "gov-004", "domain": "governance_security_failure_modes", "question": "How is IP assignment and contribution provenance verified?", "why_it_matters": "External and AI-assisted work creates IP and ownership questions.", "validation_signal": "Review contracts, contributor agreements, commit provenance, PR metadata, tool usage logs, and approval records.", "persona_relevance": [ "CIO", "CTO", "AI Governance Leader" ], "use_cases": [ "evaluate_governance_security_and_ip_risk", "assess_agentic_sdlc_readiness", "improve_existing_capacity_topology" ], "required_sources": [ "contracts or operating agreements", "repository metadata", "agent tool logs", "approval records" ], "minimum_evidence": [ "IP assignment", "commit provenance", "tool usage log", "approval record" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Governance Completeness", "Agent Delegation Safety" ], "risk_flags": [ "ip_provenance_gap", "unverified_contribution" ], "recommended_report_type": "Governance, Security, and IP Control Report", "intent": "diagnostic", "level": "cio", "tags": [ "ip", "provenance", "contributions" ], "related_concepts": [ "ip_assignment", "contribution_provenance" ], "doctrine_answer": "IP assignment and contribution provenance are verified through enforceable agreements, authenticated contributor identity, commit and PR provenance, AI-tool disclosure, review records, and acceptance history.", "answer_card_template": { "answer_type": "governance_failure_answer", "good_answer_pattern": "A strong answer directly answers: \"How is IP assignment and contribution provenance verified?\" Validation method: Review contracts, contributor agreements, commit provenance, PR metadata, tool usage logs, and approval records. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Governance Completeness, Agent Delegation Safety.", "common_failure_pattern": "A weak answer gives a generic governance security failure modes diagnosis instead of proving this question with contracts or operating agreements, repository metadata, agent tool logs, and related approved sources. It misses the operating risk: External and AI-assisted work creates IP and ownership questions.", "recommended_report_section": "Governance, Security, and IP Control Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "gov-005", "domain": "governance_security_failure_modes", "question": "How are policy exceptions logged and reviewed?", "why_it_matters": "Exceptions reveal where governance is weak or misaligned with reality.", "validation_signal": "Compare exception records, approval paths, recurrence, business justification, and remediation actions.", "persona_relevance": [ "CIO", "CTO", "DevOps Leader" ], "use_cases": [ "evaluate_governance_security_and_ip_risk", "diagnose_engineering_capacity" ], "required_sources": [ "policy exception logs", "approval workflow", "audit logs", "incident system" ], "minimum_evidence": [ "exception record", "approval path", "recurrence", "remediation action" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Governance Completeness", "Telemetry Trust" ], "risk_flags": [ "policy_exception_drift", "governance_lag" ], "recommended_report_type": "Governance, Security, and IP Control Report", "intent": "diagnostic", "level": "cio", "tags": [ "policy-exception", "audit", "governance" ], "related_concepts": [ "policy_exception", "remediation" ], "doctrine_answer": "Policy exceptions require a timestamped request, business justification, accountable approver, bounded duration, affected assets, compensating controls, remediation owner, recurrence review, and closure evidence.", "answer_card_template": { "answer_type": "governance_failure_answer", "good_answer_pattern": "A strong answer directly answers: \"How are policy exceptions logged and reviewed?\" Validation method: Compare exception records, approval paths, recurrence, business justification, and remediation actions. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Governance Completeness, Telemetry Trust.", "common_failure_pattern": "A weak answer gives a generic governance security failure modes diagnosis instead of proving this question with policy exception logs, approval workflow, audit logs, and related approved sources. It misses the operating risk: Exceptions reveal where governance is weak or misaligned with reality.", "recommended_report_section": "Governance, Security, and IP Control Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "gov-006", "domain": "governance_security_failure_modes", "question": "What breaks first when capacity, distribution, or automation increases?", "why_it_matters": "Failure-mode analysis turns scaling plans into testable risk hypotheses.", "validation_signal": "Inspect hidden queues, review bottlenecks, architecture latency, pipeline drift, context loss, agent rework, security access, and governance lag.", "persona_relevance": [ "CTO", "CIO", "VP Engineering", "AI Governance Leader" ], "use_cases": [ "diagnose_engineering_capacity", "determine_capacity_absorption_readiness", "evaluate_governance_security_and_ip_risk" ], "required_sources": [ "work tracker", "pull request system", "CI/CD", "incident system", "audit logs" ], "minimum_evidence": [ "hidden queue", "review bottleneck", "pipeline drift", "governance lag" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Governance Completeness", "Capacity Reality", "Execution Determinism" ], "risk_flags": [ "failure_mode_unknown", "scaling_degradation" ], "recommended_report_type": "Engineering Capacity OS Diagnostic", "intent": "diagnostic", "level": "cto", "tags": [ "failure-mode", "scaling", "risk" ], "related_concepts": [ "failure_mode_register", "scaling_risk" ], "doctrine_answer": "The first scaling failure is the constraint whose demand grows faster than its control capacity; test this across review queues, architecture decisions, knowledge transfer, pipeline consistency, agent rework, access control, and governance latency.", "answer_card_template": { "answer_type": "governance_failure_answer", "good_answer_pattern": "A strong answer directly answers: \"What breaks first when capacity, distribution, or automation increases?\" Validation method: Inspect hidden queues, review bottlenecks, architecture latency, pipeline drift, context loss, agent rework, security access, and governance lag. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Governance Completeness, Capacity Reality, Execution Determinism.", "common_failure_pattern": "A weak answer gives a generic governance security failure modes diagnosis instead of proving this question with work tracker, pull request system, CI/CD, and related approved sources. It misses the operating risk: Failure-mode analysis turns scaling plans into testable risk hypotheses.", "recommended_report_section": "Engineering Capacity OS Diagnostic", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } } ], "cto_question_taxonomy": { "capacity_intelligence": [ { "id": "capacity-001", "domain": "capacity_intelligence", "question": "How much usable engineering capacity exists after cognitive load, review load, interruptions, and role fit are accounted for?", "why_it_matters": "Headcount does not represent usable capacity when the system loses time to queues, incidents, meetings, or poor work fit.", "validation_signal": "Compare committed work, completed work, active WIP, review queue age, incident interruption load, and role-to-work fit over the same window.", "persona_relevance": [ "CTO", "VP Engineering" ], "use_cases": [ "diagnose_engineering_capacity", "determine_capacity_absorption_readiness" ], "required_sources": [ "Jira or Linear", "GitHub or GitLab", "incident system", "calendar metadata if approved and aggregated" ], "minimum_evidence": [ "active WIP", "completed work", "review queue age", "incident interruptions" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Capacity Reality", "Telemetry Trust" ], "risk_flags": [ "hidden_capacity_loss", "review_bottleneck" ], "recommended_report_type": "Engineering Capacity OS Diagnostic", "intent": "diagnostic", "level": "cto", "tags": [ "capacity", "headcount", "cognitive-load" ], "related_concepts": [ "available_capacity", "review_capacity", "role_fit" ], "doctrine_answer": "Usable capacity is committed delivery capacity minus time lost to active WIP, review queues, incidents, interruptions, meetings, and role mismatch over the same measurement window; headcount alone is not capacity.", "answer_card_template": { "answer_type": "capacity_constraint_answer", "good_answer_pattern": "A strong answer directly answers: \"How much usable engineering capacity exists after cognitive load, review load, interruptions, and role fit are accounted for?\" Validation method: Compare committed work, completed work, active WIP, review queue age, incident interruption load, and role-to-work fit over the same window. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Capacity Reality, Telemetry Trust.", "common_failure_pattern": "A weak answer gives a generic capacity intelligence diagnosis instead of proving this question with Jira or Linear, GitHub or GitLab, incident system, and related approved sources. It misses the operating risk: Headcount does not represent usable capacity when the system loses time to queues, incidents, meetings, or poor work fit.", "recommended_report_section": "Engineering Capacity OS Diagnostic", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "capacity-002", "domain": "capacity_intelligence", "question": "Which roles or decision points create the current capacity constraint?", "why_it_matters": "Adding contributors does not help if the bottleneck is architecture review, product decision latency, release approval, or a specialized reviewer.", "validation_signal": "Locate queues by role dependency and compare queue time against reviewer availability, decision age, and approval latency.", "persona_relevance": [ "CTO", "VP Engineering" ], "use_cases": [ "diagnose_engineering_capacity", "determine_capacity_absorption_readiness" ], "required_sources": [ "work tracker", "pull request system", "architecture decision records", "approval workflow" ], "minimum_evidence": [ "queue by role", "approval latency", "reviewer availability", "decision age" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Capacity Reality", "Execution Determinism" ], "risk_flags": [ "decision_latency", "role_bottleneck" ], "recommended_report_type": "Capacity Constraint Map", "intent": "diagnostic", "level": "cto", "tags": [ "constraints", "roles", "decision-latency" ], "related_concepts": [ "bottleneck_role", "decision_authority" ], "doctrine_answer": "The current capacity constraint is the role or decision gate whose queue time and demand exceed its available review or approval capacity, regardless of how many contributors exist upstream.", "answer_card_template": { "answer_type": "capacity_constraint_answer", "good_answer_pattern": "A strong answer directly answers: \"Which roles or decision points create the current capacity constraint?\" Validation method: Locate queues by role dependency and compare queue time against reviewer availability, decision age, and approval latency. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Capacity Reality, Execution Determinism.", "common_failure_pattern": "A weak answer gives a generic capacity intelligence diagnosis instead of proving this question with work tracker, pull request system, architecture decision records, and related approved sources. It misses the operating risk: Adding contributors does not help if the bottleneck is architecture review, product decision latency, release approval, or a specialized reviewer.", "recommended_report_section": "Capacity Constraint Map", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "capacity-003", "domain": "capacity_intelligence", "question": "What percentage of capacity is lost to context switching and fragmented ownership?", "why_it_matters": "Fragmented work creates apparent activity while reducing throughput, quality, and learning.", "validation_signal": "Measure active work items per contributor, handoff count, interrupted work, incident load, and cycle-time variance.", "persona_relevance": [ "VP Engineering", "Platform Leader" ], "use_cases": [ "diagnose_engineering_capacity" ], "required_sources": [ "work tracker", "incident system", "calendar metadata if approved and aggregated" ], "minimum_evidence": [ "active work per contributor", "handoff count", "interruption count", "cycle-time variance" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Capacity Reality", "Upside Potential" ], "risk_flags": [ "context_switching", "ownership_fragmentation" ], "recommended_report_type": "Engineering Capacity OS Diagnostic", "intent": "diagnostic", "level": "engineering_lead", "tags": [ "context-switching", "focus", "ownership" ], "related_concepts": [ "cognitive_load", "work_fragmentation" ], "doctrine_answer": "Context-switching loss is the share of available engineering time consumed by work transitions, interrupted tasks, handoffs, and fragmented ownership rather than completed flow.", "answer_card_template": { "answer_type": "capacity_constraint_answer", "good_answer_pattern": "A strong answer directly answers: \"What percentage of capacity is lost to context switching and fragmented ownership?\" Validation method: Measure active work items per contributor, handoff count, interrupted work, incident load, and cycle-time variance. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Capacity Reality, Upside Potential.", "common_failure_pattern": "A weak answer gives a generic capacity intelligence diagnosis instead of proving this question with work tracker, incident system, calendar metadata if approved and aggregated. It misses the operating risk: Fragmented work creates apparent activity while reducing throughput, quality, and learning.", "recommended_report_section": "Engineering Capacity OS Diagnostic", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "capacity-004", "domain": "capacity_intelligence", "question": "Which work types consume scarce senior review or architecture capacity?", "why_it_matters": "Capacity expansion can overload senior reviewers and turn more contributors into slower delivery.", "validation_signal": "Classify PRs, design reviews, escalations, and rework by work type and senior-review dependency.", "persona_relevance": [ "CTO", "VP Engineering" ], "use_cases": [ "determine_capacity_absorption_readiness", "improve_existing_capacity_topology" ], "required_sources": [ "pull request system", "architecture reviews", "work tracker" ], "minimum_evidence": [ "review dependency", "review queue age", "rework rate", "senior reviewer load" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Capacity Reality", "Topology Fit" ], "risk_flags": [ "senior_review_saturation", "architecture_constraint" ], "recommended_report_type": "Capacity Topology Readiness Report", "intent": "diagnostic", "level": "cto", "tags": [ "review", "architecture", "capacity" ], "related_concepts": [ "review_capacity", "architecture_authority" ], "doctrine_answer": "Work types with high architectural ambiguity, cross-service impact, security exposure, or weak test boundaries consume the most scarce senior review capacity and should be ranked by measured review demand.", "answer_card_template": { "answer_type": "capacity_constraint_answer", "good_answer_pattern": "A strong answer directly answers: \"Which work types consume scarce senior review or architecture capacity?\" Validation method: Classify PRs, design reviews, escalations, and rework by work type and senior-review dependency. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Capacity Reality, Topology Fit.", "common_failure_pattern": "A weak answer gives a generic capacity intelligence diagnosis instead of proving this question with pull request system, architecture reviews, work tracker. It misses the operating risk: Capacity expansion can overload senior reviewers and turn more contributors into slower delivery.", "recommended_report_section": "Capacity Topology Readiness Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "capacity-005", "domain": "capacity_intelligence", "question": "Is the engineering system ready to absorb additional contributors without increasing queue time?", "why_it_matters": "New capacity can create negative throughput if onboarding, review, knowledge, and release systems are not ready.", "validation_signal": "Compare onboarding duration, PR correction rate, review queue age, test reliability, deployment frequency, and incident load before scaling.", "persona_relevance": [ "CTO", "CIO", "VP Engineering" ], "use_cases": [ "determine_capacity_absorption_readiness", "build_distributed_capacity_strategy" ], "required_sources": [ "work tracker", "pull request system", "CI/CD", "deployment system", "incident system" ], "minimum_evidence": [ "onboarding duration", "review queue age", "PR correction rate", "deployment success" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Capacity Reality", "Knowledge Transfer Readiness", "Execution Determinism" ], "risk_flags": [ "unabsorbable_capacity", "queue_growth" ], "recommended_report_type": "Capacity Topology Readiness Report", "intent": "diagnostic", "level": "cto", "tags": [ "absorption", "scaling", "queue-time" ], "related_concepts": [ "capacity_absorption", "onboarding" ], "doctrine_answer": "The system is ready for more contributors only when onboarding, knowledge access, review capacity, test reliability, and release controls can absorb the marginal work without increasing queue age or rework.", "answer_card_template": { "answer_type": "capacity_constraint_answer", "good_answer_pattern": "A strong answer directly answers: \"Is the engineering system ready to absorb additional contributors without increasing queue time?\" Validation method: Compare onboarding duration, PR correction rate, review queue age, test reliability, deployment frequency, and incident load before scaling. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Capacity Reality, Knowledge Transfer Readiness, Execution Determinism.", "common_failure_pattern": "A weak answer gives a generic capacity intelligence diagnosis instead of proving this question with work tracker, pull request system, CI/CD, and related approved sources. It misses the operating risk: New capacity can create negative throughput if onboarding, review, knowledge, and release systems are not ready.", "recommended_report_section": "Capacity Topology Readiness Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "capacity-006", "domain": "capacity_intelligence", "question": "What capacity is blocked by missing decisions rather than missing people?", "why_it_matters": "Many capacity problems are decision-system problems: unclear priority, product ambiguity, architecture approval, or governance delay.", "validation_signal": "Identify blocked work items by blocker class and compare blocked time caused by people availability, technical dependency, policy, or decision latency.", "persona_relevance": [ "CTO", "CIO", "VP Engineering" ], "use_cases": [ "diagnose_engineering_capacity", "evaluate_governance_security_and_ip_risk" ], "required_sources": [ "work tracker", "decision records", "architecture records", "approval workflow" ], "minimum_evidence": [ "blocked reason", "decision wait time", "approval age", "priority changes" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Capacity Reality", "Governance Completeness" ], "risk_flags": [ "decision_latency", "ambiguous_priority" ], "recommended_report_type": "Engineering Capacity OS Diagnostic", "intent": "diagnostic", "level": "cto", "tags": [ "blocked-work", "decisions", "governance" ], "related_concepts": [ "decision_latency", "blocked_capacity" ], "doctrine_answer": "Decision-blocked capacity is the delivery time lost to unresolved priority, product, architecture, policy, or approval decisions; it must be separated from shortages in contributor availability.", "answer_card_template": { "answer_type": "capacity_constraint_answer", "good_answer_pattern": "A strong answer directly answers: \"What capacity is blocked by missing decisions rather than missing people?\" Validation method: Identify blocked work items by blocker class and compare blocked time caused by people availability, technical dependency, policy, or decision latency. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Capacity Reality, Governance Completeness.", "common_failure_pattern": "A weak answer gives a generic capacity intelligence diagnosis instead of proving this question with work tracker, decision records, architecture records, and related approved sources. It misses the operating risk: Many capacity problems are decision-system problems: unclear priority, product ambiguity, architecture approval, or governance delay.", "recommended_report_section": "Engineering Capacity OS Diagnostic", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "capacity-007", "domain": "capacity_intelligence", "question": "Which skills are scarce enough to determine capacity topology decisions?", "why_it_matters": "Topology decisions should follow scarce skills, knowledge concentration, review authority, and risk boundaries rather than location preference.", "validation_signal": "Map workstream demand to skill supply, review capacity, architecture knowledge, and validated contributor readiness.", "persona_relevance": [ "CTO", "VP Engineering" ], "use_cases": [ "build_distributed_capacity_strategy", "improve_existing_capacity_topology" ], "required_sources": [ "work tracker", "skills inventory", "service ownership map", "pull request system" ], "minimum_evidence": [ "skill demand", "skill supply", "review dependency", "ownership concentration" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Capacity Reality", "Topology Fit" ], "risk_flags": [ "scarce_skill_constraint", "knowledge_concentration" ], "recommended_report_type": "Capacity Topology Readiness Report", "intent": "diagnostic", "level": "cto", "tags": [ "skills", "topology", "scarcity" ], "related_concepts": [ "skill_fit", "topology_fit" ], "doctrine_answer": "A skill is topology-determining when demand for that skill, knowledge, or approval authority repeatedly exceeds validated supply and creates a measurable queue or risk boundary.", "answer_card_template": { "answer_type": "capacity_constraint_answer", "good_answer_pattern": "A strong answer directly answers: \"Which skills are scarce enough to determine capacity topology decisions?\" Validation method: Map workstream demand to skill supply, review capacity, architecture knowledge, and validated contributor readiness. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Capacity Reality, Topology Fit.", "common_failure_pattern": "A weak answer gives a generic capacity intelligence diagnosis instead of proving this question with work tracker, skills inventory, service ownership map, and related approved sources. It misses the operating risk: Topology decisions should follow scarce skills, knowledge concentration, review authority, and risk boundaries rather than location preference.", "recommended_report_section": "Capacity Topology Readiness Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "capacity-008", "domain": "capacity_intelligence", "question": "Which capacity constraints should be repaired before any sourcing, hiring, or automation decision is made?", "why_it_matters": "A poor system can absorb hiring, partners, or AI agents and still produce worse delivery behavior.", "validation_signal": "Rank constraints by queue impact, quality impact, risk impact, reversibility, and required controls.", "persona_relevance": [ "CTO", "CIO", "VP Engineering" ], "use_cases": [ "diagnose_engineering_capacity", "determine_capacity_absorption_readiness", "build_distributed_capacity_strategy" ], "required_sources": [ "work tracker", "pull request system", "CI/CD", "incident system", "architecture records" ], "minimum_evidence": [ "queue impact", "quality impact", "risk impact", "control gaps" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Capacity Reality", "Upside Potential", "Governance Completeness" ], "risk_flags": [ "premature_scaling", "automation_amplifies_bottleneck" ], "recommended_report_type": "Engineering Capacity OS Diagnostic", "intent": "diagnostic", "level": "cto", "tags": [ "repair-before-scale", "capacity", "risk" ], "related_concepts": [ "system_bottleneck", "capacity_repair" ], "doctrine_answer": "Repair the constraints with the greatest demonstrated queue, quality, and risk impact before adding people, partners, or agents, especially review bottlenecks, decision latency, missing knowledge, and unreliable execution controls.", "answer_card_template": { "answer_type": "capacity_constraint_answer", "good_answer_pattern": "A strong answer directly answers: \"Which capacity constraints should be repaired before any sourcing, hiring, or automation decision is made?\" Validation method: Rank constraints by queue impact, quality impact, risk impact, reversibility, and required controls. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Capacity Reality, Upside Potential, Governance Completeness.", "common_failure_pattern": "A weak answer gives a generic capacity intelligence diagnosis instead of proving this question with work tracker, pull request system, CI/CD, and related approved sources. It misses the operating risk: A poor system can absorb hiring, partners, or AI agents and still produce worse delivery behavior.", "recommended_report_section": "Engineering Capacity OS Diagnostic", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } } ], "distributed_capacity_topology": [ { "id": "topology-001", "domain": "distributed_capacity_topology", "question": "Which engineering workstreams are safest to distribute beyond the current core team?", "why_it_matters": "Not all work has the same knowledge, security, coordination, or ownership requirements.", "validation_signal": "Compare workstream complexity, dependency count, review requirements, incident risk, and knowledge availability.", "persona_relevance": [ "CTO", "VP Engineering", "CIO" ], "use_cases": [ "build_distributed_capacity_strategy", "improve_existing_capacity_topology" ], "required_sources": [ "work tracker", "service ownership map", "incident system", "architecture documentation" ], "minimum_evidence": [ "workstream complexity", "dependency count", "review requirements", "knowledge availability" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Topology Fit", "Knowledge Transfer Readiness", "Governance Completeness" ], "risk_flags": [ "unsafe_distribution", "knowledge_gap" ], "recommended_report_type": "Capacity Topology Readiness Report", "intent": "diagnostic", "level": "cto", "tags": [ "topology", "distribution", "workstreams" ], "related_concepts": [ "workstream_allocation", "distributed_capacity" ], "doctrine_answer": "The safest workstreams to distribute are low-coupling, explicitly documented, testable, observable, access-bounded, reversible, and supported by sufficient internal review and escalation capacity.", "answer_card_template": { "answer_type": "capacity_topology_answer", "good_answer_pattern": "A strong answer directly answers: \"Which engineering workstreams are safest to distribute beyond the current core team?\" Validation method: Compare workstream complexity, dependency count, review requirements, incident risk, and knowledge availability. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Topology Fit, Knowledge Transfer Readiness, Governance Completeness.", "common_failure_pattern": "A weak answer gives a generic distributed capacity topology diagnosis instead of proving this question with work tracker, service ownership map, incident system, and related approved sources. It misses the operating risk: Not all work has the same knowledge, security, coordination, or ownership requirements.", "recommended_report_section": "Capacity Topology Readiness Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "topology-002", "domain": "distributed_capacity_topology", "question": "Which workstreams should remain internally owned?", "why_it_matters": "Some work requires direct architectural, product, security, or customer-context control.", "validation_signal": "Identify work tied to strategic IP, high-risk systems, sensitive data, architecture authority, or irreversible production impact.", "persona_relevance": [ "CTO", "CIO" ], "use_cases": [ "build_distributed_capacity_strategy", "evaluate_governance_security_and_ip_risk" ], "required_sources": [ "architecture records", "security classification", "service ownership map", "incident system" ], "minimum_evidence": [ "IP sensitivity", "production impact", "data sensitivity", "architecture authority" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Topology Fit", "Governance Completeness" ], "risk_flags": [ "ip_exposure", "loss_of_architecture_control" ], "recommended_report_type": "Governance, Security, and IP Control Report", "intent": "diagnostic", "level": "cto", "tags": [ "internal-ownership", "risk", "security" ], "related_concepts": [ "internal_control", "ownership_boundary" ], "doctrine_answer": "Work should remain internally owned when it controls strategic architecture, sensitive data, security authority, customer context, regulated decisions, critical IP, or irreversible production impact.", "answer_card_template": { "answer_type": "capacity_topology_answer", "good_answer_pattern": "A strong answer directly answers: \"Which workstreams should remain internally owned?\" Validation method: Identify work tied to strategic IP, high-risk systems, sensitive data, architecture authority, or irreversible production impact. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Topology Fit, Governance Completeness.", "common_failure_pattern": "A weak answer gives a generic distributed capacity topology diagnosis instead of proving this question with architecture records, security classification, service ownership map, and related approved sources. It misses the operating risk: Some work requires direct architectural, product, security, or customer-context control.", "recommended_report_section": "Governance, Security, and IP Control Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "topology-003", "domain": "distributed_capacity_topology", "question": "Which capacity topology best matches each workstream?", "why_it_matters": "Internal hiring, external partners, nearshore, offshore, platform investment, and AI agents solve different constraints.", "validation_signal": "Map workstreams to skill fit, ownership requirements, time-zone needs, governance constraints, and performance evidence.", "persona_relevance": [ "CTO", "CIO", "VP Engineering" ], "use_cases": [ "build_distributed_capacity_strategy", "improve_existing_capacity_topology" ], "required_sources": [ "work tracker", "skills inventory", "service ownership map", "security policy", "delivery telemetry" ], "minimum_evidence": [ "skill fit", "ownership requirements", "timezone needs", "governance constraints" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Topology Fit", "Capacity Reality", "Governance Completeness" ], "risk_flags": [ "topology_mismatch", "coordination_cost" ], "recommended_report_type": "Capacity Topology Readiness Report", "intent": "diagnostic", "level": "cto", "tags": [ "topology-fit", "allocation", "strategy" ], "related_concepts": [ "capacity_topology", "sourcing_topology" ], "doctrine_answer": "The correct topology is selected per workstream by matching skill scarcity, ownership depth, coordination latency, security boundary, review capacity, execution determinism, and telemetry coverage to the available operating model.", "answer_card_template": { "answer_type": "capacity_topology_answer", "good_answer_pattern": "A strong answer directly answers: \"Which capacity topology best matches each workstream?\" Validation method: Map workstreams to skill fit, ownership requirements, time-zone needs, governance constraints, and performance evidence. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Topology Fit, Capacity Reality, Governance Completeness.", "common_failure_pattern": "A weak answer gives a generic distributed capacity topology diagnosis instead of proving this question with work tracker, skills inventory, service ownership map, and related approved sources. It misses the operating risk: Internal hiring, external partners, nearshore, offshore, platform investment, and AI agents solve different constraints.", "recommended_report_section": "Capacity Topology Readiness Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "topology-004", "domain": "distributed_capacity_topology", "question": "Where does time-zone overlap materially affect cycle time?", "why_it_matters": "Distributed capacity fails when decision latency exceeds the work's coordination tolerance.", "validation_signal": "Compare blocked time, handoff delay, review latency, meeting dependency, and incident response requirements across work classes.", "persona_relevance": [ "CTO", "VP Engineering", "Platform Leader" ], "use_cases": [ "build_distributed_capacity_strategy", "improve_existing_capacity_topology", "diagnose_delivery_latency" ], "required_sources": [ "Jira or Linear", "GitHub or GitLab", "calendar metadata if approved and aggregated", "incident system" ], "minimum_evidence": [ "blocked time", "handoff delay", "review latency", "incident response requirements" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Topology Fit", "Telemetry Trust", "Governance Completeness" ], "risk_flags": [ "decision_latency", "handoff_delay", "incident_response_risk" ], "recommended_report_type": "Capacity Topology Readiness Report", "intent": "diagnostic", "level": "cto", "tags": [ "timezone", "cycle-time", "distributed" ], "related_concepts": [ "coordination_tolerance", "handoff_delay" ], "doctrine_answer": "Time-zone overlap materially affects cycle time when work requires same-window architecture decisions, rapid review, coordinated releases, customer response, or incident control; asynchronous work with explicit interfaces is less sensitive.", "answer_card_template": { "answer_type": "capacity_topology_answer", "good_answer_pattern": "A strong answer directly answers: \"Where does time-zone overlap materially affect cycle time?\" Validation method: Compare blocked time, handoff delay, review latency, meeting dependency, and incident response requirements across work classes. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Topology Fit, Telemetry Trust, Governance Completeness.", "common_failure_pattern": "A weak answer gives a generic distributed capacity topology diagnosis instead of proving this question with Jira or Linear, GitHub or GitLab, calendar metadata if approved and aggregated, and related approved sources. It misses the operating risk: Distributed capacity fails when decision latency exceeds the work's coordination tolerance.", "recommended_report_section": "Capacity Topology Readiness Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "topology-005", "domain": "distributed_capacity_topology", "question": "What review capacity must exist before adding distributed contributors?", "why_it_matters": "Additional contributors can increase bottlenecks if review and architecture authority do not scale.", "validation_signal": "Compare PR volume, review queue age, reviewer availability, correction rate, and approval latency before and after capacity changes.", "persona_relevance": [ "CTO", "VP Engineering" ], "use_cases": [ "determine_capacity_absorption_readiness", "improve_existing_capacity_topology" ], "required_sources": [ "pull request system", "work tracker", "architecture reviews" ], "minimum_evidence": [ "PR volume", "review queue age", "reviewer availability", "correction rate" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Capacity Reality", "Topology Fit", "Execution Determinism" ], "risk_flags": [ "review_saturation", "correction_load" ], "recommended_report_type": "Capacity Topology Readiness Report", "intent": "diagnostic", "level": "cto", "tags": [ "review-capacity", "contributors", "scaling" ], "related_concepts": [ "review_capacity", "distributed_contributors" ], "doctrine_answer": "Distributed contributors should be added only after reviewer availability and architecture authority can meet a defined review service level without increasing correction rate, approval latency, or queue age.", "answer_card_template": { "answer_type": "capacity_topology_answer", "good_answer_pattern": "A strong answer directly answers: \"What review capacity must exist before adding distributed contributors?\" Validation method: Compare PR volume, review queue age, reviewer availability, correction rate, and approval latency before and after capacity changes. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Capacity Reality, Topology Fit, Execution Determinism.", "common_failure_pattern": "A weak answer gives a generic distributed capacity topology diagnosis instead of proving this question with pull request system, work tracker, architecture reviews. It misses the operating risk: Additional contributors can increase bottlenecks if review and architecture authority do not scale.", "recommended_report_section": "Capacity Topology Readiness Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "topology-006", "domain": "distributed_capacity_topology", "question": "Which systems or services are ready for external or distributed ownership?", "why_it_matters": "Ownership requires knowledge, test coverage, runbooks, telemetry, and clear escalation paths.", "validation_signal": "Score each service by documentation quality, incident history, test reliability, deployment reproducibility, and ownership clarity.", "persona_relevance": [ "CTO", "CIO", "VP Engineering", "Platform Leader" ], "use_cases": [ "improve_existing_capacity_topology", "evaluate_governance_security_and_ip_risk" ], "required_sources": [ "service catalog", "runbooks", "CI/CD", "deployment system", "incident system" ], "minimum_evidence": [ "documentation quality", "test reliability", "deployment reproducibility", "ownership clarity" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Topology Fit", "Knowledge Transfer Readiness", "Execution Determinism" ], "risk_flags": [ "ownership_ambiguity", "service_transfer_risk" ], "recommended_report_type": "Knowledge and Architecture Memory Report", "intent": "diagnostic", "level": "cto", "tags": [ "ownership", "services", "distributed" ], "related_concepts": [ "service_ownership", "external_ownership" ], "doctrine_answer": "A service is ready for distributed ownership when ownership is explicit and current documentation, tests, deployment controls, telemetry, runbooks, escalation paths, and rollback procedures make operation reproducible.", "answer_card_template": { "answer_type": "capacity_topology_answer", "good_answer_pattern": "A strong answer directly answers: \"Which systems or services are ready for external or distributed ownership?\" Validation method: Score each service by documentation quality, incident history, test reliability, deployment reproducibility, and ownership clarity. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Topology Fit, Knowledge Transfer Readiness, Execution Determinism.", "common_failure_pattern": "A weak answer gives a generic distributed capacity topology diagnosis instead of proving this question with service catalog, runbooks, CI/CD, and related approved sources. It misses the operating risk: Ownership requires knowledge, test coverage, runbooks, telemetry, and clear escalation paths.", "recommended_report_section": "Knowledge and Architecture Memory Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "topology-007", "domain": "distributed_capacity_topology", "question": "What access should each contributor type have?", "why_it_matters": "Capacity topology creates security and IP exposure if access is not role- and risk-based.", "validation_signal": "Map contributor types to repository, environment, data, secrets, deployment, and production permissions.", "persona_relevance": [ "CIO", "CTO", "AI Governance Leader" ], "use_cases": [ "evaluate_governance_security_and_ip_risk", "improve_existing_capacity_topology" ], "required_sources": [ "identity provider", "repository permissions", "deployment permissions", "security policy" ], "minimum_evidence": [ "access class", "repository scope", "environment permission", "production authority" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Governance Completeness", "Topology Fit" ], "risk_flags": [ "access_overreach", "ip_exposure", "production_risk" ], "recommended_report_type": "Governance, Security, and IP Control Report", "intent": "diagnostic", "level": "cio", "tags": [ "access", "permissions", "security" ], "related_concepts": [ "access_boundary", "contributor_type" ], "doctrine_answer": "Each contributor type should receive the least repository, environment, data, secret, deployment, and production access required for its approved work, with time bounds, auditability, and revocation.", "answer_card_template": { "answer_type": "capacity_topology_answer", "good_answer_pattern": "A strong answer directly answers: \"What access should each contributor type have?\" Validation method: Map contributor types to repository, environment, data, secrets, deployment, and production permissions. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Governance Completeness, Topology Fit.", "common_failure_pattern": "A weak answer gives a generic distributed capacity topology diagnosis instead of proving this question with identity provider, repository permissions, deployment permissions, and related approved sources. It misses the operating risk: Capacity topology creates security and IP exposure if access is not role- and risk-based.", "recommended_report_section": "Governance, Security, and IP Control Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "topology-008", "domain": "distributed_capacity_topology", "question": "What is the ramp curve from onboarding to independent contribution?", "why_it_matters": "Capacity is not real until contributors can produce safely without excessive supervision.", "validation_signal": "Measure time to first accepted PR, time to independent task completion, review correction rate, and escalation frequency.", "persona_relevance": [ "VP Engineering", "CTO" ], "use_cases": [ "determine_capacity_absorption_readiness", "improve_existing_capacity_topology" ], "required_sources": [ "work tracker", "pull request system", "onboarding records", "escalation logs" ], "minimum_evidence": [ "time to first accepted PR", "independent task completion", "correction rate", "escalation frequency" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Knowledge Transfer Readiness", "Capacity Reality" ], "risk_flags": [ "slow_ramp", "supervision_overhead" ], "recommended_report_type": "Knowledge and Architecture Memory Report", "intent": "diagnostic", "level": "engineering_lead", "tags": [ "onboarding", "ramp", "independence" ], "related_concepts": [ "ramp_curve", "independent_contribution" ], "doctrine_answer": "The ramp curve is the measured progression from access and context acquisition to first accepted change, independent task completion, production-safe contribution, and ownership with declining correction and escalation rates.", "answer_card_template": { "answer_type": "capacity_topology_answer", "good_answer_pattern": "A strong answer directly answers: \"What is the ramp curve from onboarding to independent contribution?\" Validation method: Measure time to first accepted PR, time to independent task completion, review correction rate, and escalation frequency. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Knowledge Transfer Readiness, Capacity Reality.", "common_failure_pattern": "A weak answer gives a generic distributed capacity topology diagnosis instead of proving this question with work tracker, pull request system, onboarding records, and related approved sources. It misses the operating risk: Capacity is not real until contributors can produce safely without excessive supervision.", "recommended_report_section": "Knowledge and Architecture Memory Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "topology-009", "domain": "distributed_capacity_topology", "question": "Which communication rituals reduce decision latency?", "why_it_matters": "Distributed systems need explicit coordination mechanisms.", "validation_signal": "Compare blocked states, decision wait time, rework, handoff delay, and meeting load before and after ritual changes.", "persona_relevance": [ "VP Engineering", "Platform Leader" ], "use_cases": [ "diagnose_delivery_latency", "improve_existing_capacity_topology" ], "required_sources": [ "work tracker", "decision records", "calendar metadata if approved and aggregated", "pull request system" ], "minimum_evidence": [ "blocked states", "decision wait time", "handoff delay", "meeting load" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Topology Fit", "Telemetry Trust" ], "risk_flags": [ "coordination_overhead", "meeting_load" ], "recommended_report_type": "Capacity Topology Readiness Report", "intent": "diagnostic", "level": "engineering_lead", "tags": [ "rituals", "coordination", "latency" ], "related_concepts": [ "decision_latency", "operating_rituals" ], "doctrine_answer": "Useful communication rituals reduce decision latency by making ownership, decision records, handoffs, escalation windows, and unresolved blockers explicit without adding more meeting load than the delay they remove.", "answer_card_template": { "answer_type": "capacity_topology_answer", "good_answer_pattern": "A strong answer directly answers: \"Which communication rituals reduce decision latency?\" Validation method: Compare blocked states, decision wait time, rework, handoff delay, and meeting load before and after ritual changes. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Topology Fit, Telemetry Trust.", "common_failure_pattern": "A weak answer gives a generic distributed capacity topology diagnosis instead of proving this question with work tracker, decision records, calendar metadata if approved and aggregated, and related approved sources. It misses the operating risk: Distributed systems need explicit coordination mechanisms.", "recommended_report_section": "Capacity Topology Readiness Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "topology-010", "domain": "distributed_capacity_topology", "question": "What is the exit path if a capacity topology underperforms?", "why_it_matters": "Governance requires reversibility, not only rollout plans.", "validation_signal": "Verify ownership transfer, documentation continuity, access removal, IP control, work reassignment, and service continuity plans.", "persona_relevance": [ "CIO", "CTO" ], "use_cases": [ "evaluate_governance_security_and_ip_risk", "build_distributed_capacity_strategy" ], "required_sources": [ "contracts or operating agreements", "access policy", "service ownership map", "documentation inventory" ], "minimum_evidence": [ "exit plan", "access removal", "ownership transfer", "service continuity" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Governance Completeness", "Topology Fit" ], "risk_flags": [ "irreversible_topology", "continuity_risk" ], "recommended_report_type": "Governance, Security, and IP Control Report", "intent": "diagnostic", "level": "cio", "tags": [ "exit-plan", "governance", "reversibility" ], "related_concepts": [ "exit_readiness", "reversibility" ], "doctrine_answer": "A governed exit path preserves service continuity through documented ownership transfer, knowledge capture, access revocation, IP confirmation, work reassignment, and rollback or replacement triggers defined before rollout.", "answer_card_template": { "answer_type": "capacity_topology_answer", "good_answer_pattern": "A strong answer directly answers: \"What is the exit path if a capacity topology underperforms?\" Validation method: Verify ownership transfer, documentation continuity, access removal, IP control, work reassignment, and service continuity plans. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Governance Completeness, Topology Fit.", "common_failure_pattern": "A weak answer gives a generic distributed capacity topology diagnosis instead of proving this question with contracts or operating agreements, access policy, service ownership map, and related approved sources. It misses the operating risk: Governance requires reversibility, not only rollout plans.", "recommended_report_section": "Governance, Security, and IP Control Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } } ], "knowledge_architecture_memory": [ { "id": "knowledge-001", "domain": "knowledge_architecture_memory", "question": "Which parts of the engineering system depend on tribal knowledge?", "why_it_matters": "Tribal knowledge limits distributed execution and safe AI assistance.", "validation_signal": "Identify repeated escalations, undocumented decisions, onboarding blockers, and work items requiring specific individuals.", "persona_relevance": [ "CTO", "VP Engineering", "Platform Leader" ], "use_cases": [ "improve_existing_capacity_topology", "assess_agentic_sdlc_readiness", "determine_capacity_absorption_readiness" ], "required_sources": [ "work tracker", "service ownership map", "documentation inventory", "incident system" ], "minimum_evidence": [ "repeated escalation", "undocumented decision", "onboarding blocker", "individual dependency" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Knowledge Transfer Readiness", "Topology Fit" ], "risk_flags": [ "tribal_knowledge", "single_point_of_context" ], "recommended_report_type": "Knowledge and Architecture Memory Report", "intent": "diagnostic", "level": "cto", "tags": [ "knowledge", "tribal-knowledge", "architecture" ], "related_concepts": [ "explicit_knowledge", "knowledge_dependency" ], "doctrine_answer": "Tribal-knowledge dependencies are system areas where delivery, review, deployment, or incident response repeatedly requires specific individuals because the necessary decisions, constraints, or procedures are not durable artifacts.", "answer_card_template": { "answer_type": "knowledge_memory_answer", "good_answer_pattern": "A strong answer directly answers: \"Which parts of the engineering system depend on tribal knowledge?\" Validation method: Identify repeated escalations, undocumented decisions, onboarding blockers, and work items requiring specific individuals. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Knowledge Transfer Readiness, Topology Fit.", "common_failure_pattern": "A weak answer gives a generic knowledge architecture memory diagnosis instead of proving this question with work tracker, service ownership map, documentation inventory, and related approved sources. It misses the operating risk: Tribal knowledge limits distributed execution and safe AI assistance.", "recommended_report_section": "Knowledge and Architecture Memory Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "knowledge-002", "domain": "knowledge_architecture_memory", "question": "How current are architecture decision records?", "why_it_matters": "Distributed contributors and agents need explicit architectural intent.", "validation_signal": "Compare architecture records against current services, dependencies, incidents, and recent implementation choices.", "persona_relevance": [ "CTO", "Platform Leader" ], "use_cases": [ "improve_existing_capacity_topology", "assess_agentic_sdlc_readiness" ], "required_sources": [ "architecture decision records", "service catalog", "repository history", "incident reviews" ], "minimum_evidence": [ "ADR freshness", "service dependency match", "recent decision coverage", "incident linkage" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Knowledge Transfer Readiness", "Governance Completeness" ], "risk_flags": [ "architecture_drift", "stale_decision_memory" ], "recommended_report_type": "Knowledge and Architecture Memory Report", "intent": "diagnostic", "level": "cto", "tags": [ "adr", "architecture", "documentation" ], "related_concepts": [ "architecture_memory", "decision_record" ], "doctrine_answer": "Architecture decision records are current only when they still match deployed services, dependencies, constraints, ownership, and recent implementation and incident evidence; document age alone does not establish validity.", "answer_card_template": { "answer_type": "knowledge_memory_answer", "good_answer_pattern": "A strong answer directly answers: \"How current are architecture decision records?\" Validation method: Compare architecture records against current services, dependencies, incidents, and recent implementation choices. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Knowledge Transfer Readiness, Governance Completeness.", "common_failure_pattern": "A weak answer gives a generic knowledge architecture memory diagnosis instead of proving this question with architecture decision records, service catalog, repository history, and related approved sources. It misses the operating risk: Distributed contributors and agents need explicit architectural intent.", "recommended_report_section": "Knowledge and Architecture Memory Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "knowledge-003", "domain": "knowledge_architecture_memory", "question": "Which services have clear ownership maps?", "why_it_matters": "Ownership ambiguity creates delays, rework, and incident risk.", "validation_signal": "Verify each service has named owners, escalation paths, review authorities, and support expectations.", "persona_relevance": [ "CTO", "VP Engineering", "Platform Leader" ], "use_cases": [ "improve_existing_capacity_topology", "diagnose_engineering_capacity" ], "required_sources": [ "service catalog", "ownership map", "incident system", "pull request system" ], "minimum_evidence": [ "named owner", "escalation path", "review authority", "support expectation" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Knowledge Transfer Readiness", "Governance Completeness" ], "risk_flags": [ "ownership_ambiguity", "incident_delay" ], "recommended_report_type": "Knowledge and Architecture Memory Report", "intent": "diagnostic", "level": "cto", "tags": [ "ownership", "service-map", "runbooks" ], "related_concepts": [ "service_ownership", "escalation_path" ], "doctrine_answer": "A clear service ownership map names the accountable owner, review authority, operational responder, escalation path, and support expectation for every production service and critical dependency.", "answer_card_template": { "answer_type": "knowledge_memory_answer", "good_answer_pattern": "A strong answer directly answers: \"Which services have clear ownership maps?\" Validation method: Verify each service has named owners, escalation paths, review authorities, and support expectations. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Knowledge Transfer Readiness, Governance Completeness.", "common_failure_pattern": "A weak answer gives a generic knowledge architecture memory diagnosis instead of proving this question with service catalog, ownership map, incident system, and related approved sources. It misses the operating risk: Ownership ambiguity creates delays, rework, and incident risk.", "recommended_report_section": "Knowledge and Architecture Memory Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "knowledge-004", "domain": "knowledge_architecture_memory", "question": "What knowledge must a contributor have before production-impacting work?", "why_it_matters": "Unsafe delegation often starts with insufficient context.", "validation_signal": "Define required service knowledge, system constraints, tests, deployment process, incident history, and approval boundaries.", "persona_relevance": [ "CTO", "CIO", "VP Engineering" ], "use_cases": [ "improve_existing_capacity_topology", "evaluate_governance_security_and_ip_risk" ], "required_sources": [ "runbooks", "deployment procedures", "test strategy", "incident reviews", "approval policy" ], "minimum_evidence": [ "required knowledge checklist", "deployment process", "incident history", "approval boundary" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Knowledge Transfer Readiness", "Governance Completeness" ], "risk_flags": [ "unsafe_delegation", "production_impact" ], "recommended_report_type": "Knowledge and Architecture Memory Report", "intent": "diagnostic", "level": "cto", "tags": [ "production", "delegation", "knowledge" ], "related_concepts": [ "production_readiness", "approval_boundary" ], "doctrine_answer": "Before production-impacting work, a contributor needs verified knowledge of service behavior, architecture constraints, data sensitivity, tests, deployment and rollback procedures, incident history, and approval boundaries.", "answer_card_template": { "answer_type": "knowledge_memory_answer", "good_answer_pattern": "A strong answer directly answers: \"What knowledge must a contributor have before production-impacting work?\" Validation method: Define required service knowledge, system constraints, tests, deployment process, incident history, and approval boundaries. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Knowledge Transfer Readiness, Governance Completeness.", "common_failure_pattern": "A weak answer gives a generic knowledge architecture memory diagnosis instead of proving this question with runbooks, deployment procedures, test strategy, and related approved sources. It misses the operating risk: Unsafe delegation often starts with insufficient context.", "recommended_report_section": "Knowledge and Architecture Memory Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "knowledge-005", "domain": "knowledge_architecture_memory", "question": "Which knowledge sources are safe for AI retrieval?", "why_it_matters": "Agentic workflows need context without exposing secrets, customer data, or sensitive records.", "validation_signal": "Classify documentation, tickets, code references, runbooks, logs, and incidents by sensitivity and retrieval permission.", "persona_relevance": [ "CIO", "AI Governance Leader", "Platform Leader" ], "use_cases": [ "assess_agentic_sdlc_readiness", "evaluate_governance_security_and_ip_risk" ], "required_sources": [ "documentation system", "security classification", "AI tool policy", "identity provider" ], "minimum_evidence": [ "sensitivity class", "retrieval permission", "redaction rule", "audit requirement" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Agent Delegation Safety", "Governance Completeness" ], "risk_flags": [ "data_exposure", "unsafe_ai_retrieval" ], "recommended_report_type": "Agent Delegation Safety Matrix", "intent": "diagnostic", "level": "cio", "tags": [ "ai-retrieval", "privacy", "knowledge" ], "related_concepts": [ "retrieval_boundary", "privacy_class" ], "doctrine_answer": "AI retrieval should be limited to approved, access-controlled knowledge whose sensitivity is classified and whose content excludes secrets, customer records, privileged logs, and other data outside the agent's task boundary.", "answer_card_template": { "answer_type": "knowledge_memory_answer", "good_answer_pattern": "A strong answer directly answers: \"Which knowledge sources are safe for AI retrieval?\" Validation method: Classify documentation, tickets, code references, runbooks, logs, and incidents by sensitivity and retrieval permission. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Agent Delegation Safety, Governance Completeness.", "common_failure_pattern": "A weak answer gives a generic knowledge architecture memory diagnosis instead of proving this question with documentation system, security classification, AI tool policy, and related approved sources. It misses the operating risk: Agentic workflows need context without exposing secrets, customer data, or sensitive records.", "recommended_report_section": "Agent Delegation Safety Matrix", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "knowledge-006", "domain": "knowledge_architecture_memory", "question": "Where does documentation drift create delivery risk?", "why_it_matters": "Outdated documentation causes incorrect decisions by humans and agents.", "validation_signal": "Compare documented procedures against actual deployment paths, incident response steps, code ownership, and pipeline behavior.", "persona_relevance": [ "VP Engineering", "Platform Leader", "AI Governance Leader" ], "use_cases": [ "diagnose_engineering_capacity", "assess_agentic_sdlc_readiness" ], "required_sources": [ "documentation system", "CI/CD", "deployment system", "incident system" ], "minimum_evidence": [ "documented procedure", "actual procedure", "drift instance", "risk impact" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Knowledge Transfer Readiness", "Execution Determinism" ], "risk_flags": [ "documentation_drift", "agent_error" ], "recommended_report_type": "Knowledge and Architecture Memory Report", "intent": "diagnostic", "level": "engineering_lead", "tags": [ "documentation-drift", "risk", "agents" ], "related_concepts": [ "doc_freshness", "procedure_drift" ], "doctrine_answer": "Documentation drift creates delivery risk wherever documented ownership, deployment, recovery, architecture, or policy no longer matches observed system behavior and can cause a human or agent to take an invalid action.", "answer_card_template": { "answer_type": "knowledge_memory_answer", "good_answer_pattern": "A strong answer directly answers: \"Where does documentation drift create delivery risk?\" Validation method: Compare documented procedures against actual deployment paths, incident response steps, code ownership, and pipeline behavior. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Knowledge Transfer Readiness, Execution Determinism.", "common_failure_pattern": "A weak answer gives a generic knowledge architecture memory diagnosis instead of proving this question with documentation system, CI/CD, deployment system, and related approved sources. It misses the operating risk: Outdated documentation causes incorrect decisions by humans and agents.", "recommended_report_section": "Knowledge and Architecture Memory Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "knowledge-007", "domain": "knowledge_architecture_memory", "question": "How are incidents converted into durable system memory?", "why_it_matters": "Learning requires failures to update rules, tests, runbooks, and agent instructions.", "validation_signal": "Verify incident outcomes produced updated tests, documentation, alerts, workflow rules, or governance constraints.", "persona_relevance": [ "CTO", "Platform Leader", "VP Engineering" ], "use_cases": [ "diagnose_engineering_capacity", "assess_agentic_sdlc_readiness" ], "required_sources": [ "incident system", "runbooks", "test suite", "workflow rules", "agent instructions" ], "minimum_evidence": [ "incident outcome", "updated test", "updated runbook", "new workflow rule" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Knowledge Transfer Readiness", "Upside Potential" ], "risk_flags": [ "repeat_failure", "learning_gap" ], "recommended_report_type": "Knowledge and Architecture Memory Report", "intent": "diagnostic", "level": "cto", "tags": [ "incidents", "learning", "memory" ], "related_concepts": [ "incident_memory", "durable_learning" ], "doctrine_answer": "An incident becomes durable system memory only when verified lessons update executable controls such as tests, alerts, runbooks, ownership, architecture records, workflow rules, or agent instructions.", "answer_card_template": { "answer_type": "knowledge_memory_answer", "good_answer_pattern": "A strong answer directly answers: \"How are incidents converted into durable system memory?\" Validation method: Verify incident outcomes produced updated tests, documentation, alerts, workflow rules, or governance constraints. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Knowledge Transfer Readiness, Upside Potential.", "common_failure_pattern": "A weak answer gives a generic knowledge architecture memory diagnosis instead of proving this question with incident system, runbooks, test suite, and related approved sources. It misses the operating risk: Learning requires failures to update rules, tests, runbooks, and agent instructions.", "recommended_report_section": "Knowledge and Architecture Memory Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "knowledge-008", "domain": "knowledge_architecture_memory", "question": "What evidence proves a distributed contributor is ready for ownership?", "why_it_matters": "Ownership should be evidence-based, not tenure-based.", "validation_signal": "Review accepted work, correction rate, service understanding, incident handling, deployment success, and escalation behavior.", "persona_relevance": [ "VP Engineering", "CTO" ], "use_cases": [ "improve_existing_capacity_topology", "determine_capacity_absorption_readiness" ], "required_sources": [ "pull request system", "work tracker", "incident system", "deployment system" ], "minimum_evidence": [ "accepted work", "correction rate", "deployment success", "escalation behavior" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Knowledge Transfer Readiness", "Topology Fit" ], "risk_flags": [ "premature_ownership", "service_risk" ], "recommended_report_type": "Capacity Topology Readiness Report", "intent": "diagnostic", "level": "engineering_lead", "tags": [ "ownership-readiness", "distributed", "evidence" ], "related_concepts": [ "ownership_readiness", "evidence_based_delegation" ], "doctrine_answer": "Ownership readiness is demonstrated by accepted work, accurate system explanations, reliable deployments, low correction rates, sound incident behavior, and appropriate escalation across a representative evidence window.", "answer_card_template": { "answer_type": "knowledge_memory_answer", "good_answer_pattern": "A strong answer directly answers: \"What evidence proves a distributed contributor is ready for ownership?\" Validation method: Review accepted work, correction rate, service understanding, incident handling, deployment success, and escalation behavior. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Knowledge Transfer Readiness, Topology Fit.", "common_failure_pattern": "A weak answer gives a generic knowledge architecture memory diagnosis instead of proving this question with pull request system, work tracker, incident system, and related approved sources. It misses the operating risk: Ownership should be evidence-based, not tenure-based.", "recommended_report_section": "Capacity Topology Readiness Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } } ], "execution_harness": [ { "id": "execution-001", "domain": "execution_harness", "question": "How standardized are CI/CD pipelines across teams, services, and contributor types?", "why_it_matters": "Distributed and AI-assisted capacity requires reproducible execution, not local delivery customs.", "validation_signal": "Compare pipeline templates, required gates, deployment paths, manual overrides, and exception frequency.", "persona_relevance": [ "CTO", "VP Engineering", "DevOps Leader" ], "use_cases": [ "determine_capacity_absorption_readiness", "improve_existing_capacity_topology" ], "required_sources": [ "CI/CD", "deployment system", "repository templates", "exception logs" ], "minimum_evidence": [ "pipeline template", "required gate", "manual override", "exception frequency" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Execution Determinism", "Governance Completeness" ], "risk_flags": [ "pipeline_variance", "manual_override" ], "recommended_report_type": "Execution Determinism Report", "intent": "diagnostic", "level": "cto", "tags": [ "ci-cd", "standardization", "execution" ], "related_concepts": [ "execution_harness", "pipeline_standardization" ], "doctrine_answer": "CI/CD is standardized when teams and contributor types use versioned pipeline templates, required quality and approval gates, consistent deployment paths, controlled exceptions, and equivalent audit evidence.", "answer_card_template": { "answer_type": "execution_control_answer", "good_answer_pattern": "A strong answer directly answers: \"How standardized are CI/CD pipelines across teams, services, and contributor types?\" Validation method: Compare pipeline templates, required gates, deployment paths, manual overrides, and exception frequency. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Execution Determinism, Governance Completeness.", "common_failure_pattern": "A weak answer gives a generic execution harness diagnosis instead of proving this question with CI/CD, deployment system, repository templates, and related approved sources. It misses the operating risk: Distributed and AI-assisted capacity requires reproducible execution, not local delivery customs.", "recommended_report_section": "Execution Determinism Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "execution-002", "domain": "execution_harness", "question": "Where does execution variance enter the delivery system?", "why_it_matters": "Variance hides inside local workflow differences, skipped gates, environment drift, and undocumented release paths.", "validation_signal": "Trace delivery flows by team and identify manual steps, skipped gates, divergent templates, and environment-specific behavior.", "persona_relevance": [ "VP Engineering", "DevOps Leader", "Platform Leader" ], "use_cases": [ "diagnose_engineering_capacity", "determine_capacity_absorption_readiness" ], "required_sources": [ "CI/CD", "deployment system", "work tracker", "environment inventory" ], "minimum_evidence": [ "manual step", "skipped gate", "template divergence", "environment drift" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Execution Determinism", "Telemetry Trust" ], "risk_flags": [ "execution_drift", "environment_drift" ], "recommended_report_type": "Execution Determinism Report", "intent": "diagnostic", "level": "engineering_lead", "tags": [ "variance", "delivery", "environment" ], "related_concepts": [ "execution_variance", "environment_drift" ], "doctrine_answer": "Execution variance enters wherever teams use divergent templates, manual steps, skipped gates, environment-specific behavior, undocumented release paths, or ungoverned overrides that change outcomes for equivalent work.", "answer_card_template": { "answer_type": "execution_control_answer", "good_answer_pattern": "A strong answer directly answers: \"Where does execution variance enter the delivery system?\" Validation method: Trace delivery flows by team and identify manual steps, skipped gates, divergent templates, and environment-specific behavior. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Execution Determinism, Telemetry Trust.", "common_failure_pattern": "A weak answer gives a generic execution harness diagnosis instead of proving this question with CI/CD, deployment system, work tracker, and related approved sources. It misses the operating risk: Variance hides inside local workflow differences, skipped gates, environment drift, and undocumented release paths.", "recommended_report_section": "Execution Determinism Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "execution-003", "domain": "execution_harness", "question": "Which SDLC controls are system-enforced versus manually enforced?", "why_it_matters": "Manual enforcement breaks under scale, distribution, and agentic speed.", "validation_signal": "Classify each SDLC control as automated, policy-enforced, manually enforced, or undocumented.", "persona_relevance": [ "CIO", "CTO", "DevOps Leader" ], "use_cases": [ "evaluate_governance_security_and_ip_risk", "determine_capacity_absorption_readiness" ], "required_sources": [ "CI/CD", "policy documentation", "repository settings", "approval workflow" ], "minimum_evidence": [ "control class", "automation status", "manual gate", "undocumented exception" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Execution Determinism", "Governance Completeness" ], "risk_flags": [ "manual_control_failure", "policy_drift" ], "recommended_report_type": "Execution Determinism Report", "intent": "diagnostic", "level": "cio", "tags": [ "controls", "automation", "governance" ], "related_concepts": [ "system_enforcement", "manual_control" ], "doctrine_answer": "A control is system-enforced when the delivery platform automatically applies and records it; a policy, checklist, or reviewer habit is manually enforced and should not be treated as deterministic control.", "answer_card_template": { "answer_type": "execution_control_answer", "good_answer_pattern": "A strong answer directly answers: \"Which SDLC controls are system-enforced versus manually enforced?\" Validation method: Classify each SDLC control as automated, policy-enforced, manually enforced, or undocumented. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Execution Determinism, Governance Completeness.", "common_failure_pattern": "A weak answer gives a generic execution harness diagnosis instead of proving this question with CI/CD, policy documentation, repository settings, and related approved sources. It misses the operating risk: Manual enforcement breaks under scale, distribution, and agentic speed.", "recommended_report_section": "Execution Determinism Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "execution-004", "domain": "execution_harness", "question": "How reproducible are production deployments across services?", "why_it_matters": "A topology can scale only when deployments behave as governed system states.", "validation_signal": "Compare deployment inputs, environment state, approval paths, rollback readiness, and post-deploy outcomes across services.", "persona_relevance": [ "CTO", "DevOps Leader", "Platform Leader" ], "use_cases": [ "determine_capacity_absorption_readiness", "evaluate_governance_security_and_ip_risk" ], "required_sources": [ "deployment system", "CI/CD", "environment inventory", "rollback records" ], "minimum_evidence": [ "deployment input", "approval path", "rollback record", "post-deploy outcome" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Execution Determinism", "Governance Completeness" ], "risk_flags": [ "deployment_non_reproducibility", "rollback_gap" ], "recommended_report_type": "Execution Determinism Report", "intent": "diagnostic", "level": "cto", "tags": [ "deployment", "reproducibility", "rollback" ], "related_concepts": [ "deployment_determinism", "release_path" ], "doctrine_answer": "Production deployments are reproducible when equivalent versioned inputs, environment state, approvals, and pipeline rules produce consistent releases with tested rollback paths and explainable outcomes across services.", "answer_card_template": { "answer_type": "execution_control_answer", "good_answer_pattern": "A strong answer directly answers: \"How reproducible are production deployments across services?\" Validation method: Compare deployment inputs, environment state, approval paths, rollback readiness, and post-deploy outcomes across services. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Execution Determinism, Governance Completeness.", "common_failure_pattern": "A weak answer gives a generic execution harness diagnosis instead of proving this question with deployment system, CI/CD, environment inventory, and related approved sources. It misses the operating risk: A topology can scale only when deployments behave as governed system states.", "recommended_report_section": "Execution Determinism Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "execution-005", "domain": "execution_harness", "question": "Where do pipeline failures originate most frequently?", "why_it_matters": "Failure concentration reveals weak execution stages before capacity increases amplify them.", "validation_signal": "Classify failed pipeline runs by stage, owner, cause class, recovery path, and recurrence.", "persona_relevance": [ "VP Engineering", "DevOps Leader" ], "use_cases": [ "diagnose_engineering_capacity", "determine_capacity_absorption_readiness" ], "required_sources": [ "CI/CD", "incident system", "deployment system" ], "minimum_evidence": [ "failure stage", "cause class", "recovery path", "recurrence" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Execution Determinism", "Telemetry Trust" ], "risk_flags": [ "pipeline_failure_concentration", "recovery_gap" ], "recommended_report_type": "Execution Determinism Report", "intent": "diagnostic", "level": "engineering_lead", "tags": [ "pipeline-failure", "root-cause", "ci-cd" ], "related_concepts": [ "failure_origin", "build_stage" ], "doctrine_answer": "The dominant pipeline failure origin is the stage and cause class with the highest recurring failure burden after runs are classified by build, test, security, approval, environment, deployment, and recovery behavior.", "answer_card_template": { "answer_type": "execution_control_answer", "good_answer_pattern": "A strong answer directly answers: \"Where do pipeline failures originate most frequently?\" Validation method: Classify failed pipeline runs by stage, owner, cause class, recovery path, and recurrence. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Execution Determinism, Telemetry Trust.", "common_failure_pattern": "A weak answer gives a generic execution harness diagnosis instead of proving this question with CI/CD, incident system, deployment system. It misses the operating risk: Failure concentration reveals weak execution stages before capacity increases amplify them.", "recommended_report_section": "Execution Determinism Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "execution-006", "domain": "execution_harness", "question": "Who defines and changes execution rules in the SDLC?", "why_it_matters": "Execution rule ownership is required before distributed teams or agents can safely modify workflows.", "validation_signal": "Map SDLC execution rules to owners, approval authority, change process, and audit record.", "persona_relevance": [ "CTO", "CIO", "DevOps Leader" ], "use_cases": [ "evaluate_governance_security_and_ip_risk", "assess_agentic_sdlc_readiness" ], "required_sources": [ "policy documentation", "CI/CD config", "audit logs", "change management records" ], "minimum_evidence": [ "rule owner", "approval authority", "change process", "audit record" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Execution Determinism", "Governance Completeness" ], "risk_flags": [ "rule_ownership_gap", "unaudited_change" ], "recommended_report_type": "Governance, Security, and IP Control Report", "intent": "diagnostic", "level": "cto", "tags": [ "execution-rules", "ownership", "audit" ], "related_concepts": [ "rule_owner", "execution_policy" ], "doctrine_answer": "Execution rules require named owners, authorized approvers, versioned change records, audit history, exception handling, and rollback authority before teams or agents can modify them safely.", "answer_card_template": { "answer_type": "execution_control_answer", "good_answer_pattern": "A strong answer directly answers: \"Who defines and changes execution rules in the SDLC?\" Validation method: Map SDLC execution rules to owners, approval authority, change process, and audit record. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Execution Determinism, Governance Completeness.", "common_failure_pattern": "A weak answer gives a generic execution harness diagnosis instead of proving this question with policy documentation, CI/CD config, audit logs, and related approved sources. It misses the operating risk: Execution rule ownership is required before distributed teams or agents can safely modify workflows.", "recommended_report_section": "Governance, Security, and IP Control Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "execution-007", "domain": "execution_harness", "question": "How are workflow standards propagated across teams?", "why_it_matters": "Scaling requires controlled propagation of standards rather than informal copying.", "validation_signal": "Compare documented standards with templates, automated checks, rollout records, and exception logs.", "persona_relevance": [ "VP Engineering", "Platform Leader", "DevOps Leader" ], "use_cases": [ "determine_capacity_absorption_readiness", "improve_existing_capacity_topology" ], "required_sources": [ "repository templates", "CI/CD", "documentation", "exception logs" ], "minimum_evidence": [ "standard template", "automated check", "rollout record", "exception" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Execution Determinism", "Knowledge Transfer Readiness" ], "risk_flags": [ "standard_drift", "local_execution_variance" ], "recommended_report_type": "Execution Determinism Report", "intent": "diagnostic", "level": "engineering_lead", "tags": [ "standards", "propagation", "workflow" ], "related_concepts": [ "workflow_standard", "policy_enforcement" ], "doctrine_answer": "Workflow standards propagate reliably through versioned templates, automated checks, controlled rollout, conformance telemetry, and explicit exception records rather than documentation and informal copying alone.", "answer_card_template": { "answer_type": "execution_control_answer", "good_answer_pattern": "A strong answer directly answers: \"How are workflow standards propagated across teams?\" Validation method: Compare documented standards with templates, automated checks, rollout records, and exception logs. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Execution Determinism, Knowledge Transfer Readiness.", "common_failure_pattern": "A weak answer gives a generic execution harness diagnosis instead of proving this question with repository templates, CI/CD, documentation, and related approved sources. It misses the operating risk: Scaling requires controlled propagation of standards rather than informal copying.", "recommended_report_section": "Execution Determinism Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "execution-008", "domain": "execution_harness", "question": "What is the cost of pipeline inconsistency?", "why_it_matters": "Inconsistency converts capacity into waiting, rework, release risk, and operational overhead.", "validation_signal": "Compare cycle time, failed runs, manual intervention, rollback events, and rework by pipeline class.", "persona_relevance": [ "CIO", "CTO", "DevOps Leader" ], "use_cases": [ "diagnose_engineering_capacity", "build_distributed_capacity_strategy" ], "required_sources": [ "CI/CD", "deployment system", "work tracker", "incident system" ], "minimum_evidence": [ "cycle time by pipeline class", "failed run rate", "manual intervention", "rollback event" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Execution Determinism", "Cost/Value/Risk Economics" ], "risk_flags": [ "pipeline_inconsistency_cost", "release_risk" ], "recommended_report_type": "Execution Determinism Report", "intent": "diagnostic", "level": "cio", "tags": [ "cost", "pipeline", "inconsistency" ], "related_concepts": [ "pipeline_cost", "release_risk" ], "doctrine_answer": "Pipeline inconsistency costs the engineering system the measured cycle time, failed runs, manual intervention, rework, rollback exposure, and release delay attributable to divergent execution paths.", "answer_card_template": { "answer_type": "execution_control_answer", "good_answer_pattern": "A strong answer directly answers: \"What is the cost of pipeline inconsistency?\" Validation method: Compare cycle time, failed runs, manual intervention, rollback events, and rework by pipeline class. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Execution Determinism, Cost/Value/Risk Economics.", "common_failure_pattern": "A weak answer gives a generic execution harness diagnosis instead of proving this question with CI/CD, deployment system, work tracker, and related approved sources. It misses the operating risk: Inconsistency converts capacity into waiting, rework, release risk, and operational overhead.", "recommended_report_section": "Execution Determinism Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "execution-009", "domain": "execution_harness", "question": "Which execution paths are safe for AI-assisted or external contributors?", "why_it_matters": "Delegation safety depends on deterministic test, review, approval, deployment, and rollback paths.", "validation_signal": "Classify execution paths by test reliability, approval boundary, production impact, auditability, and rollback readiness.", "persona_relevance": [ "CTO", "CIO", "AI Governance Leader", "DevOps Leader" ], "use_cases": [ "assess_agentic_sdlc_readiness", "improve_existing_capacity_topology", "evaluate_governance_security_and_ip_risk" ], "required_sources": [ "CI/CD", "deployment system", "policy documentation", "audit logs" ], "minimum_evidence": [ "test reliability", "approval boundary", "production impact", "rollback readiness" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Execution Determinism", "Agent Delegation Safety", "Governance Completeness" ], "risk_flags": [ "unsafe_execution_path", "agent_blast_radius" ], "recommended_report_type": "Agent Delegation Safety Matrix", "intent": "diagnostic", "level": "cto", "tags": [ "ai", "external-contributors", "execution-path" ], "related_concepts": [ "safe_delegation", "approval_path" ], "doctrine_answer": "An execution path is safe for AI-assisted or external contribution only when permissions are bounded and tests, review, approval, deployment, audit, and rollback controls constrain the path's blast radius.", "answer_card_template": { "answer_type": "execution_control_answer", "good_answer_pattern": "A strong answer directly answers: \"Which execution paths are safe for AI-assisted or external contributors?\" Validation method: Classify execution paths by test reliability, approval boundary, production impact, auditability, and rollback readiness. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Execution Determinism, Agent Delegation Safety, Governance Completeness.", "common_failure_pattern": "A weak answer gives a generic execution harness diagnosis instead of proving this question with CI/CD, deployment system, policy documentation, and related approved sources. It misses the operating risk: Delegation safety depends on deterministic test, review, approval, deployment, and rollback paths.", "recommended_report_section": "Agent Delegation Safety Matrix", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "execution-010", "domain": "execution_harness", "question": "What breaks in execution when delivery volume increases?", "why_it_matters": "Volume exposes weak gates, slow reviews, unstable environments, and fragile deployment paths.", "validation_signal": "Compare failure rates, queue times, environment conflicts, rollback events, and approval latency before and after volume changes.", "persona_relevance": [ "CTO", "VP Engineering", "DevOps Leader" ], "use_cases": [ "determine_capacity_absorption_readiness", "diagnose_engineering_capacity" ], "required_sources": [ "CI/CD", "deployment system", "pull request system", "work tracker" ], "minimum_evidence": [ "volume change", "failure rate", "queue time", "environment conflict" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Execution Determinism", "Capacity Reality" ], "risk_flags": [ "volume_degradation", "execution_saturation" ], "recommended_report_type": "Execution Determinism Report", "intent": "diagnostic", "level": "cto", "tags": [ "volume", "scaling", "execution" ], "related_concepts": [ "delivery_volume", "execution_saturation" ], "doctrine_answer": "When delivery volume rises, the first execution failures appear at gates whose service capacity does not scale, including review, tests, environments, approvals, deployment concurrency, and rollback handling.", "answer_card_template": { "answer_type": "execution_control_answer", "good_answer_pattern": "A strong answer directly answers: \"What breaks in execution when delivery volume increases?\" Validation method: Compare failure rates, queue times, environment conflicts, rollback events, and approval latency before and after volume changes. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Execution Determinism, Capacity Reality.", "common_failure_pattern": "A weak answer gives a generic execution harness diagnosis instead of proving this question with CI/CD, deployment system, pull request system, and related approved sources. It misses the operating risk: Volume exposes weak gates, slow reviews, unstable environments, and fragile deployment paths.", "recommended_report_section": "Execution Determinism Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } } ], "decision_grade_telemetry": [ { "id": "telemetry-001", "domain": "decision_grade_telemetry", "question": "Which engineering signals are trusted enough to govern capacity topology decisions?", "why_it_matters": "Topology decisions require evidence that explains delivery behavior, not dashboard activity.", "validation_signal": "Inventory metrics used for decisions and classify each by source reliability, freshness, coverage, and decision history.", "persona_relevance": [ "CTO", "CIO", "VP Engineering" ], "use_cases": [ "build_distributed_capacity_strategy", "diagnose_engineering_capacity" ], "required_sources": [ "work tracker", "CI/CD", "deployment system", "incident system", "observability dashboards" ], "minimum_evidence": [ "metric source", "freshness", "coverage", "decision history" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Telemetry Trust", "Governance Completeness" ], "risk_flags": [ "dashboard_noise", "low_signal_decision" ], "recommended_report_type": "Engineering Capacity OS Diagnostic", "intent": "diagnostic", "level": "cto", "tags": [ "telemetry", "decision-grade", "metrics" ], "related_concepts": [ "telemetry_trust", "decision_signal" ], "doctrine_answer": "A signal is trusted for topology governance only when its source, definition, freshness, coverage, aggregation, known bias, and history of decision use are documented and tied to delivery outcomes.", "answer_card_template": { "answer_type": "telemetry_trust_answer", "good_answer_pattern": "A strong answer directly answers: \"Which engineering signals are trusted enough to govern capacity topology decisions?\" Validation method: Inventory metrics used for decisions and classify each by source reliability, freshness, coverage, and decision history. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Telemetry Trust, Governance Completeness.", "common_failure_pattern": "A weak answer gives a generic decision grade telemetry diagnosis instead of proving this question with work tracker, CI/CD, deployment system, and related approved sources. It misses the operating risk: Topology decisions require evidence that explains delivery behavior, not dashboard activity.", "recommended_report_section": "Engineering Capacity OS Diagnostic", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "telemetry-002", "domain": "decision_grade_telemetry", "question": "Which signals correlate with delivery success rather than activity volume?", "why_it_matters": "Activity metrics can increase while speed, quality, cost, risk, and business value degrade.", "validation_signal": "Compare candidate metrics with delivery outcomes, escaped defects, rework, cycle time, incident impact, and business milestones.", "persona_relevance": [ "CTO", "CIO", "VP Engineering" ], "use_cases": [ "diagnose_engineering_capacity", "build_distributed_capacity_strategy" ], "required_sources": [ "work tracker", "quality system", "incident system", "product milestones", "deployment system" ], "minimum_evidence": [ "metric correlation", "defect signal", "cycle time", "business milestone" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Telemetry Trust", "Cost/Value/Risk Economics" ], "risk_flags": [ "vanity_metric", "activity_bias" ], "recommended_report_type": "Engineering Capacity OS Diagnostic", "intent": "diagnostic", "level": "cto", "tags": [ "metrics", "outcomes", "value" ], "related_concepts": [ "outcome_metric", "activity_metric" ], "doctrine_answer": "Outcome signals are metrics that demonstrate a stable relationship with delivery speed, quality, cost, risk, reliability, or business milestones; activity counts without that relationship are not decision-grade evidence.", "answer_card_template": { "answer_type": "telemetry_trust_answer", "good_answer_pattern": "A strong answer directly answers: \"Which signals correlate with delivery success rather than activity volume?\" Validation method: Compare candidate metrics with delivery outcomes, escaped defects, rework, cycle time, incident impact, and business milestones. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Telemetry Trust, Cost/Value/Risk Economics.", "common_failure_pattern": "A weak answer gives a generic decision grade telemetry diagnosis instead of proving this question with work tracker, quality system, incident system, and related approved sources. It misses the operating risk: Activity metrics can increase while speed, quality, cost, risk, and business value degrade.", "recommended_report_section": "Engineering Capacity OS Diagnostic", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "telemetry-003", "domain": "decision_grade_telemetry", "question": "How real-time is delivery visibility for leaders?", "why_it_matters": "Slow telemetry creates delayed intervention and makes adaptive control unsafe.", "validation_signal": "Measure reporting latency for work state, review queues, CI/CD failures, deployment outcomes, incidents, and agent actions.", "persona_relevance": [ "CTO", "CIO", "Platform Leader" ], "use_cases": [ "diagnose_engineering_capacity", "assess_agentic_sdlc_readiness" ], "required_sources": [ "work tracker", "pull request system", "CI/CD", "deployment system", "incident system", "agent tool logs" ], "minimum_evidence": [ "reporting latency", "refresh interval", "coverage gap", "stale metric" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Telemetry Trust", "Agent Delegation Safety" ], "risk_flags": [ "stale_visibility", "late_intervention" ], "recommended_report_type": "Engineering Capacity OS Diagnostic", "intent": "diagnostic", "level": "cto", "tags": [ "real-time", "visibility", "telemetry" ], "related_concepts": [ "telemetry_freshness", "delivery_visibility" ], "doctrine_answer": "Delivery visibility is real-time only to the degree that reporting latency remains below the intervention window for work queues, reviews, pipeline failures, deployments, incidents, and agent actions.", "answer_card_template": { "answer_type": "telemetry_trust_answer", "good_answer_pattern": "A strong answer directly answers: \"How real-time is delivery visibility for leaders?\" Validation method: Measure reporting latency for work state, review queues, CI/CD failures, deployment outcomes, incidents, and agent actions. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Telemetry Trust, Agent Delegation Safety.", "common_failure_pattern": "A weak answer gives a generic decision grade telemetry diagnosis instead of proving this question with work tracker, pull request system, CI/CD, and related approved sources. It misses the operating risk: Slow telemetry creates delayed intervention and makes adaptive control unsafe.", "recommended_report_section": "Engineering Capacity OS Diagnostic", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "telemetry-004", "domain": "decision_grade_telemetry", "question": "Where are queues invisible to current dashboards?", "why_it_matters": "Hidden queues are a common cause of false capacity conclusions.", "validation_signal": "Compare work tracker states, PR waiting time, approval wait, dependency wait, incident interruption, and blocked comments against dashboard coverage.", "persona_relevance": [ "VP Engineering", "Platform Leader" ], "use_cases": [ "diagnose_engineering_capacity", "determine_capacity_absorption_readiness" ], "required_sources": [ "work tracker", "pull request system", "approval workflow", "incident system" ], "minimum_evidence": [ "hidden wait", "approval wait", "dependency wait", "dashboard coverage" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Telemetry Trust", "Capacity Reality" ], "risk_flags": [ "hidden_queue", "misdiagnosed_capacity" ], "recommended_report_type": "Engineering Capacity OS Diagnostic", "intent": "diagnostic", "level": "engineering_lead", "tags": [ "queues", "dashboard", "visibility" ], "related_concepts": [ "hidden_queue", "queue_time" ], "doctrine_answer": "A queue is invisible when work waits for review, approval, dependencies, decisions, environments, or incident recovery without a distinct timestamped state in the leadership telemetry model.", "answer_card_template": { "answer_type": "telemetry_trust_answer", "good_answer_pattern": "A strong answer directly answers: \"Where are queues invisible to current dashboards?\" Validation method: Compare work tracker states, PR waiting time, approval wait, dependency wait, incident interruption, and blocked comments against dashboard coverage. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Telemetry Trust, Capacity Reality.", "common_failure_pattern": "A weak answer gives a generic decision grade telemetry diagnosis instead of proving this question with work tracker, pull request system, approval workflow, and related approved sources. It misses the operating risk: Hidden queues are a common cause of false capacity conclusions.", "recommended_report_section": "Engineering Capacity OS Diagnostic", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "telemetry-005", "domain": "decision_grade_telemetry", "question": "Which telemetry detects quality degradation after capacity, topology, or AI changes?", "why_it_matters": "A capacity intervention is weak if it increases speed while degrading quality or risk.", "validation_signal": "Track defect escape, failed tests, review correction rate, reverts, incidents, rollback events, and customer-impacting defects after change.", "persona_relevance": [ "CTO", "CIO", "VP Engineering", "AI Governance Leader" ], "use_cases": [ "assess_agentic_sdlc_readiness", "improve_existing_capacity_topology", "evaluate_governance_security_and_ip_risk" ], "required_sources": [ "quality system", "pull request system", "CI/CD", "incident system", "deployment system" ], "minimum_evidence": [ "defect escape", "review correction", "revert", "rollback", "incident" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Telemetry Trust", "Agent Delegation Safety", "Cost/Value/Risk Economics" ], "risk_flags": [ "quality_degradation", "ai_rework" ], "recommended_report_type": "Agent Delegation Safety Matrix", "intent": "diagnostic", "level": "cto", "tags": [ "quality", "degradation", "ai" ], "related_concepts": [ "quality_signal", "degradation_detection" ], "doctrine_answer": "Quality degradation after a capacity or AI change is detected through changes in failed tests, review corrections, reverts, escaped defects, incidents, rollback events, and customer impact against a pre-change baseline.", "answer_card_template": { "answer_type": "telemetry_trust_answer", "good_answer_pattern": "A strong answer directly answers: \"Which telemetry detects quality degradation after capacity, topology, or AI changes?\" Validation method: Track defect escape, failed tests, review correction rate, reverts, incidents, rollback events, and customer-impacting defects after change. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Telemetry Trust, Agent Delegation Safety, Cost/Value/Risk Economics.", "common_failure_pattern": "A weak answer gives a generic decision grade telemetry diagnosis instead of proving this question with quality system, pull request system, CI/CD, and related approved sources. It misses the operating risk: A capacity intervention is weak if it increases speed while degrading quality or risk.", "recommended_report_section": "Agent Delegation Safety Matrix", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "telemetry-006", "domain": "decision_grade_telemetry", "question": "What telemetry compares topology performance without exposing individual employee data?", "why_it_matters": "Leaders need topology evidence while avoiding surveillance and individual performance misuse.", "validation_signal": "Aggregate cycle time, queue time, deployment success, defect rate, incident interruption, and rework by workstream or team-level topology.", "persona_relevance": [ "CIO", "CTO", "VP Engineering" ], "use_cases": [ "build_distributed_capacity_strategy", "evaluate_governance_security_and_ip_risk" ], "required_sources": [ "work tracker", "CI/CD", "deployment system", "incident system" ], "minimum_evidence": [ "aggregate cycle time", "team-level queue time", "topology class", "defect rate" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Telemetry Trust", "Governance Completeness" ], "risk_flags": [ "privacy_violation", "bad_benchmark" ], "recommended_report_type": "Capacity Topology Readiness Report", "intent": "diagnostic", "level": "cio", "tags": [ "privacy", "topology", "benchmark" ], "related_concepts": [ "aggregate_telemetry", "privacy_boundary" ], "doctrine_answer": "Topology performance should be compared with aggregated workstream or team-level flow, quality, deployment, incident, and rework signals, never individual surveillance or employee ranking.", "answer_card_template": { "answer_type": "telemetry_trust_answer", "good_answer_pattern": "A strong answer directly answers: \"What telemetry compares topology performance without exposing individual employee data?\" Validation method: Aggregate cycle time, queue time, deployment success, defect rate, incident interruption, and rework by workstream or team-level topology. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Telemetry Trust, Governance Completeness.", "common_failure_pattern": "A weak answer gives a generic decision grade telemetry diagnosis instead of proving this question with work tracker, CI/CD, deployment system, and related approved sources. It misses the operating risk: Leaders need topology evidence while avoiding surveillance and individual performance misuse.", "recommended_report_section": "Capacity Topology Readiness Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "telemetry-007", "domain": "decision_grade_telemetry", "question": "Which metrics should trigger governance review before scaling automation?", "why_it_matters": "Agentic and adaptive systems need stop conditions before local optimizations harm global performance.", "validation_signal": "Define thresholds for failed validations, reverted changes, policy exceptions, human overrides, incident correlation, and quality drift.", "persona_relevance": [ "CIO", "AI Governance Leader", "CTO" ], "use_cases": [ "assess_agentic_sdlc_readiness", "evaluate_governance_security_and_ip_risk" ], "required_sources": [ "agent tool logs", "CI/CD", "policy exception logs", "incident system", "pull request system" ], "minimum_evidence": [ "validation failure threshold", "human override rate", "policy exception", "quality drift" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Telemetry Trust", "Agent Delegation Safety", "Governance Completeness" ], "risk_flags": [ "automation_without_stop_condition", "recursive_degradation" ], "recommended_report_type": "Governance, Security, and IP Control Report", "intent": "diagnostic", "level": "cio", "tags": [ "governance", "automation", "stop-condition" ], "related_concepts": [ "stop_condition", "governance_trigger" ], "doctrine_answer": "Governance review should trigger when agent or automation telemetry crosses predefined limits for failed validation, reverts, policy exceptions, human overrides, quality drift, incident correlation, or unbounded actions.", "answer_card_template": { "answer_type": "telemetry_trust_answer", "good_answer_pattern": "A strong answer directly answers: \"Which metrics should trigger governance review before scaling automation?\" Validation method: Define thresholds for failed validations, reverted changes, policy exceptions, human overrides, incident correlation, and quality drift. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Telemetry Trust, Agent Delegation Safety, Governance Completeness.", "common_failure_pattern": "A weak answer gives a generic decision grade telemetry diagnosis instead of proving this question with agent tool logs, CI/CD, policy exception logs, and related approved sources. It misses the operating risk: Agentic and adaptive systems need stop conditions before local optimizations harm global performance.", "recommended_report_section": "Governance, Security, and IP Control Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "telemetry-008", "domain": "decision_grade_telemetry", "question": "Which signals are missing but necessary for the next operating decision?", "why_it_matters": "A responsible model should mark unknowns instead of inventing certainty.", "validation_signal": "Compare the decision to required sources, available evidence, confidence tier, and missing instrumentation.", "persona_relevance": [ "CTO", "CIO", "VP Engineering" ], "use_cases": [ "build_distributed_capacity_strategy", "diagnose_engineering_capacity", "evaluate_governance_security_and_ip_risk" ], "required_sources": [ "research question evidence inventory", "metric catalog", "source-system inventory" ], "minimum_evidence": [ "required evidence", "available evidence", "missing instrumentation", "confidence tier" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Telemetry Trust", "Governance Completeness" ], "risk_flags": [ "false_confidence", "missing_instrumentation" ], "recommended_report_type": "Engineering Capacity OS Diagnostic", "intent": "diagnostic", "level": "cto", "tags": [ "missing-data", "confidence", "instrumentation" ], "related_concepts": [ "unknown_evidence", "confidence_tier" ], "doctrine_answer": "A necessary signal is missing when the pending decision requires an evidence class that has no reliable source, insufficient coverage, excessive latency, or an unknown definition; the correct result is an instrumentation gap, not an inferred fact.", "answer_card_template": { "answer_type": "telemetry_trust_answer", "good_answer_pattern": "A strong answer directly answers: \"Which signals are missing but necessary for the next operating decision?\" Validation method: Compare the decision to required sources, available evidence, confidence tier, and missing instrumentation. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Telemetry Trust, Governance Completeness.", "common_failure_pattern": "A weak answer gives a generic decision grade telemetry diagnosis instead of proving this question with research question evidence inventory, metric catalog, source-system inventory. It misses the operating risk: A responsible model should mark unknowns instead of inventing certainty.", "recommended_report_section": "Engineering Capacity OS Diagnostic", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } } ], "governed_agentic_sdlc": [ { "id": "agent-001", "domain": "governed_agentic_sdlc", "question": "Which agentic workflows reduce onboarding time for distributed contributors?", "why_it_matters": "AI can improve capacity only if it reduces context acquisition cost without increasing rework.", "validation_signal": "Compare onboarding duration, first accepted PR, documentation usage, correction rate, and escalation frequency.", "persona_relevance": [ "CTO", "VP Engineering", "AI Governance Leader" ], "use_cases": [ "assess_agentic_sdlc_readiness", "improve_existing_capacity_topology" ], "required_sources": [ "work tracker", "pull request system", "documentation analytics", "agent tool logs" ], "minimum_evidence": [ "onboarding duration", "first accepted PR", "documentation usage", "correction rate" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Agent Delegation Safety", "Knowledge Transfer Readiness" ], "risk_flags": [ "ai_context_error", "rework_increase" ], "recommended_report_type": "Agent Delegation Safety Matrix", "intent": "diagnostic", "level": "cto", "tags": [ "agents", "onboarding", "distributed" ], "related_concepts": [ "agentic_onboarding", "context_acquisition" ], "doctrine_answer": "Agentic workflows reduce onboarding time when they accelerate safe context retrieval, environment setup, task decomposition, and feedback while first accepted work arrives sooner without higher correction or escalation rates.", "answer_card_template": { "answer_type": "agent_delegation_answer", "good_answer_pattern": "A strong answer directly answers: \"Which agentic workflows reduce onboarding time for distributed contributors?\" Validation method: Compare onboarding duration, first accepted PR, documentation usage, correction rate, and escalation frequency. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Agent Delegation Safety, Knowledge Transfer Readiness.", "common_failure_pattern": "A weak answer gives a generic governed agentic sdlc diagnosis instead of proving this question with work tracker, pull request system, documentation analytics, and related approved sources. It misses the operating risk: AI can improve capacity only if it reduces context acquisition cost without increasing rework.", "recommended_report_section": "Agent Delegation Safety Matrix", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "agent-002", "domain": "governed_agentic_sdlc", "question": "Which AI-generated outputs can distributed teams safely validate?", "why_it_matters": "Validation authority must match skill, context, and risk.", "validation_signal": "Classify outputs by reversibility, test coverage, blast radius, required domain knowledge, and approval path.", "persona_relevance": [ "CTO", "AI Governance Leader", "VP Engineering" ], "use_cases": [ "assess_agentic_sdlc_readiness", "evaluate_governance_security_and_ip_risk" ], "required_sources": [ "agent tool logs", "pull request system", "CI/CD", "approval workflow" ], "minimum_evidence": [ "output type", "reversibility", "test coverage", "approval path" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Agent Delegation Safety", "Governance Completeness" ], "risk_flags": [ "validation_authority_gap", "agent_blast_radius" ], "recommended_report_type": "Agent Delegation Safety Matrix", "intent": "diagnostic", "level": "cto", "tags": [ "ai-output", "validation", "distributed" ], "related_concepts": [ "validation_authority", "blast_radius" ], "doctrine_answer": "AI-generated output is safely validatable when the reviewer has the required domain context and the output is reversible, testable, provenance-marked, bounded in blast radius, and subject to an explicit approval path.", "answer_card_template": { "answer_type": "agent_delegation_answer", "good_answer_pattern": "A strong answer directly answers: \"Which AI-generated outputs can distributed teams safely validate?\" Validation method: Classify outputs by reversibility, test coverage, blast radius, required domain knowledge, and approval path. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Agent Delegation Safety, Governance Completeness.", "common_failure_pattern": "A weak answer gives a generic governed agentic sdlc diagnosis instead of proving this question with agent tool logs, pull request system, CI/CD, and related approved sources. It misses the operating risk: Validation authority must match skill, context, and risk.", "recommended_report_section": "Agent Delegation Safety Matrix", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "agent-003", "domain": "governed_agentic_sdlc", "question": "Which AI tools are allowed for each contributor type?", "why_it_matters": "AI usage creates data exposure, IP, and governance risk.", "validation_signal": "Map contributor type to approved tools, data classes, repository access, prompt policy, and audit requirements.", "persona_relevance": [ "CIO", "AI Governance Leader", "CTO" ], "use_cases": [ "assess_agentic_sdlc_readiness", "evaluate_governance_security_and_ip_risk" ], "required_sources": [ "AI tool policy", "identity provider", "repository permissions", "audit logs" ], "minimum_evidence": [ "approved tool", "data class", "access class", "audit requirement" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Agent Delegation Safety", "Governance Completeness" ], "risk_flags": [ "unauthorized_ai_tool", "data_exposure" ], "recommended_report_type": "Governance, Security, and IP Control Report", "intent": "diagnostic", "level": "cio", "tags": [ "ai-tools", "contributors", "policy" ], "related_concepts": [ "tool_permission", "prompt_policy" ], "doctrine_answer": "Allowed AI tools must be assigned by contributor role, task, data classification, repository boundary, retention policy, permission scope, and audit requirement rather than made universally available.", "answer_card_template": { "answer_type": "agent_delegation_answer", "good_answer_pattern": "A strong answer directly answers: \"Which AI tools are allowed for each contributor type?\" Validation method: Map contributor type to approved tools, data classes, repository access, prompt policy, and audit requirements. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Agent Delegation Safety, Governance Completeness.", "common_failure_pattern": "A weak answer gives a generic governed agentic sdlc diagnosis instead of proving this question with AI tool policy, identity provider, repository permissions, and related approved sources. It misses the operating risk: AI usage creates data exposure, IP, and governance risk.", "recommended_report_section": "Governance, Security, and IP Control Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "agent-004", "domain": "governed_agentic_sdlc", "question": "How are AI-generated PRs reviewed across distributed teams?", "why_it_matters": "AI can increase review burden if review policy is unclear.", "validation_signal": "Track PR provenance, review path, correction rate, test evidence, approval authority, and rollback evidence.", "persona_relevance": [ "CTO", "VP Engineering", "AI Governance Leader" ], "use_cases": [ "assess_agentic_sdlc_readiness", "determine_capacity_absorption_readiness" ], "required_sources": [ "pull request system", "agent tool logs", "CI/CD", "approval workflow" ], "minimum_evidence": [ "PR provenance", "review path", "correction rate", "test evidence" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Agent Delegation Safety", "Execution Determinism" ], "risk_flags": [ "review_burden", "unknown_pr_provenance" ], "recommended_report_type": "Agent Delegation Safety Matrix", "intent": "diagnostic", "level": "cto", "tags": [ "ai-pr", "review", "provenance" ], "related_concepts": [ "pr_provenance", "review_policy" ], "doctrine_answer": "AI-generated pull requests require recorded provenance, automated test evidence, risk-based human review, correction tracking, approval authority, and rollback readiness equivalent to or stronger than human-generated changes.", "answer_card_template": { "answer_type": "agent_delegation_answer", "good_answer_pattern": "A strong answer directly answers: \"How are AI-generated PRs reviewed across distributed teams?\" Validation method: Track PR provenance, review path, correction rate, test evidence, approval authority, and rollback evidence. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Agent Delegation Safety, Execution Determinism.", "common_failure_pattern": "A weak answer gives a generic governed agentic sdlc diagnosis instead of proving this question with pull request system, agent tool logs, CI/CD, and related approved sources. It misses the operating risk: AI can increase review burden if review policy is unclear.", "recommended_report_section": "Agent Delegation Safety Matrix", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "agent-005", "domain": "governed_agentic_sdlc", "question": "What telemetry detects agent-generated rework?", "why_it_matters": "AI productivity claims are weak unless rework is measured.", "validation_signal": "Compare reopened tickets, review corrections, failed tests, reverted commits, escaped defects, and cycle-time impact.", "persona_relevance": [ "CTO", "AI Governance Leader", "VP Engineering" ], "use_cases": [ "assess_agentic_sdlc_readiness", "diagnose_engineering_capacity" ], "required_sources": [ "work tracker", "pull request system", "CI/CD", "quality system", "deployment system" ], "minimum_evidence": [ "reopened ticket", "review correction", "failed test", "reverted commit" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Agent Delegation Safety", "Telemetry Trust" ], "risk_flags": [ "agent_rework", "false_productivity" ], "recommended_report_type": "Agent Delegation Safety Matrix", "intent": "diagnostic", "level": "cto", "tags": [ "agent-rework", "telemetry", "quality" ], "related_concepts": [ "rework_signal", "ai_productivity" ], "doctrine_answer": "Agent-generated rework is detected by linking AI provenance to review corrections, reopened work, failed tests, reverted changes, escaped defects, and downstream cycle-time impact.", "answer_card_template": { "answer_type": "agent_delegation_answer", "good_answer_pattern": "A strong answer directly answers: \"What telemetry detects agent-generated rework?\" Validation method: Compare reopened tickets, review corrections, failed tests, reverted commits, escaped defects, and cycle-time impact. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Agent Delegation Safety, Telemetry Trust.", "common_failure_pattern": "A weak answer gives a generic governed agentic sdlc diagnosis instead of proving this question with work tracker, pull request system, CI/CD, and related approved sources. It misses the operating risk: AI productivity claims are weak unless rework is measured.", "recommended_report_section": "Agent Delegation Safety Matrix", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "agent-006", "domain": "governed_agentic_sdlc", "question": "Which workflows should remain human-gated until trust improves?", "why_it_matters": "Agentic delegation should expand only when validation and governance mature.", "validation_signal": "Identify workflows with high ambiguity, sensitive data, customer impact, production impact, or irreversible consequences.", "persona_relevance": [ "CIO", "CTO", "AI Governance Leader" ], "use_cases": [ "assess_agentic_sdlc_readiness", "evaluate_governance_security_and_ip_risk" ], "required_sources": [ "workflow catalog", "security classification", "incident system", "approval policy" ], "minimum_evidence": [ "ambiguity class", "data sensitivity", "production impact", "approval requirement" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Agent Delegation Safety", "Governance Completeness" ], "risk_flags": [ "unsafe_agent_delegation", "irreversible_action" ], "recommended_report_type": "Agent Delegation Safety Matrix", "intent": "diagnostic", "level": "cio", "tags": [ "human-gated", "agents", "risk" ], "related_concepts": [ "human_gate", "trust_boundary" ], "doctrine_answer": "Workflows with high ambiguity, sensitive data, architecture authority, customer or production impact, weak validation, or irreversible consequences should remain human-gated until evidence demonstrates bounded agent reliability.", "answer_card_template": { "answer_type": "agent_delegation_answer", "good_answer_pattern": "A strong answer directly answers: \"Which workflows should remain human-gated until trust improves?\" Validation method: Identify workflows with high ambiguity, sensitive data, customer impact, production impact, or irreversible consequences. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Agent Delegation Safety, Governance Completeness.", "common_failure_pattern": "A weak answer gives a generic governed agentic sdlc diagnosis instead of proving this question with workflow catalog, security classification, incident system, and related approved sources. It misses the operating risk: Agentic delegation should expand only when validation and governance mature.", "recommended_report_section": "Agent Delegation Safety Matrix", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } } ], "governed_adaptive_control_loops": [ { "id": "adaptive-001", "domain": "governed_adaptive_control_loops", "question": "Can the engineering system recommend workflow changes from telemetry without automatically applying them?", "why_it_matters": "Adaptive control should begin with governed recommendations before self-modifying execution.", "validation_signal": "Verify recommendation source, evidence trail, approval path, rollback path, and post-change measurement.", "persona_relevance": [ "CTO", "CIO", "AI Governance Leader" ], "use_cases": [ "assess_agentic_sdlc_readiness", "evaluate_governance_security_and_ip_risk" ], "required_sources": [ "telemetry platform", "workflow rules", "approval workflow", "audit logs" ], "minimum_evidence": [ "recommendation", "evidence trail", "approval path", "rollback path" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Agent Delegation Safety", "Governance Completeness", "Upside Potential" ], "risk_flags": [ "unapproved_self_modification", "automation_overreach" ], "recommended_report_type": "Governed Adaptive Control Loop Review", "intent": "diagnostic", "level": "cto", "tags": [ "adaptive", "recommendation", "governance" ], "related_concepts": [ "adaptive_control", "governed_recommendation" ], "doctrine_answer": "The system may generate evidence-backed workflow recommendations without applying them; each recommendation must expose its source signals, assumptions, expected effect, approval path, measurement plan, and rollback condition.", "answer_card_template": { "answer_type": "adaptive_control_answer", "good_answer_pattern": "A strong answer directly answers: \"Can the engineering system recommend workflow changes from telemetry without automatically applying them?\" Validation method: Verify recommendation source, evidence trail, approval path, rollback path, and post-change measurement. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Agent Delegation Safety, Governance Completeness, Upside Potential.", "common_failure_pattern": "A weak answer gives a generic governed adaptive control loops diagnosis instead of proving this question with telemetry platform, workflow rules, approval workflow, and related approved sources. It misses the operating risk: Adaptive control should begin with governed recommendations before self-modifying execution.", "recommended_report_section": "Governed Adaptive Control Loop Review", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "adaptive-002", "domain": "governed_adaptive_control_loops", "question": "Which workflow rules can be safely modified under governance?", "why_it_matters": "Not every execution rule should be adaptive; some rules encode security, compliance, or architecture constraints.", "validation_signal": "Classify rules by blast radius, reversibility, policy class, source-system owner, and required approval.", "persona_relevance": [ "CIO", "CTO", "AI Governance Leader", "DevOps Leader" ], "use_cases": [ "assess_agentic_sdlc_readiness", "evaluate_governance_security_and_ip_risk" ], "required_sources": [ "workflow rules", "CI/CD config", "policy documentation", "audit logs" ], "minimum_evidence": [ "rule class", "blast radius", "reversibility", "approval requirement" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Governance Completeness", "Agent Delegation Safety" ], "risk_flags": [ "rule_modification_risk", "policy_bypass" ], "recommended_report_type": "Governed Adaptive Control Loop Review", "intent": "diagnostic", "level": "cio", "tags": [ "workflow-rules", "adaptive", "policy" ], "related_concepts": [ "rule_class", "workflow_modification" ], "doctrine_answer": "Only reversible, observable, low-blast-radius workflow rules may be adaptive by default; security, compliance, architecture, data, and production authority rules require explicit human governance.", "answer_card_template": { "answer_type": "adaptive_control_answer", "good_answer_pattern": "A strong answer directly answers: \"Which workflow rules can be safely modified under governance?\" Validation method: Classify rules by blast radius, reversibility, policy class, source-system owner, and required approval. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Governance Completeness, Agent Delegation Safety.", "common_failure_pattern": "A weak answer gives a generic governed adaptive control loops diagnosis instead of proving this question with workflow rules, CI/CD config, policy documentation, and related approved sources. It misses the operating risk: Not every execution rule should be adaptive; some rules encode security, compliance, or architecture constraints.", "recommended_report_section": "Governed Adaptive Control Loop Review", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "adaptive-003", "domain": "governed_adaptive_control_loops", "question": "How does the system detect when adaptive changes degrade performance?", "why_it_matters": "Learning loops need negative feedback and stop conditions.", "validation_signal": "Monitor quality drift, cycle-time degradation, failed validations, human override rate, incident correlation, and rollback triggers after adaptive changes.", "persona_relevance": [ "CTO", "AI Governance Leader", "Platform Leader" ], "use_cases": [ "assess_agentic_sdlc_readiness", "diagnose_engineering_capacity" ], "required_sources": [ "telemetry platform", "agent tool logs", "CI/CD", "incident system", "rollback records" ], "minimum_evidence": [ "post-change delta", "quality drift", "override rate", "rollback trigger" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Telemetry Trust", "Agent Delegation Safety", "Upside Potential" ], "risk_flags": [ "recursive_degradation", "missing_negative_feedback" ], "recommended_report_type": "Governed Adaptive Control Loop Review", "intent": "diagnostic", "level": "cto", "tags": [ "degradation", "feedback", "adaptive" ], "related_concepts": [ "negative_feedback", "post_change_delta" ], "doctrine_answer": "Adaptive degradation is detected by comparing post-change quality, cycle time, failed validation, override, incident, and rollback signals against baselines and predefined stop conditions.", "answer_card_template": { "answer_type": "adaptive_control_answer", "good_answer_pattern": "A strong answer directly answers: \"How does the system detect when adaptive changes degrade performance?\" Validation method: Monitor quality drift, cycle-time degradation, failed validations, human override rate, incident correlation, and rollback triggers after adaptive changes. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Telemetry Trust, Agent Delegation Safety, Upside Potential.", "common_failure_pattern": "A weak answer gives a generic governed adaptive control loops diagnosis instead of proving this question with telemetry platform, agent tool logs, CI/CD, and related approved sources. It misses the operating risk: Learning loops need negative feedback and stop conditions.", "recommended_report_section": "Governed Adaptive Control Loop Review", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "adaptive-004", "domain": "governed_adaptive_control_loops", "question": "Who can approve, audit, and reverse adaptive changes to the SDLC?", "why_it_matters": "Self-improving systems require explicit authority and reversibility.", "validation_signal": "Map adaptive change classes to approvers, audit logs, rollback authority, exception handling, and stop conditions.", "persona_relevance": [ "CIO", "CTO", "AI Governance Leader" ], "use_cases": [ "assess_agentic_sdlc_readiness", "evaluate_governance_security_and_ip_risk" ], "required_sources": [ "policy documentation", "approval workflow", "audit logs", "rollback records" ], "minimum_evidence": [ "approver", "audit log", "rollback authority", "stop condition" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Governance Completeness", "Agent Delegation Safety" ], "risk_flags": [ "authority_gap", "irreversible_adaptive_change" ], "recommended_report_type": "Governance, Security, and IP Control Report", "intent": "diagnostic", "level": "cio", "tags": [ "approval", "audit", "adaptive" ], "related_concepts": [ "adaptive_authority", "rollback_authority" ], "doctrine_answer": "Every adaptive change class must have named approval authority, immutable audit evidence, an accountable system owner, independent rollback authority, and defined emergency stop conditions.", "answer_card_template": { "answer_type": "adaptive_control_answer", "good_answer_pattern": "A strong answer directly answers: \"Who can approve, audit, and reverse adaptive changes to the SDLC?\" Validation method: Map adaptive change classes to approvers, audit logs, rollback authority, exception handling, and stop conditions. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Governance Completeness, Agent Delegation Safety.", "common_failure_pattern": "A weak answer gives a generic governed adaptive control loops diagnosis instead of proving this question with policy documentation, approval workflow, audit logs, and related approved sources. It misses the operating risk: Self-improving systems require explicit authority and reversibility.", "recommended_report_section": "Governance, Security, and IP Control Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } } ], "governance_security_failure_modes": [ { "id": "gov-001", "domain": "governance_security_failure_modes", "question": "Who owns delivery risk for externally or agent-produced work?", "why_it_matters": "Distributed and AI-assisted delivery require clear accountability.", "validation_signal": "Map work ownership to accountable leaders, review authority, approval paths, and incident responsibility.", "persona_relevance": [ "CIO", "CTO", "VP Engineering", "AI Governance Leader" ], "use_cases": [ "evaluate_governance_security_and_ip_risk", "improve_existing_capacity_topology", "assess_agentic_sdlc_readiness" ], "required_sources": [ "ownership map", "approval workflow", "incident system", "contracts or operating agreements" ], "minimum_evidence": [ "accountable owner", "review authority", "approval path", "incident responsibility" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Governance Completeness", "Topology Fit" ], "risk_flags": [ "accountability_gap", "delivery_risk" ], "recommended_report_type": "Governance, Security, and IP Control Report", "intent": "diagnostic", "level": "cio", "tags": [ "accountability", "risk", "external-work" ], "related_concepts": [ "delivery_risk_owner", "accountability" ], "doctrine_answer": "Delivery risk remains owned by the accountable internal leader who authorizes the work and controls acceptance, production approval, and incident response, even when execution is external or agent-assisted.", "answer_card_template": { "answer_type": "governance_failure_answer", "good_answer_pattern": "A strong answer directly answers: \"Who owns delivery risk for externally or agent-produced work?\" Validation method: Map work ownership to accountable leaders, review authority, approval paths, and incident responsibility. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Governance Completeness, Topology Fit.", "common_failure_pattern": "A weak answer gives a generic governance security failure modes diagnosis instead of proving this question with ownership map, approval workflow, incident system, and related approved sources. It misses the operating risk: Distributed and AI-assisted delivery require clear accountability.", "recommended_report_section": "Governance, Security, and IP Control Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "gov-002", "domain": "governance_security_failure_modes", "question": "Which production actions require internal approval?", "why_it_matters": "Production authority must be explicit in distributed systems.", "validation_signal": "Classify deployment, rollback, data migration, configuration, and incident actions by approval requirement.", "persona_relevance": [ "CIO", "CTO", "DevOps Leader" ], "use_cases": [ "evaluate_governance_security_and_ip_risk", "improve_existing_capacity_topology" ], "required_sources": [ "deployment system", "approval workflow", "policy documentation", "audit logs" ], "minimum_evidence": [ "production action", "approval requirement", "approver", "audit record" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Governance Completeness", "Execution Determinism" ], "risk_flags": [ "production_authority_gap", "approval_bypass" ], "recommended_report_type": "Governance, Security, and IP Control Report", "intent": "diagnostic", "level": "cio", "tags": [ "production", "approval", "governance" ], "related_concepts": [ "production_authority", "approval_requirement" ], "doctrine_answer": "Internal approval is required for production actions whose blast radius, data impact, customer effect, irreversibility, or regulatory significance exceeds the organization's predefined authority threshold.", "answer_card_template": { "answer_type": "governance_failure_answer", "good_answer_pattern": "A strong answer directly answers: \"Which production actions require internal approval?\" Validation method: Classify deployment, rollback, data migration, configuration, and incident actions by approval requirement. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Governance Completeness, Execution Determinism.", "common_failure_pattern": "A weak answer gives a generic governance security failure modes diagnosis instead of proving this question with deployment system, approval workflow, policy documentation, and related approved sources. It misses the operating risk: Production authority must be explicit in distributed systems.", "recommended_report_section": "Governance, Security, and IP Control Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "gov-003", "domain": "governance_security_failure_modes", "question": "Which systems are off-limits to external contributors or agents?", "why_it_matters": "Security boundaries must be defined before capacity is distributed.", "validation_signal": "Verify restrictions for sensitive repositories, customer data, secrets, regulated systems, production environments, and privileged tools.", "persona_relevance": [ "CIO", "AI Governance Leader", "CTO" ], "use_cases": [ "evaluate_governance_security_and_ip_risk", "assess_agentic_sdlc_readiness", "improve_existing_capacity_topology" ], "required_sources": [ "security policy", "repository permissions", "identity provider", "data classification" ], "minimum_evidence": [ "restricted system", "access boundary", "data class", "privileged tool" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Governance Completeness", "Agent Delegation Safety" ], "risk_flags": [ "security_boundary_gap", "privileged_access_overreach" ], "recommended_report_type": "Governance, Security, and IP Control Report", "intent": "diagnostic", "level": "cio", "tags": [ "security", "off-limits", "access" ], "related_concepts": [ "security_boundary", "restricted_system" ], "doctrine_answer": "External contributors and agents must be excluded from systems whose data sensitivity, privilege level, regulatory boundary, strategic IP, or production blast radius cannot be contained by least-privilege controls.", "answer_card_template": { "answer_type": "governance_failure_answer", "good_answer_pattern": "A strong answer directly answers: \"Which systems are off-limits to external contributors or agents?\" Validation method: Verify restrictions for sensitive repositories, customer data, secrets, regulated systems, production environments, and privileged tools. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Governance Completeness, Agent Delegation Safety.", "common_failure_pattern": "A weak answer gives a generic governance security failure modes diagnosis instead of proving this question with security policy, repository permissions, identity provider, and related approved sources. It misses the operating risk: Security boundaries must be defined before capacity is distributed.", "recommended_report_section": "Governance, Security, and IP Control Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "gov-004", "domain": "governance_security_failure_modes", "question": "How is IP assignment and contribution provenance verified?", "why_it_matters": "External and AI-assisted work creates IP and ownership questions.", "validation_signal": "Review contracts, contributor agreements, commit provenance, PR metadata, tool usage logs, and approval records.", "persona_relevance": [ "CIO", "CTO", "AI Governance Leader" ], "use_cases": [ "evaluate_governance_security_and_ip_risk", "assess_agentic_sdlc_readiness", "improve_existing_capacity_topology" ], "required_sources": [ "contracts or operating agreements", "repository metadata", "agent tool logs", "approval records" ], "minimum_evidence": [ "IP assignment", "commit provenance", "tool usage log", "approval record" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Governance Completeness", "Agent Delegation Safety" ], "risk_flags": [ "ip_provenance_gap", "unverified_contribution" ], "recommended_report_type": "Governance, Security, and IP Control Report", "intent": "diagnostic", "level": "cio", "tags": [ "ip", "provenance", "contributions" ], "related_concepts": [ "ip_assignment", "contribution_provenance" ], "doctrine_answer": "IP assignment and contribution provenance are verified through enforceable agreements, authenticated contributor identity, commit and PR provenance, AI-tool disclosure, review records, and acceptance history.", "answer_card_template": { "answer_type": "governance_failure_answer", "good_answer_pattern": "A strong answer directly answers: \"How is IP assignment and contribution provenance verified?\" Validation method: Review contracts, contributor agreements, commit provenance, PR metadata, tool usage logs, and approval records. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Governance Completeness, Agent Delegation Safety.", "common_failure_pattern": "A weak answer gives a generic governance security failure modes diagnosis instead of proving this question with contracts or operating agreements, repository metadata, agent tool logs, and related approved sources. It misses the operating risk: External and AI-assisted work creates IP and ownership questions.", "recommended_report_section": "Governance, Security, and IP Control Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "gov-005", "domain": "governance_security_failure_modes", "question": "How are policy exceptions logged and reviewed?", "why_it_matters": "Exceptions reveal where governance is weak or misaligned with reality.", "validation_signal": "Compare exception records, approval paths, recurrence, business justification, and remediation actions.", "persona_relevance": [ "CIO", "CTO", "DevOps Leader" ], "use_cases": [ "evaluate_governance_security_and_ip_risk", "diagnose_engineering_capacity" ], "required_sources": [ "policy exception logs", "approval workflow", "audit logs", "incident system" ], "minimum_evidence": [ "exception record", "approval path", "recurrence", "remediation action" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Governance Completeness", "Telemetry Trust" ], "risk_flags": [ "policy_exception_drift", "governance_lag" ], "recommended_report_type": "Governance, Security, and IP Control Report", "intent": "diagnostic", "level": "cio", "tags": [ "policy-exception", "audit", "governance" ], "related_concepts": [ "policy_exception", "remediation" ], "doctrine_answer": "Policy exceptions require a timestamped request, business justification, accountable approver, bounded duration, affected assets, compensating controls, remediation owner, recurrence review, and closure evidence.", "answer_card_template": { "answer_type": "governance_failure_answer", "good_answer_pattern": "A strong answer directly answers: \"How are policy exceptions logged and reviewed?\" Validation method: Compare exception records, approval paths, recurrence, business justification, and remediation actions. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Governance Completeness, Telemetry Trust.", "common_failure_pattern": "A weak answer gives a generic governance security failure modes diagnosis instead of proving this question with policy exception logs, approval workflow, audit logs, and related approved sources. It misses the operating risk: Exceptions reveal where governance is weak or misaligned with reality.", "recommended_report_section": "Governance, Security, and IP Control Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "gov-006", "domain": "governance_security_failure_modes", "question": "What breaks first when capacity, distribution, or automation increases?", "why_it_matters": "Failure-mode analysis turns scaling plans into testable risk hypotheses.", "validation_signal": "Inspect hidden queues, review bottlenecks, architecture latency, pipeline drift, context loss, agent rework, security access, and governance lag.", "persona_relevance": [ "CTO", "CIO", "VP Engineering", "AI Governance Leader" ], "use_cases": [ "diagnose_engineering_capacity", "determine_capacity_absorption_readiness", "evaluate_governance_security_and_ip_risk" ], "required_sources": [ "work tracker", "pull request system", "CI/CD", "incident system", "audit logs" ], "minimum_evidence": [ "hidden queue", "review bottleneck", "pipeline drift", "governance lag" ], "privacy_boundary": "Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Governance Completeness", "Capacity Reality", "Execution Determinism" ], "risk_flags": [ "failure_mode_unknown", "scaling_degradation" ], "recommended_report_type": "Engineering Capacity OS Diagnostic", "intent": "diagnostic", "level": "cto", "tags": [ "failure-mode", "scaling", "risk" ], "related_concepts": [ "failure_mode_register", "scaling_risk" ], "doctrine_answer": "The first scaling failure is the constraint whose demand grows faster than its control capacity; test this across review queues, architecture decisions, knowledge transfer, pipeline consistency, agent rework, access control, and governance latency.", "answer_card_template": { "answer_type": "governance_failure_answer", "good_answer_pattern": "A strong answer directly answers: \"What breaks first when capacity, distribution, or automation increases?\" Validation method: Inspect hidden queues, review bottlenecks, architecture latency, pipeline drift, context loss, agent rework, security access, and governance lag. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Governance Completeness, Capacity Reality, Execution Determinism.", "common_failure_pattern": "A weak answer gives a generic governance security failure modes diagnosis instead of proving this question with work tracker, pull request system, CI/CD, and related approved sources. It misses the operating risk: Failure-mode analysis turns scaling plans into testable risk hypotheses.", "recommended_report_section": "Engineering Capacity OS Diagnostic", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } } ] }, "validation_framework": [ { "step": "capture_decision", "definition": "State the operating decision the leader actually needs to make." }, { "step": "set_boundary", "definition": "Define time window, included systems, excluded systems, source permissions, and privacy constraints." }, { "step": "collect_evidence", "definition": "Use aggregate source-system evidence, approved MCP retrieval, or a redacted evidence pack." }, { "step": "score_readiness", "definition": "Score readiness dimensions and classify evidence confidence." }, { "step": "choose_next_action", "definition": "Recommend the safest next action without assuming sourcing, hiring, or automation is the answer." } ], "tags": [ "engineering systems", "capacity intelligence", "agentic SDLC", "telemetry-driven engineering", "distributed capacity topology", "location-agnostic capacity design" ], "answer_card_system": { "title": "Answer Card System", "definition": "The answer card turns each CTO research question into a private, evidence-bound diagnostic object. The public site supplies the question, doctrine answer, evidence requirements, confidence rubric, and report shape. The customer answer is generated inside the organization's own MCP environment or from a redacted manual evidence pack.", "public_answer_boundary": "The public answer is doctrine guidance. It explains what a valid answer must prove. It does not guess the customer's internal state.", "why_no_public_customer_answers": "Real answers require private Jira, Linear, GitHub, GitLab, CI/CD, incident, architecture, review, telemetry, policy, and access data. That data should stay inside the organization boundary.", "schema_fields": [ { "field": "question_id", "type": "string", "required": true, "definition": "Stable identifier from the question bank." }, { "field": "domain", "type": "string", "required": true, "definition": "Research domain that owns the question." }, { "field": "question", "type": "string", "required": true, "definition": "Atomic CTO question being answered." }, { "field": "doctrine_answer", "type": "string", "required": true, "definition": "Public baseline answer from the Engineering Capacity OS model." }, { "field": "evidence_summary", "type": "string", "required": true, "definition": "Aggregate, redacted summary of what the internal evidence shows." }, { "field": "observed_state", "type": "enum", "required": true, "definition": "observed, modeled, directional, or unknown." }, { "field": "confidence", "type": "enum", "required": true, "definition": "high, medium, directional, or unknown." }, { "field": "source_classes", "type": "array", "required": true, "definition": "Approved source categories used, never raw sensitive records." }, { "field": "missing_evidence", "type": "array", "required": true, "definition": "Evidence needed before the answer can be treated as reliable." }, { "field": "risk_flags", "type": "array", "required": true, "definition": "System risks surfaced by the answer." }, { "field": "recommended_report_section", "type": "string", "required": true, "definition": "Report section where the answer belongs." }, { "field": "next_safe_action", "type": "string", "required": true, "definition": "One reversible action or measurement step." }, { "field": "do_not_collect", "type": "array", "required": true, "definition": "Sensitive data classes that should not be exported." } ], "confidence_levels": { "high": "90 or more days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30 to 90 days of evidence with partial but useful source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that points to a hypothesis.", "unknown": "No reliable evidence is available. The correct output is instrumentation guidance, not a forced answer." }, "workflow": [ { "step": "Select question", "definition": "Choose one operating decision and one question. Do not run the whole bank when the leader needs a specific decision." }, { "step": "Constrain evidence", "definition": "Define source systems, time window, aggregation level, redaction rules, and data classes that must not leave the organization." }, { "step": "Retrieve aggregate signals", "definition": "Use MCP or exports to retrieve counts, distributions, metadata, examples, and summaries rather than raw source code, secrets, logs, or employee records." }, { "step": "Map to doctrine answer", "definition": "Compare the evidence to the Engineering Capacity OS doctrine answer and identify whether the question is observed, modeled, directional, or unknown." }, { "step": "Write answer card", "definition": "Produce one answer card with confidence, risk flags, missing evidence, report section, and one next safe action." }, { "step": "Validate with the owner", "definition": "A human system owner checks the source classes, assumptions, confidence tier, missing evidence, and action boundary before the answer is used." } ], "example_card": { "question_id": "topology-005", "domain": "distributed_capacity_topology", "question": "What review capacity must exist before adding distributed contributors?", "doctrine_answer": "Additional contributors increase throughput only when review capacity, architecture authority, and approval paths can absorb the added work. If review is the constraint, more contributors create more queue time.", "evidence_summary": "Synthetic example: PR review queue age is above 36 hours for platform services, correction rate is rising, and reviewer availability is concentrated in two senior engineers.", "observed_state": "directional", "confidence": "medium", "source_classes": [ "pull request metadata", "review queue age", "service ownership map", "deployment metadata" ], "missing_evidence": [ "reviewer calendar load", "architecture decision latency", "post-merge defect trend" ], "risk_flags": [ "review_bottleneck", "architecture_authority_constraint" ], "recommended_report_section": "Capacity Topology Readiness Report", "next_safe_action": "Measure reviewer availability, PR correction rate, approval latency, and service ownership coverage for 30 days before adding distributed contributors.", "do_not_collect": [ "source code", "secrets", "customer data", "raw private messages", "individual employee performance records" ] } }, "workflow_report_system": { "title": "Workflow Report System", "purpose": "The report system converts answer cards into executive operating reports. A report should tell a CTO, CIO, or VP Engineering what the system is doing, what evidence supports that view, where confidence is weak, and what can be changed safely.", "report_contract": { "required_sections": [ "Operating decision", "Evidence boundary", "Answer cards", "System diagnosis", "Confidence table", "Missing instrumentation", "Risk register", "Recommended next safe actions", "Human approval and rollback boundary" ], "forbidden_sections": [ "Raw source code", "Secrets or credentials", "Customer records", "Private employee records", "Unredacted logs", "Payroll, legal, or health data", "Forced recommendation without evidence" ] }, "report_types": [ { "id": "engineering_capacity_os_diagnostic", "title": "Engineering Capacity OS Diagnostic", "use_for": "Executive view of capacity, topology, telemetry, governance, and AI readiness.", "primary_domains": [ "capacity_intelligence", "decision_grade_telemetry", "governance_security_failure_modes" ], "output_questions": [ "What is the actual constraint?", "What evidence supports that conclusion?", "Can the system absorb more capacity?", "Where is instrumentation missing?" ] }, { "id": "capacity_topology_readiness_report", "title": "Capacity Topology Readiness Report", "use_for": "Decision support for internal hiring, distributed teams, external partners, nearshore, offshore, platform investment, or agentic workflows.", "primary_domains": [ "distributed_capacity_topology", "knowledge_architecture_memory", "execution_harness" ], "output_questions": [ "Which workstreams are distributable?", "Which workstreams should remain internally owned?", "What controls must exist before the topology changes?", "Where would the model create hidden risk?" ] }, { "id": "agentic_sdlc_readiness_report", "title": "Agentic SDLC Readiness Report", "use_for": "Assessment of which engineering workflows can be safely delegated to agents.", "primary_domains": [ "governed_agentic_sdlc", "governed_adaptive_control_loops", "governance_security_failure_modes" ], "output_questions": [ "Which tasks are safe for agent assistance?", "Where is human judgment still required?", "What telemetry proves agents are helping?", "What approval, audit, and rollback controls are required?" ] }, { "id": "execution_control_plane_report", "title": "Execution Control Plane Report", "use_for": "Review of CI/CD, deployment, environment, rollback, quality-gate, and workflow determinism.", "primary_domains": [ "execution_harness", "decision_grade_telemetry", "governance_security_failure_modes" ], "output_questions": [ "Where does execution variance enter the SDLC?", "Which controls are manually enforced?", "Which controls are system-enforced?", "How reproducible are deployments across environments?" ] } ] }, "formula_registry": { "title": "Engineering Capacity OS Formula Registry", "version": "1.1", "schema_version": "1.0.0", "status": "public_research_registry", "purpose": "Map published TeamStation Engineering Doctrine formulas and algorithmic concepts to Engineering Capacity OS research questions, private MCP evidence, answer cards, and workflow reports.", "privacy_boundary": "The public registry defines formulas, evidence requirements, and interpretation rules. Customer source code, secrets, raw logs, customer records, payroll data, legal records, and employee-level performance records stay inside the organization.", "how_to_use": [ "Select the operating problem and matching research question.", "Find the related formula or algorithmic concept in this registry.", "Retrieve only aggregate or redacted evidence from approved internal systems.", "Apply the interpretation rules to create answer cards with observed state, confidence, missing evidence, risk flags, and next safe action.", "Do not treat a formula as a private scoring engine unless the required evidence is present and source-cited." ], "formula_registry": [ { "id": "engineering_performance_function", "label": "Engineering Performance Function", "formula_type": "system_function", "doctrine_source": { "route": "/research/engineering-operating-system/", "file": "data/research/engineering-os.json", "title": "Engineering Capacity Operating System" }, "formula": "P(t)=f(C,T,K,D,O,A,L,G) -> {Speed, Quality, Cost, Risk, Value}", "plain_language": "Engineering performance at time t is a system output, not a headcount output. It depends on capacity, topology, knowledge, execution, telemetry, agentic action, adaptive learning, and governance.", "diagnostic_use": "Use this as the top-level dependency map for every Engineering Capacity OS report.", "related_domains": [ "capacity_intelligence", "distributed_capacity_topology", "knowledge_architecture_memory", "execution_harness", "decision_grade_telemetry", "governed_agentic_sdlc", "governed_adaptive_control_loops", "governance_security_failure_modes" ], "related_question_ids": [ "capacity-001", "topology-003", "knowledge-001", "execution-001", "telemetry-001", "agent-001", "adaptive-001", "gov-006" ], "required_signals": [ "committed work", "completed work", "review queue age", "cycle time", "deployment success", "incident interruption load", "ownership map", "approval path", "rollback evidence" ], "mcp_source_categories": [ "work tracker", "source control", "pull request system", "CI/CD system", "incident system", "architecture catalog", "telemetry platform", "policy system" ], "interpretation_rules": [ "If speed improves while quality, cost, risk, or value degrade, the system did not improve.", "If one variable is unknown, mark the answer as partial rather than forcing a recommendation.", "If governance evidence is missing, do not recommend capacity expansion or autonomous workflow changes." ], "answer_card_fields": [ "observed_state", "evidence_summary", "confidence", "missing_evidence", "risk_flags", "next_safe_action" ], "report_sections": [ "Executive Summary", "System Function Map", "Risk Boundary", "Next Safe Action" ], "maturity": "research_hypothesis", "validation_status": "conceptual_dependency_map_not_calibrated", "assumptions": [ "Each input is defined independently before use.", "Outputs are evaluated together rather than optimized in isolation." ], "units": "No common unit. Inputs and outputs require separate operational measures.", "limitations": [ "This function states dependency, not magnitude or causality.", "It cannot predict performance until variables, interactions, and calibration data are specified." ] }, { "id": "sequential_probability_network", "label": "Sequential Probability Network", "formula_type": "probability_model", "doctrine_source": { "route": "/teams/", "file": "data/teams/overview.ts", "title": "Pillar I: On Teams" }, "formula": "P = product(p_i) for i=1..n", "plain_language": "In a sequential engineering chain, the probability of system success is multiplied across nodes. One weak upstream node can cap the entire downstream system.", "diagnostic_use": "Use this to test whether adding capacity will improve throughput or only add more weak links to a fragile chain.", "related_domains": [ "capacity_intelligence", "distributed_capacity_topology", "knowledge_architecture_memory", "execution_harness" ], "related_question_ids": [ "capacity-002", "capacity-005", "topology-001", "topology-006", "knowledge-003", "execution-010" ], "required_signals": [ "workstream sequence", "handoff count", "blocked work", "dependency wait", "review queue age", "rework by upstream source", "deployment dependency map" ], "mcp_source_categories": [ "work tracker", "pull request system", "architecture catalog", "service registry", "CI/CD system" ], "interpretation_rules": [ "If success depends on a long chain of handoffs, capacity should be modeled as chain reliability, not seat count.", "If downstream teams are waiting on ambiguous upstream output, adding downstream contributors will not repair the constraint.", "If one service or role caps the sequence, report it as the probability ceiling." ], "answer_card_fields": [ "chain_map", "constraint_node", "dependency_wait", "confidence", "missing_evidence" ], "report_sections": [ "Capacity Constraint Map", "Topology Readiness", "Execution Failure Modes" ], "maturity": "derived_model", "validation_status": "valid_under_explicit_probability_chain_assumptions", "assumptions": [ "Node probabilities are independent, or are explicitly defined as conditional probabilities in sequence.", "Success requires every modeled node to succeed." ], "units": "Dimensionless probability from 0 to 1.", "limitations": [ "A simple product is invalid for correlated unconditional probabilities.", "Parallel paths, retries, and partial success require a richer reliability model." ] }, { "id": "strict_complementarity", "label": "Strict Complementarity", "formula_type": "economic_constraint", "doctrine_source": { "route": "/teams/sequential-probability-networks/", "file": "data/teams/sequential.ts", "title": "The Sequential Pipeline Reality" }, "formula": "p_{k+2} - p_{k+1} > p_{k+1} - p_k", "plain_language": "Improving one node creates more value when the rest of the chain is already strong. Strong people at the wrong point in a broken chain can be wasted.", "diagnostic_use": "Use this to decide whether the system needs stronger upstream architecture, better review capacity, or fewer handoffs before adding contributors.", "related_domains": [ "capacity_intelligence", "distributed_capacity_topology", "knowledge_architecture_memory" ], "related_question_ids": [ "capacity-004", "capacity-007", "topology-002", "topology-005", "knowledge-004", "knowledge-008" ], "required_signals": [ "senior review dependency", "architecture decision age", "rework by reviewer", "handoff failure", "critical knowledge ownership" ], "mcp_source_categories": [ "pull request system", "architecture decision records", "work tracker", "engineering review records" ], "interpretation_rules": [ "If senior review is the scarce multiplier, adding contributors increases queues unless review capacity changes.", "If architecture decisions are stale or missing, downstream delivery probability is capped.", "If high-skill nodes are placed after weak upstream inputs, report wasted capacity risk." ], "answer_card_fields": [ "pivotal_node", "upstream_quality_signal", "downstream_blockage", "risk_flags" ], "report_sections": [ "Capacity Constraint Map", "Knowledge and Ownership Risk" ], "maturity": "research_hypothesis", "validation_status": "testable_inequality_not_empirically_calibrated", "assumptions": [ "The ordered probability terms measure comparable outcomes under comparable conditions.", "The node index represents a meaningful sequence." ], "units": "Difference between dimensionless probabilities.", "limitations": [ "The inequality is a proposed diagnostic condition, not a universal law.", "Observed complementarity can be confounded by role, work type, or measurement window." ] }, { "id": "shirking_margin_zeta", "label": "Shirking Margin", "formula_type": "incentive_model", "doctrine_source": { "route": "/teams/ai-incentive-structure/", "file": "data/teams/incentives.ts", "title": "The Incentive Structure" }, "formula": "zeta_i^x = P(project succeeds | e_i=0, policy x)", "plain_language": "Zeta measures how safe a contributor feels when they do not apply full effort. If the system hides weak effort behind downstream rescue, incentive quality degrades.", "diagnostic_use": "Use this to test whether AI, QA, senior rescue, or vendor buffering is hiding low-quality upstream work.", "related_domains": [ "capacity_intelligence", "governed_agentic_sdlc", "governance_security_failure_modes" ], "related_question_ids": [ "capacity-006", "agent-004", "agent-005", "agent-006", "gov-001", "gov-006" ], "required_signals": [ "review correction rate", "reopened work", "QA rescue count", "senior rescue count", "agent-generated rework", "approval override history" ], "mcp_source_categories": [ "pull request system", "test system", "incident system", "work tracker", "agent audit logs" ], "interpretation_rules": [ "If downstream rescue repeatedly masks upstream defects, do not treat delivered work as healthy capacity.", "If agent output lowers effort discipline, require stronger validation and ownership boundaries.", "If responsibility is unclear, classify the risk as governance failure before capacity failure." ], "answer_card_fields": [ "rescue_pattern", "quality_escape", "owner_boundary", "confidence" ], "report_sections": [ "Agentic Workflow Control Report", "Governance and Risk Boundary" ], "maturity": "derived_model", "validation_status": "principal_agent_model_requires_local_estimation", "assumptions": [ "Effort state and project success are defined for the same policy and time window.", "The probability can be estimated without exposing individual private records." ], "units": "Dimensionless probability from 0 to 1.", "limitations": [ "The construct is not directly observable and requires a defensible proxy.", "Do not infer individual intent from aggregate delivery outcomes." ] }, { "id": "incentive_compatibility_constraint", "label": "Incentive Compatibility Constraint", "formula_type": "incentive_model", "doctrine_source": { "route": "/teams/ai-incentive-structure/", "file": "data/teams/incentives.ts", "title": "The Incentive Structure" }, "formula": "p_n * w_i - c >= zeta_i^x * w_i", "plain_language": "A contributor exerts effort when the expected value of working is greater than the expected value of shirking.", "diagnostic_use": "Use this as a qualitative operating model for effort, friction, unclear ownership, time-zone delay, and downstream safety nets.", "related_domains": [ "capacity_intelligence", "distributed_capacity_topology", "governance_security_failure_modes" ], "related_question_ids": [ "capacity-003", "topology-004", "topology-009", "gov-001", "gov-006" ], "required_signals": [ "decision latency", "blocked time", "handoff delay", "context switching", "work ownership", "review accountability" ], "mcp_source_categories": [ "work tracker", "calendar metadata if approved and aggregated", "pull request system", "decision records" ], "interpretation_rules": [ "If coordination cost is high, effort drops even when people are busy.", "If ownership is unclear, activity signals are not evidence of productive effort.", "If downstream teams constantly catch upstream issues, the incentive model is distorted." ], "answer_card_fields": [ "effort_friction", "blocked_time", "ownership_gap", "next_safe_action" ], "report_sections": [ "Capacity Constraint Map", "Topology Readiness" ], "maturity": "derived_model", "validation_status": "algebraically_defined_under_principal_agent_assumptions", "assumptions": [ "The wage is outcome contingent.", "Effort cost and success probabilities are expressed on compatible expected-value terms.", "The decision maker is modeled as risk neutral for this simplified constraint." ], "units": "Expected currency on both sides of the inequality.", "limitations": [ "Risk aversion, multi-period incentives, and non-monetary utility are omitted.", "The model must not be used as an individual compensation decision without additional evidence." ] }, { "id": "wage_equation", "label": "Wage Equation", "formula_type": "economic_model", "doctrine_source": { "route": "/teams/ai-incentive-structure/", "file": "data/teams/incentives.ts", "title": "The Incentive Structure" }, "formula": "w_i^x = c / (p_n - zeta_i^x)", "plain_language": "As the incentive margin shrinks, the cost required to sustain high effort rises.", "diagnostic_use": "Use this to explain why cheap capacity can become expensive when coordination friction, review drag, and rescue work rise.", "related_domains": [ "capacity_intelligence", "distributed_capacity_topology", "decision_grade_telemetry" ], "related_question_ids": [ "capacity-008", "topology-003", "telemetry-002", "telemetry-006" ], "required_signals": [ "cycle time", "review drag", "rework rate", "defect escape", "incident load", "coordination delay", "topology cost" ], "mcp_source_categories": [ "work tracker", "pull request system", "incident system", "finance or planning summaries if approved" ], "interpretation_rules": [ "If low-cost capacity creates high review drag, the system cost is not low.", "If the evidence does not include rework and delay, do not make a cost claim.", "If capacity topology changes reduce friction, treat the gain as operating leverage." ], "answer_card_fields": [ "cost_driver", "delay_driver", "rework_driver", "evidence_gap" ], "report_sections": [ "Cost, Value, and Risk Economics", "Topology Readiness" ], "maturity": "derived_model", "validation_status": "algebraic_solution_requires_positive_probability_margin", "assumptions": [ "p_n is greater than zeta_i^x.", "The incentive compatibility assumptions hold.", "Cost and wage use the same currency and period." ], "units": "Currency per modeled outcome period.", "limitations": [ "The equation is undefined when p_n equals zeta_i^x and unstable when the margin is close to zero.", "It is a theoretical boundary, not a market wage recommendation." ] }, { "id": "replacement_kinetics_derivative", "label": "Replacement Kinetics Derivative", "formula_type": "agentic_automation_model", "doctrine_source": { "route": "/teams/replacement-kinetics/", "file": "data/teams/kinetics.ts", "title": "Replacement Kinetics" }, "formula": "partial C / partial x_i = Direct Savings - Incentive Distortion", "plain_language": "Replacing or automating a position creates direct savings only if it does not distort incentives and coordination around the rest of the chain.", "diagnostic_use": "Use this to decide whether AI should automate a workflow, augment it, or stay outside the approval path.", "related_domains": [ "governed_agentic_sdlc", "governed_adaptive_control_loops", "governance_security_failure_modes" ], "related_question_ids": [ "agent-001", "agent-002", "agent-006", "adaptive-002", "gov-002", "gov-006" ], "required_signals": [ "workflow step position", "blast radius", "human approval path", "agent error rate", "review correction rate", "rollback evidence" ], "mcp_source_categories": [ "agent audit logs", "pull request system", "CI/CD system", "policy system", "incident system" ], "interpretation_rules": [ "End-of-chain validation tasks are more automation tolerant than middle-of-chain architecture decisions.", "If automation removes a human signal needed by other contributors, classify it as protected or human-gated.", "If rollback is missing, do not mark the workflow as safe for adaptive change." ], "answer_card_fields": [ "workflow_position", "automation_class", "blast_radius", "rollback_path" ], "report_sections": [ "Agentic Workflow Control Report", "Governed Adaptive Control Loop Report" ], "maturity": "research_hypothesis", "validation_status": "directional_decomposition_not_calibrated", "assumptions": [ "Direct savings and incentive distortion are measured in the same currency and period.", "Cross-effects on quality, queues, knowledge, and risk are included in incentive distortion." ], "units": "Currency change per unit change in replacement exposure.", "limitations": [ "Omitted cross-effects can reverse the sign.", "The expression does not prove that replacement creates savings." ] }, { "id": "kingman_wait_time", "label": "Kingman Wait Time Approximation", "formula_type": "queueing_model", "doctrine_source": { "route": "/work/", "file": "data/work/overview.ts", "title": "Pillar II: On Work" }, "formula": "E[W_q] approx (rho / (1-rho)) * ((C_a^2 + C_s^2) / 2) * tau", "plain_language": "As utilization approaches 100 percent, wait time explodes. Variance makes the queue worse.", "diagnostic_use": "Use this to test whether a team is actually capacity constrained or queue constrained.", "related_domains": [ "capacity_intelligence", "execution_harness", "decision_grade_telemetry" ], "related_question_ids": [ "capacity-001", "capacity-003", "capacity-005", "execution-010", "telemetry-004", "telemetry-006" ], "required_signals": [ "utilization proxy", "active WIP", "queue age", "cycle time", "arrival variability", "service-time variability", "blocked work" ], "mcp_source_categories": [ "work tracker", "pull request system", "CI/CD system", "incident system" ], "interpretation_rules": [ "If utilization is high and queue age is rising, adding more work will worsen delivery.", "If task-size variance is high, normalize work before scaling capacity.", "If queue data is missing, mark telemetry as insufficient for capacity decisions." ], "answer_card_fields": [ "queue_age", "wip_level", "cycle_time_variance", "capacity_risk" ], "report_sections": [ "Capacity Constraint Map", "Telemetry Trust Report" ], "maturity": "established_model", "validation_status": "established_queueing_approximation", "assumptions": [ "Single-server GI/G/1 approximation.", "Arrival and service processes are stable and utilization is below 1.", "Mean and variability estimates use a representative window." ], "units": "Time in the same unit as mean service time tau.", "limitations": [ "Delay grows nonlinearly as utilization approaches 1; no universal 80 percent infinity threshold exists.", "Multi-server, priority, batching, and network queues require other models." ] }, { "id": "little_law", "label": "Little's Law", "formula_type": "flow_model", "doctrine_source": { "route": "/work/code-inventory-axioms/", "file": "data/work/axioms.ts", "title": "Inventory Liability, Little's Law, and The Kingman Invariant" }, "formula": "L = lambda * W", "plain_language": "Average work in progress equals throughput multiplied by time in system.", "diagnostic_use": "Use this to show why more active work can increase lead time even when people look busy.", "related_domains": [ "capacity_intelligence", "execution_harness", "decision_grade_telemetry" ], "related_question_ids": [ "capacity-003", "execution-008", "telemetry-002", "telemetry-004" ], "required_signals": [ "active WIP", "throughput", "lead time", "cycle time", "work item aging" ], "mcp_source_categories": [ "work tracker", "pull request system" ], "interpretation_rules": [ "If WIP rises faster than throughput, lead time must rise.", "If throughput is flat and work starts increase, the system is manufacturing delay.", "If WIP is not measured, do not claim the team has usable spare capacity." ], "answer_card_fields": [ "wip_level", "throughput", "lead_time", "queue_risk" ], "report_sections": [ "Capacity Constraint Map", "Execution Control Report" ], "maturity": "established_model", "validation_status": "established_flow_conservation_identity", "assumptions": [ "The observed system is stable over the measurement window.", "WIP, throughput, and time share the same boundary and population." ], "units": "Items = items per unit time multiplied by time.", "limitations": [ "Little's Law does not identify the cause of delay.", "Mixed work classes require segmentation before interpretation." ] }, { "id": "wip_rule_of_two", "label": "Rule of Two WIP Constraint", "formula_type": "operating_constraint", "doctrine_source": { "route": "/work/wip-regulation/", "file": "data/work/regulation.ts", "title": "Regulation: Enforceable Constraints" }, "formula": "WIP_person <= 2", "plain_language": "A contributor should not carry unlimited active work. Too much WIP hides blocked flow and destroys feedback.", "diagnostic_use": "Use this to identify false capacity created by multitasking and fragmented ownership.", "related_domains": [ "capacity_intelligence", "execution_harness" ], "related_question_ids": [ "capacity-003", "capacity-005", "execution-003", "execution-007" ], "required_signals": [ "active items per contributor", "work state aging", "blocked items", "handoff count", "review waiting time" ], "mcp_source_categories": [ "work tracker", "pull request system" ], "interpretation_rules": [ "If contributors carry more active work than the operating limit, treat capacity as fragmented.", "If blocked work causes new work starts, the system is optimizing busyness over delivery.", "If the tracker cannot show WIP by contributor or workstream, mark telemetry incomplete." ], "answer_card_fields": [ "active_wip", "fragmentation_risk", "blocked_work", "next_safe_action" ], "report_sections": [ "Capacity Constraint Map", "Execution Control Report" ], "maturity": "operating_heuristic", "validation_status": "policy_threshold_requires_local_experiment", "assumptions": [ "Active work is defined consistently.", "Expedite and incident work are accounted for separately." ], "units": "Active work items per person.", "limitations": [ "Two is a proposed control limit, not a mathematical law.", "The useful threshold varies by work type, role, and queue design." ] }, { "id": "cost_of_delay", "label": "Cost of Delay", "formula_type": "economic_model", "doctrine_source": { "route": "/work/cost-of-delay-economics/", "file": "data/work/economics.ts", "title": "Economics of Work" }, "formula": "CoD = dV_lost / dt = -dV_remaining / dt", "plain_language": "Cost of delay is the rate at which waiting destroys remaining value or accumulates lost value. The sign convention must be stated before comparing work.", "diagnostic_use": "Use this to prioritize work by time-sensitive value rather than loudness, politics, or activity volume.", "related_domains": [ "capacity_intelligence", "distributed_capacity_topology", "decision_grade_telemetry" ], "related_question_ids": [ "capacity-008", "topology-003", "telemetry-002", "telemetry-008" ], "required_signals": [ "business milestone", "work age", "expected value", "cycle time", "blocked dependency", "release date movement" ], "mcp_source_categories": [ "product roadmap", "work tracker", "release management", "finance or planning summaries if approved" ], "interpretation_rules": [ "If business value is time-sensitive, queue age becomes economic loss.", "If work priority lacks value and time basis, do not treat priority labels as evidence.", "If telemetry cannot connect work to outcome, report missing value instrumentation." ], "answer_card_fields": [ "value_at_risk", "time_sensitivity", "blocked_dependency", "confidence" ], "report_sections": [ "Cost, Value, and Risk Economics", "Executive Summary" ], "maturity": "derived_model", "validation_status": "economic_rate_definition_requires_value_model", "assumptions": [ "Value loss is estimated over a defined decision horizon.", "The value model includes relevant revenue, risk, cost, or mission impact." ], "units": "Currency or value units per unit time.", "limitations": [ "The derivative is only as credible as the value model.", "Use scenarios or intervals when value is uncertain." ] }, { "id": "dependency_density", "label": "Dependency Density", "formula_type": "graph_model", "doctrine_source": { "route": "/integration/dependency-density/", "file": "data/integration/dependency.ts", "title": "Dependency Density and Gall's Law" }, "formula": "E_max = N(N-1)/2; D = E/E_max", "plain_language": "A system with N nodes can contain at most N(N-1)/2 undirected pairwise dependencies. Actual dependency density is the observed edge count divided by that bound.", "diagnostic_use": "Use this to test whether team, service, or vendor topology is creating integration cost faster than delivery value.", "related_domains": [ "distributed_capacity_topology", "knowledge_architecture_memory", "governance_security_failure_modes" ], "related_question_ids": [ "topology-003", "topology-006", "knowledge-003", "knowledge-006", "gov-006" ], "required_signals": [ "service count", "team count", "interface count", "cross-service changes", "owner map", "dependency incidents" ], "mcp_source_categories": [ "service registry", "architecture catalog", "source control", "incident system", "work tracker" ], "interpretation_rules": [ "If dependency count grows without ownership clarity, integration risk rises.", "If service boundaries exist only on diagrams and not in code or deployment independence, classify as distributed monolith risk.", "If dependency evidence is missing, do not recommend distributed ownership." ], "answer_card_fields": [ "dependency_map", "owner_map", "integration_risk", "missing_evidence" ], "report_sections": [ "Topology Readiness", "Failure Mode Register" ], "maturity": "established_model", "validation_status": "established_complete_graph_bound_with_derived_density", "assumptions": [ "Dependencies are represented as undirected pairwise edges for the bound.", "N counts comparable system nodes and E counts observed edges within the same boundary." ], "units": "Edge count for E_max; dimensionless ratio for D.", "limitations": [ "N(N-1)/2 is the maximum possible edge count, not actual complexity.", "Directed, weighted, higher-order, and dynamic dependencies need richer graph measures." ] }, { "id": "synchronization_penalty", "label": "Synchronization Penalty", "formula_type": "distributed_work_model", "doctrine_source": { "route": "/integration/asynchronous-amplifier/", "file": "data/integration/async.ts", "title": "The Asynchronous Amplifier" }, "formula": "S_p = sum(T_wait + T_context_switch)", "plain_language": "Distributed work pays a penalty whenever waiting time and context switching replace direct feedback.", "diagnostic_use": "Use this to measure whether time-zone overlap, unclear ownership, or missing self-serve context is slowing the SDLC.", "related_domains": [ "distributed_capacity_topology", "capacity_intelligence", "decision_grade_telemetry" ], "related_question_ids": [ "topology-004", "topology-009", "capacity-003", "telemetry-003", "telemetry-004" ], "required_signals": [ "wait time", "handoff delay", "blocked comments", "review latency", "time-zone overlap", "context switch count" ], "mcp_source_categories": [ "work tracker", "pull request system", "calendar metadata if approved and aggregated", "engineering chat summaries if approved and redacted" ], "interpretation_rules": [ "If wait time is caused by missing context, add documentation or ownership before adding people.", "If time-zone overlap materially affects cycle time, topology choice must include overlap as a constraint.", "If context switching is unmeasured, report capacity as partially unknown." ], "answer_card_fields": [ "wait_time", "context_switching", "topology_constraint", "confidence" ], "report_sections": [ "Topology Readiness", "Capacity Constraint Map" ], "maturity": "operating_heuristic", "validation_status": "measurement_definition_requires_local_baseline", "assumptions": [ "Wait time and context-switch time are measured in the same time unit.", "Only avoidable synchronization costs are included." ], "units": "Person-hours or another declared time unit.", "limitations": [ "The sum does not capture quality loss or delayed learning unless those effects are measured separately.", "Attribution requires a defined workflow boundary." ] }, { "id": "availability_mttr", "label": "Availability and MTTR", "formula_type": "reliability_model", "doctrine_source": { "route": "/failure/recovery-metrics/", "file": "data/failure/metrics.ts", "title": "Recovery Metrics" }, "formula": "A = MTBF / (MTBF + MTTR)", "plain_language": "Availability improves when recovery time drops. Modern software systems should optimize fast recovery, not frozen change.", "diagnostic_use": "Use this to test whether engineering governance improves recovery or only slows delivery.", "related_domains": [ "execution_harness", "decision_grade_telemetry", "governance_security_failure_modes" ], "related_question_ids": [ "execution-004", "execution-005", "telemetry-005", "gov-002", "gov-006" ], "required_signals": [ "deployment frequency", "change failure rate", "MTTR", "rollback duration", "incident detection time", "incident diagnosis time" ], "mcp_source_categories": [ "CI/CD system", "incident system", "observability platform", "change management" ], "interpretation_rules": [ "If rollback is slow, execution governance is not production-grade.", "If MTTR improves while deployment frequency improves, governance is enabling flow.", "If incident data is missing, do not make reliability claims." ], "answer_card_fields": [ "mttr", "rollback_time", "change_failure_rate", "governance_gap" ], "report_sections": [ "Execution Control Report", "Governance and Failure Mode Register" ], "maturity": "established_model", "validation_status": "established_steady_state_availability_model", "assumptions": [ "Failure and repair cycles are represented by stable mean times.", "The service boundary and failure definition are consistent." ], "units": "Dimensionless ratio from 0 to 1.", "limitations": [ "Mean values hide tail risk and correlated failures.", "User-perceived availability can differ from component availability." ] }, { "id": "mttr_limit_behavior", "label": "MTTR Limit Behavior", "formula_type": "reliability_model", "doctrine_source": { "route": "/failure/recovery-metrics/", "file": "data/failure/metrics.ts", "title": "Recovery Metrics" }, "formula": "lim_{MTTR -> 0} MTBF / (MTBF + MTTR) = 1", "plain_language": "As recovery time approaches zero, availability approaches one even when failures still happen.", "diagnostic_use": "Use this to evaluate rollback, feature flags, observability, and authority delegation.", "related_domains": [ "execution_harness", "decision_grade_telemetry", "governance_security_failure_modes" ], "related_question_ids": [ "execution-003", "execution-004", "telemetry-003", "telemetry-005", "gov-002" ], "required_signals": [ "rollback path", "feature flag coverage", "incident time to mitigation", "approval latency", "audit record" ], "mcp_source_categories": [ "CI/CD system", "feature flag system", "incident system", "policy system" ], "interpretation_rules": [ "If mitigation requires manual escalation, MTTR is governed by authority latency, not tooling.", "If deployment and release are not separated, rollback risk is higher.", "If feature flags lack ownership and audit, they are not sufficient governance." ], "answer_card_fields": [ "mitigation_time", "approval_latency", "rollback_authority", "auditability" ], "report_sections": [ "Execution Control Report", "Governance and Risk Boundary" ], "maturity": "derived_model", "validation_status": "algebraic_limit_of_availability_model", "assumptions": [ "MTBF remains positive and finite as MTTR approaches zero." ], "units": "Dimensionless ratio.", "limitations": [ "The limit does not imply zero operational recovery cost.", "Detection, rollback, and data repair can remain material even when service restoration is fast." ] }, { "id": "mutation_score", "label": "Mutation Score", "formula_type": "quality_model", "doctrine_source": { "route": "/quality/blameless-quality-protocols/", "file": "data/quality/regulation.ts", "title": "Regulation: Blameless Science" }, "formula": "MS = K / (T - E)", "plain_language": "Test quality is measured by whether tests kill injected faults, not whether lines were merely executed.", "diagnostic_use": "Use this to test whether quality telemetry is meaningful enough to trust AI-generated or distributed engineering output.", "related_domains": [ "decision_grade_telemetry", "governed_agentic_sdlc", "execution_harness" ], "related_question_ids": [ "telemetry-005", "agent-002", "agent-004", "execution-009" ], "required_signals": [ "test coverage", "mutation score if available", "failed tests", "escaped defects", "review correction rate", "reverts" ], "mcp_source_categories": [ "test system", "CI/CD system", "pull request system", "incident system" ], "interpretation_rules": [ "If tests do not catch injected or known defect classes, do not trust automation output.", "If quality telemetry is limited to coverage percentage, mark telemetry as weak.", "If AI-generated code bypasses mutation or regression checks, require human gating." ], "answer_card_fields": [ "test_strength", "defect_signal", "ai_validation_boundary", "confidence" ], "report_sections": [ "Telemetry Trust Report", "Agentic Workflow Control Report" ], "maturity": "established_model", "validation_status": "established_software_testing_metric", "assumptions": [ "Equivalent mutants are excluded or estimated consistently.", "Killed and total mutants are generated under a documented operator set." ], "units": "Dimensionless ratio or percentage.", "limitations": [ "Mutation score measures test sensitivity to injected changes, not complete product quality.", "Operator quality and equivalent-mutant handling affect comparability." ] }, { "id": "cognitive_fidelity", "label": "Cognitive Fidelity", "formula_type": "cognitive_model", "doctrine_source": { "route": "/quality/", "file": "data/quality/overview.ts", "title": "Pillar IV: On Quality" }, "formula": "Quality ~ isomorphism(M_e, S_sys)", "plain_language": "Quality depends on how closely an engineer's mental model matches the actual system state.", "diagnostic_use": "Use this to evaluate whether ownership, documentation, and review systems keep human and agent contributors aligned with reality.", "related_domains": [ "knowledge_architecture_memory", "governed_agentic_sdlc", "decision_grade_telemetry" ], "related_question_ids": [ "knowledge-001", "knowledge-004", "knowledge-006", "agent-002", "agent-006", "telemetry-005" ], "required_signals": [ "architecture decision records", "documentation usage", "review comments", "rework caused by misunderstanding", "incident root cause", "agent correction rate" ], "mcp_source_categories": [ "architecture catalog", "documentation system", "pull request system", "incident system", "agent audit logs" ], "interpretation_rules": [ "If contributors act on stale or missing system knowledge, delivery failures are knowledge failures before people failures.", "If AI outputs are correct syntactically but wrong semantically, classify the workflow as human-gated.", "If incidents repeat because lessons are not stored, knowledge memory is broken." ], "answer_card_fields": [ "knowledge_gap", "mental_model_drift", "review_signal", "durable_memory_action" ], "report_sections": [ "Knowledge and Ownership Risk", "Agentic Workflow Control Report" ], "maturity": "research_hypothesis", "validation_status": "construct_requires_operational_definition_and_replication", "assumptions": [ "Mental-model and system-state representations can be defined and compared.", "The comparison does not use protected traits as quality proxies." ], "units": "Undefined until the isomorphism or similarity measure is operationalized.", "limitations": [ "The expression is conceptual and cannot be scored without a validated measurement instrument.", "Similarity does not by itself prove causal engineering judgment." ] }, { "id": "l2_adjusted_score", "label": "L2 Adjusted Communication Score", "formula_type": "fairness_model", "doctrine_source": { "route": "/quality/", "file": "data/quality/overview.ts", "title": "Pillar IV: On Quality" }, "formula": "s_adj = s_raw - beta * (f_error - E[f | P])", "plain_language": "Language form errors should not be allowed to erase correct technical reasoning.", "diagnostic_use": "Use this as a public doctrine mapping for fair evaluation of distributed contributors, not as a public scoring engine.", "related_domains": [ "capacity_intelligence", "distributed_capacity_topology", "governance_security_failure_modes" ], "related_question_ids": [ "capacity-007", "topology-008", "knowledge-008", "gov-004" ], "required_signals": [ "evaluation rubric", "technical reasoning evidence", "communication context", "review calibration", "bias control record" ], "mcp_source_categories": [ "approved evaluation records", "calibration records", "governance policy" ], "interpretation_rules": [ "Do not use accent or grammar as a proxy for engineering capability.", "Separate reasoning quality from language surface form.", "Do not expose individual evaluation records through the public research workflow." ], "answer_card_fields": [ "evaluation_boundary", "calibration_evidence", "bias_control", "confidence" ], "report_sections": [ "Governance and Risk Boundary", "Capacity Topology Readiness" ], "maturity": "derived_model", "validation_status": "statistical_adjustment_requires_calibration_and_fairness_audit", "assumptions": [ "Form error is measured separately from engineering content.", "Beta and the conditional expectation are estimated on representative data." ], "units": "Same standardized score unit as s_raw.", "limitations": [ "Adjustment can introduce bias when the conditioning model is misspecified.", "Report raw and adjusted scores with uncertainty and subgroup diagnostics." ] }, { "id": "frechet_semantic_distance", "label": "Frechet Semantic Distance", "formula_type": "semantic_fidelity_model", "doctrine_source": { "route": "/decisions/axiom-cortex-engine/", "file": "data/cortex.ts", "title": "Axiom Cortex" }, "formula": "FSD(y_q,b_q)=||mu_y-mu_b||_2^2 + Tr(Sigma_y + Sigma_b - 2(Sigma_y^(1/2) Sigma_b Sigma_y^(1/2))^(1/2))", "plain_language": "Semantic similarity should be measured by meaning, not surface phrasing.", "diagnostic_use": "Use this as a public doctrine reference for semantic matching and technical reasoning fidelity.", "related_domains": [ "knowledge_architecture_memory", "capacity_intelligence", "governance_security_failure_modes" ], "related_question_ids": [ "knowledge-005", "knowledge-008", "capacity-007", "gov-004" ], "required_signals": [ "approved rubric", "ideal answer blueprint", "semantic content evidence", "calibration record" ], "mcp_source_categories": [ "approved evaluation records", "knowledge base", "governance policy" ], "interpretation_rules": [ "Use semantic equivalence only inside approved evaluation or knowledge systems.", "Do not publish private transcript data or proprietary scoring parameters.", "If calibration evidence is missing, mark the semantic claim as unsupported." ], "answer_card_fields": [ "semantic_match_boundary", "calibration_status", "source_class", "missing_evidence" ], "report_sections": [ "Knowledge and Ownership Risk", "Governance and Risk Boundary" ], "maturity": "derived_model", "validation_status": "adapted_distribution_distance_requires_construct_validation", "assumptions": [ "Embedding distributions are adequately summarized by means and covariances.", "Compared samples use the same embedding model and preprocessing." ], "units": "Squared embedding-space distance.", "limitations": [ "The Gaussian approximation may be poor.", "Distance in embedding space is not direct proof of engineering quality or equivalence." ] }, { "id": "optimal_transport_code_switch", "label": "Optimal Transport With Code Switch Awareness", "formula_type": "semantic_fidelity_model", "doctrine_source": { "route": "/decisions/axiom-cortex-engine/", "file": "data/cortex.ts", "title": "Axiom Cortex" }, "formula": "s_q^OT = psi(W_2(P_q,Q_q; C o (1 - lambda M)))", "plain_language": "Code switching should not be treated as technical weakness when meaning is preserved.", "diagnostic_use": "Use this as public governance language for fair interpretation of multilingual technical reasoning.", "related_domains": [ "capacity_intelligence", "governance_security_failure_modes" ], "related_question_ids": [ "capacity-007", "knowledge-008", "gov-004" ], "required_signals": [ "language context", "semantic content", "evaluation calibration", "bias review" ], "mcp_source_categories": [ "approved evaluation records", "calibration records", "governance policy" ], "interpretation_rules": [ "Do not penalize multilingual phrasing when technical reasoning is preserved.", "Do not expose raw transcripts in public artifacts.", "Require governance review before using language-sensitive scoring." ], "answer_card_fields": [ "language_boundary", "semantic_evidence", "bias_review", "confidence" ], "report_sections": [ "Governance and Risk Boundary" ], "maturity": "research_hypothesis", "validation_status": "proposed_metric_requires_complete_cost_definition_and_replication", "assumptions": [ "P_q, Q_q, the cost matrix C, mask M, lambda, and transform psi are fully defined.", "The transport comparison preserves the engineering construct being measured." ], "units": "Defined by psi applied to the transport cost.", "limitations": [ "The current compact formula omits optimization constraints.", "A lower transport cost does not automatically imply better engineering reasoning." ] }, { "id": "integrity_l2", "label": "Composite L2 Integrity Score", "formula_type": "fairness_model", "doctrine_source": { "route": "/decisions/axiom-cortex-engine/", "file": "data/cortex.ts", "title": "Axiom Cortex" }, "formula": "Integrity_L2 = w1*ICC_band + w2*avg(s_OT) + w3*avg(c_q) + w4*R2_Phase2_to_Phase3 + w5*GC - w6*Delta_trans", "plain_language": "Integrity combines consistency, semantic fidelity, conceptual content, phase coherence, grounding, and translation drift.", "diagnostic_use": "Use this only as public schema context for evaluation governance. Do not expose proprietary weights or private evidence.", "related_domains": [ "capacity_intelligence", "governance_security_failure_modes" ], "related_question_ids": [ "capacity-007", "knowledge-008", "gov-004", "gov-005" ], "required_signals": [ "approved rubric", "calibration evidence", "grounding check", "translation drift check", "audit record" ], "mcp_source_categories": [ "approved evaluation records", "governance policy", "audit records" ], "interpretation_rules": [ "Never publish proprietary scoring weights or raw evaluation records.", "Use aggregate calibration and governance evidence only.", "If audit evidence is missing, classify the evaluation system as not decision-grade." ], "answer_card_fields": [ "calibration_status", "audit_status", "private_data_boundary", "missing_evidence" ], "report_sections": [ "Governance and Risk Boundary" ], "maturity": "research_hypothesis", "validation_status": "composite_index_requires_normalization_weighting_and_sensitivity_analysis", "assumptions": [ "Every component is normalized to a comparable scale.", "Weights are declared before evaluation and tested for sensitivity." ], "units": "Dimensionless composite score after normalization.", "limitations": [ "Weights can dominate the result and must not be hidden.", "A single composite score can conceal compensating failures across components." ] }, { "id": "counterfactual_esl_stability", "label": "Counterfactual ESL Stability", "formula_type": "fairness_constraint", "doctrine_source": { "route": "/decisions/zero-trust-scoring/", "file": "data/decisions/regulation.ts", "title": "Regulation: Zero Trust" }, "formula": "|c_q - c_q_prime| <= tau_trans", "plain_language": "A score should remain stable when the same technical meaning is expressed in standardized English.", "diagnostic_use": "Use this as an audit question for evaluation systems and AI-assisted talent decisions.", "related_domains": [ "governance_security_failure_modes", "capacity_intelligence" ], "related_question_ids": [ "capacity-007", "gov-004", "gov-005" ], "required_signals": [ "counterfactual test result", "score drift", "translation policy", "audit record" ], "mcp_source_categories": [ "approved evaluation records", "audit records", "governance policy" ], "interpretation_rules": [ "If meaning is stable but score changes materially, flag bias risk.", "If the evaluation system lacks counterfactual testing, mark governance incomplete.", "Do not expose raw candidate data through this public research system." ], "answer_card_fields": [ "score_stability", "bias_risk", "audit_record", "next_safe_action" ], "report_sections": [ "Governance and Risk Boundary" ], "maturity": "research_hypothesis", "validation_status": "counterfactual_test_requires_semantics_preserving_transformations", "assumptions": [ "The counterfactual changes language form without changing engineering meaning or difficulty.", "Tau_trans is set before evaluation." ], "units": "Same score unit as c_q.", "limitations": [ "Invalid counterfactuals can create false instability.", "Passing the threshold is evidence of local stability, not complete fairness." ] }, { "id": "adversarial_indistinguishability", "label": "Adversarial Indistinguishability", "formula_type": "fairness_constraint", "doctrine_source": { "route": "/decisions/zero-trust-scoring/", "file": "data/decisions/regulation.ts", "title": "Regulation: Zero Trust" }, "formula": "AUC_protected_prediction compared with the 0.5 random-classification baseline", "plain_language": "An adversary that performs near the random-classification baseline has not demonstrated useful prediction of the protected attribute. That result is one diagnostic, not proof of fairness or zero leakage.", "diagnostic_use": "Use this to audit whether evaluation telemetry is fair enough for capacity topology decisions.", "related_domains": [ "governance_security_failure_modes", "capacity_intelligence" ], "related_question_ids": [ "capacity-007", "gov-004", "gov-005" ], "required_signals": [ "adversarial test result", "AUC summary", "feature policy", "model audit record" ], "mcp_source_categories": [ "approved evaluation records", "model governance records", "audit records" ], "interpretation_rules": [ "If background prediction is materially better than random, classify the scoring system as biased or leaky.", "If model governance records are unavailable, do not treat the evaluation score as decision-grade.", "Use aggregate audit summaries only." ], "answer_card_fields": [ "auc_summary", "leakage_risk", "audit_status", "confidence" ], "report_sections": [ "Governance and Risk Boundary" ], "maturity": "operating_heuristic", "validation_status": "diagnostic_test_not_fairness_proof", "assumptions": [ "The adversary is appropriately powered and evaluated on held-out representative data.", "Protected or linguistic labels are valid for the stated audit purpose." ], "units": "Dimensionless AUC from 0 to 1.", "limitations": [ "AUC near 0.5 is necessary but not sufficient evidence that protected information is not recoverable.", "It does not prove fairness, absence of leakage, calibration, or equal outcomes." ] }, { "id": "agentic_intervention_load", "label": "Agentic Intervention Load", "formula_type": "agentic_system_model", "doctrine_source": { "route": "/integration/integration-topologies/", "file": "data/integration/topology.ts", "title": "Integration Topologies" }, "formula": "Intervention Load Hours = Agent Execution Volume * Error Rate * Mean Human Repair Time + Context Switching Hours", "plain_language": "Agent speed is not free. Convert agent errors and context switching into the same human-time unit before comparing agent execution volume with orchestration capacity.", "diagnostic_use": "Use this to decide whether an agentic workflow is increasing throughput or overloading human orchestrators.", "related_domains": [ "governed_agentic_sdlc", "governed_adaptive_control_loops", "decision_grade_telemetry" ], "related_question_ids": [ "agent-001", "agent-004", "agent-005", "agent-006", "adaptive-003", "telemetry-007" ], "required_signals": [ "agent execution volume", "agent error rate", "human review load", "correction rate", "context switching", "cycle-time impact", "rollback triggers" ], "mcp_source_categories": [ "agent audit logs", "pull request system", "work tracker", "CI/CD system", "incident system" ], "interpretation_rules": [ "If intervention load exceeds human orchestration capacity, throttle agent execution.", "If agent velocity increases review queues, do not classify the workflow as successful automation.", "If error rate is unknown, keep the workflow human-gated." ], "answer_card_fields": [ "agent_volume", "agent_error_rate", "human_review_load", "throttle_recommendation" ], "report_sections": [ "Agentic Workflow Control Report", "Governed Adaptive Control Loop Report" ], "maturity": "operating_heuristic", "validation_status": "operational_cost_model_requires_local_measurement", "assumptions": [ "Error rate is measured on comparable agent actions.", "Mean human repair time and context-switch time use the same time unit." ], "units": "Human time, normally person-hours per measurement window.", "limitations": [ "Error severity and review effort may be highly skewed, so averages need percentile reporting.", "The model excludes downstream incident cost unless added explicitly." ] }, { "id": "engineering_throughput_equation", "label": "Engineering Throughput Equation", "formula_type": "throughput_model", "doctrine_source": { "route": "/teams/agentic-development-workflows/", "file": "data/teams/agentic.ts", "title": "Agentic Engineering Workflows" }, "formula": "Throughput = f(Topology, Cognitive Load, Coordination Cost, AI Assistance)", "plain_language": "Throughput is shaped by team topology, cognitive load, coordination cost, and bounded AI assistance, not headcount alone.", "diagnostic_use": "Use this as the bridge between doctrine math and the Engineering Capacity OS capacity topology questions.", "related_domains": [ "capacity_intelligence", "distributed_capacity_topology", "governed_agentic_sdlc", "decision_grade_telemetry" ], "related_question_ids": [ "capacity-001", "capacity-003", "topology-003", "agent-001", "telemetry-006" ], "required_signals": [ "team topology", "active WIP", "context switching", "coordination delay", "agent usage", "cycle time", "quality signal" ], "mcp_source_categories": [ "work tracker", "pull request system", "agent audit logs", "telemetry platform" ], "interpretation_rules": [ "If throughput gains come with higher rework or risk, do not report a capacity improvement.", "If AI assistance lowers cognitive load and review drag, classify the workflow as promising but still governed.", "If topology and coordination cost are unknown, throughput claims are unsupported." ], "answer_card_fields": [ "throughput_signal", "topology_signal", "cognitive_load_signal", "agent_assistance_signal" ], "report_sections": [ "Capacity Topology Readiness", "Agentic Workflow Control Report" ], "maturity": "research_hypothesis", "validation_status": "dependency_map_not_predictive_equation", "assumptions": [ "Topology, load, coordination cost, and AI assistance are measured over the same workflow and time window.", "Quality and risk constraints are reported with throughput." ], "units": "Throughput uses completed value-bearing work per unit time; inputs retain their own units.", "limitations": [ "The function does not specify coefficients, interactions, or causal direction.", "Higher throughput is not system improvement when quality, risk, or value degrades." ] } ], "epistemic_policy": { "purpose": "Separate established mathematics from TeamStation-derived models, operating heuristics, and research hypotheses.", "classes": { "established_model": "A named or standard mathematical or engineering model used within its stated assumptions.", "derived_model": "An algebraic or statistical model derived from stated assumptions and requiring local parameter estimation.", "operating_heuristic": "A practical decision rule or diagnostic threshold that requires local testing and must not be presented as a universal law.", "research_hypothesis": "A proposed relationship or construct that is testable but not yet independently validated or calibrated." }, "decision_rule": "No formula may produce an automated recommendation when its assumptions, units, required signals, or validation boundary are unknown." } } }