onto-mcp 0.3.1 → 0.3.2

package/.onto/domains/software-engineering/domain_scope.md

@@ -1,183 +1,214 @@
 ---
-version: 3
-last_updated: "2026-03-31"
-source: bundled-domain-baseline
+version: 8
+last_updated: "2026-05-28"
+source: zero-based-software-engineering-redesign
 status: established
 ---
 
-# Software Engineering Domain — Domain Scope Definition
+# Software Engineering Domain - Domain Scope Definition
 
-This is the reference document used by coverage to identify "what should exist but is missing."
-This domain applies when **reviewing** a software system.
+This document is the coverage and axiology entrypoint for the `software-engineering`
+domain. It defines what a software review must be able to notice.
 
-## Major Sub-areas
-
-Classification axis: **concern** — classified by the design concerns that a software system must address.
-
-Applicability markers:
-- **(required)**: Must be addressed in any software system review. Absence indicates a fundamental gap
-- **(when applicable)**: Address when the system's architecture includes the relevant pattern. Not addressing it when the pattern is absent is correct, not a gap
-- **(scale-dependent)**: Becomes required beyond a scale threshold. The threshold should be documented per sub-area
-
-### Data & State
-- **Data Modeling** (required): entities, relationships, type definitions, schema design. Uber's Schemaless demonstrates schema-on-read (MySQL stores JSON blobs, schema evolution without migrations). Netflix EVCache handles 30M+ req/s, illustrating consistency vs availability trade-offs. Event Sourcing (Greg Young, EventStore) stores state as immutable event logs — Axon Framework implements this on the JVM with built-in CQRS. Data modeling must declare schema-on-write vs schema-on-read, as this determines migration strategy and consistency guarantees
-- **State Management** (required): state transitions, invariants, recovery paths, concurrency control. CQRS (Command Query Responsibility Segregation) separates read and write models — the write side enforces invariants via commands, the read side serves optimized projections. Saga patterns (choreography vs orchestration) coordinate distributed state changes across service boundaries without distributed transactions
-- **Event Sourcing** (when applicable): event storage, state reconstruction, projections, terminal states, partial commit prevention. Event Store (eventstore.com) provides a purpose-built database for event sourcing with built-in projections and subscriptions
-
-### Interface & Contract
-- **API Design** (required): public interfaces, versioning, contracts, backward compatibility. REST maturity is measured by Richardson's Maturity Model (L0: HTTP tunnel → L3: hypermedia/HATEOAS). GraphQL (Facebook, 2015) lets clients specify exact data shapes, solving over/under-fetching. gRPC (Google) uses Protocol Buffers for schema-first, strongly-typed RPC with HTTP/2 multiplexing. Stripe's rolling API versioning pins each customer to their integration version, avoiding the "upgrade cliff." OpenAPI/Swagger provides machine-readable specs enabling automated client generation and contract testing
-- **Type System** (required): discriminated union, exhaustive check, type-level safety mechanisms. TypeScript's discriminated unions with exhaustive switch/case checking eliminate an entire class of runtime errors at compile time. Rust's `Result<T, E>` and `Option<T>` force callers to handle both success and failure paths (see also: concepts.md §Type Safety Mechanisms)
-- **Error Handling** (required): error classification, recovery strategies, fallback paths, user guidance. Error classification should distinguish operational errors (expected, recoverable: network timeout, validation failure) from programmer errors (unexpected, non-recoverable: null dereference, assertion violation). Circuit breaker patterns (Netflix Hystrix, Resilience4j) prevent cascading failures by failing fast when downstream services are unhealthy
-- **Requirements & Specification** (when applicable): functional and non-functional requirements capture, acceptance criteria, traceability from requirements to implementation. IEEE 830 (SRS) provides a standard format. Requirements must be testable — each requirement should map to at least one verification method. Non-functional requirements (performance, security, availability) must be quantified. Applicable when formal requirements management is practiced; implicit for small-team projects with clear verbal agreements
+`software-engineering` is the canonical domain for conventional software engineering,
+AI-assisted development, and LLM-powered product/runtime behavior. The former
+`llm-native-development` domain is a compatibility alias only. A reviewer should not
+run a second domain review to cover AI behavior; this domain activates AI-era concerns
+when the target uses LLMs, agents, model providers, prompt/context contracts, retrieval,
+semantic evaluation, AI-assisted workflows, or tool-call boundaries.
 
-### Security & Auth
-- **Authentication/Authorization** (required): user identification, permission systems, access control. OAuth 2.0/OIDC are the industry standards for delegated auth. JWT enables stateless authentication but requires careful token expiration, refresh rotation, and revocation handling. RBAC vs ABAC represent different authorization models — RBAC assigns permissions to roles, ABAC evaluates policies against attributes at runtime
-- **Security** (required): input validation, injection prevention, data encryption, supply chain security. OWASP Top 10 (2021) classifies critical risks: A01 Broken Access Control through A10 SSRF. Log4Shell (CVE-2021-44228) demonstrated supply chain risk — a single Log4j vulnerability compromised millions of systems. The SolarWinds attack (2020) showed compromised build pipelines can inject malicious code into trusted updates, affecting 18,000+ organizations
+The domain is not a MECE taxonomy. It is a lens-usable concern map. A concern is strong
+enough for active scope when it can support:
 
-### Verification & Quality
-- **Test Strategy** (required): unit/integration/E2E coverage, verification criteria, test data management. Google's Testing Pyramid: many unit tests (fast, isolated), fewer integration tests (service boundaries), minimal E2E tests (slow, brittle). Fowler distinguishes sociable tests (real collaborators) from solitary tests (test doubles). Property-based testing (QuickCheck, Hypothesis, fast-check) generates random inputs to discover edge cases. Mutation testing (Stryker, PIT) validates test suite effectiveness by checking that tests catch injected mutations (see also: structure_spec.md §Verification Structure)
-- **Verification Design** (when applicable): verification timing (shift-left), structural vs semantic verification, specification requirements when delegating to AI agents. Netflix Chaos Engineering (Chaos Monkey, 2011) injects failures in production to verify resilience — accepting failure as inevitable and testing recovery paths
-- **Performance** (scale-dependent): response time, throughput, caching strategy. Load testing tools (k6, Gatling, Locust) simulate concurrent users to identify bottlenecks before production. Key metrics: p50/p95/p99 latency, throughput (RPS), error rate under load
+```text
+lens perspective -> principle -> case evidence -> actionable guideline -> CQ
+```
 
-### Structure & Architecture
-- **Module Separation** (required): layer structure, dependency direction, separation of concerns. Hexagonal Architecture (Cockburn, 2005) isolates domain logic from infrastructure through ports and adapters, making the core testable without databases or HTTP. Clean Architecture (Robert C. Martin) enforces the Dependency Rule: dependencies point only inward. Domain-Driven Design (Evans, 2003) organizes code around bounded contexts. Microservices (Sam Newman) decompose systems into independently deployable services, trading operational complexity for deployment independence
-- **Data Flow** (required): input-to-processing-to-output paths, transformation chains, source of truth designation. Pipe-and-filter architecture (Unix philosophy) composes systems from small, focused transformations. Event-driven architecture uses event buses (Kafka, RabbitMQ) to decouple producers from consumers
-- **Event/Messaging** (when applicable): message queues, asynchronous processing, pipeline scalability. Apache Kafka provides durable, partitioned event logs enabling replay and exactly-once semantics. Message delivery guarantees (at-most-once, at-least-once, exactly-once) have fundamental trade-offs with latency and complexity
+## Domain Purpose
 
-### Operations, Deployment & Maintenance
-- **Deployment/Operations** (scale-dependent): CI/CD, environment separation, monitoring, logging. The 12-Factor App defines 12 principles for cloud-native applications (codebase, dependencies, config, backing services, build/release/run, processes, port binding, concurrency, disposability, dev/prod parity, logs, admin processes). GitOps (Weaveworks) uses Git as the single source of truth for declarative infrastructure. Feature flags (LaunchDarkly, Unleash) decouple deployment from release, enabling progressive rollouts without redeployment. Google SRE defines error budgets, SLIs/SLOs/SLAs, and toil reduction. DORA metrics (Deployment Frequency, Lead Time, Change Failure Rate, Time to Restore) measure delivery performance
-- **Internationalization/Accessibility** (scale-dependent): multi-language, time zones, accessibility standards. **Applicability conditions**: Required when (1) the system serves users in multiple locales, (2) the system is subject to accessibility regulations (ADA, EAA, EN 301 549), or (3) the system is public-facing web/mobile. Not applicable for internal tools with a single-locale user base unless regulatory requirements mandate it. WCAG 2.1 defines A/AA/AAA conformance levels. ICU handles locale-aware formatting, collation, and transliteration. See concepts.md §Internationalization/Accessibility Terms for definitions
-- **Maintenance** (when applicable): corrective maintenance (fixing defects discovered after delivery), adaptive maintenance (accommodating environment changes — OS upgrades, dependency updates, regulatory changes), perfective maintenance (improving performance/maintainability based on user feedback), preventive maintenance (refactoring to prevent anticipated problems). IEEE 14764 classifies these four categories. Technical debt management maps to preventive maintenance. Corrective/adaptive are reactive; perfective/preventive are proactive. See concepts.md §Change Management Terms for related terminology
+Software engineering review should detect whether a software system can be understood,
+changed, verified, operated, trusted, and retired without hiding the authority, evidence,
+or value tradeoffs that make the system work.
 
-### Documentation & Consumers
-- **Document Design** (when applicable): dual-consumer handling for AI agents and humans, separation of contract documents vs guide documents, separation of information structure and rendering. Diátaxis classifies documentation into 4 types: tutorials (learning), how-to guides (task), reference (information), explanation (understanding). ADRs (Michael Nygard) capture the "why" behind architectural choices in structured format (context, decision, consequences). API-first design ensures contracts are defined before implementation
-- **Constraint Design** (when applicable): hard/soft constraint classification, invariant vs best-effort boundary, pre-inclusion vs post-verification. Hard constraints: invariants that must never be violated (data integrity, security). Soft constraints: preferences relaxed under pressure (response time targets, cache hit ratios)
+The domain covers the full lifecycle:
 
-## Normative System Classification
+1. acquisition and supply
+2. requirements and design
+3. implementation
+4. verification and release
+5. operation and incident response
+6. maintenance and evolution
+7. decommissioning and retirement
 
-Standards governing software engineering operate at three distinct layers. Each layer has different enforcement mechanisms and change velocity.
+LLM-native artifacts inherit this lifecycle. Prompts, context assembly rules, tool
+schemas, retrieval indexes, model/provider routes, eval rubrics, agent instructions, and
+generated authority artifacts are behavior-affecting software artifacts.
 
-| Layer | Scope | Enforcement | Change Velocity | Examples |
-|---|---|---|---|---|
-| Layer 1 — Language/Runtime | Syntax, semantics, built-in APIs | Compiler/interpreter rejection | Slow (years) | ECMAScript, JLS, Go Spec, Rust Reference |
-| Layer 2 — Framework/Library | Conventions imposed by frameworks | Runtime errors, lint rules | Medium (quarterly) | React hooks rules, Spring IoC, Rails conventions |
-| Layer 3 — Industry/Organization | Cross-technology principles | Code review, audit | Fast (per incident) | OWASP Top 10, 12-Factor, SOLID, DDD patterns |
+## Axiology Input
 
-**Why this matters**: A review that cites only Layer 3 principles without checking Layer 1/2 conformance misses concrete, enforceable violations. Conversely, a review that only checks Layer 1/2 conformance without Layer 3 assessment misses systemic design issues.
+Axiology uses this domain input to identify value conflicts; it does not treat these
+statements as predetermined conclusions.
 
-## Required Concept Categories
-
-These are concept categories that must be addressed in any software system.
-
-| Category | Description | Risk if Missing | Example of Failure |
-|---|---|---|---|
-| Happy path | Normal behavior for expected inputs | Incomplete functional definition | API returns 200 but response body format is unspecified |
-| Error path | Handling of abnormal inputs/states | Defenseless during failures | Unhandled exception crashes process; user sees raw stack trace |
-| Boundary condition | Min/max values, empty inputs, concurrent access | Edge case failures | Integer overflow in payment calculation; empty array dereference |
-| Lifecycle | Creation → use → disposal, state transitions | Resource leaks, zombie objects | Database connection pool exhaustion from unclosed connections |
-| Traceability | Change rationale, decision justification, audit trail | Unmaintainable | 3-year-old conditional with no comment or commit message explaining why it exists |
-| Source of truth | The authoritative data/definition source when inconsistencies arise | Unable to resolve information conflicts | User profile cached in 3 services diverges; no system is designated authoritative |
-| Concurrency | Thread safety, race conditions, deadlock prevention | Data corruption under load | Two threads updating the same balance without locking; lost update |
-| Idempotency | Operations that produce the same result when executed multiple times | Duplicate side effects | Payment charged twice because retry logic doesn't check for existing transaction |
-| Observability | Logging, metrics, and tracing for runtime behavior | Silent failures, undiagnosable production issues | Error rate spikes but no logs indicate which endpoint or upstream service is responsible |
-
-## Reference Standards/Frameworks
-
-| Standard | Application Area | Usage | When to Apply |
-|---|---|---|---|
-| OWASP Top 10 (2021) | Security | Web application security vulnerability classification | Every web-facing system; review checklist for security |
-| 12-Factor App | Deployment/Operations | Cloud-native application design principles | Cloud-deployed services; SaaS architecture review |
-| REST Maturity Model (Richardson) | API Design | API design level assessment (L0–L3) | Reviewing or designing REST APIs |
-| SOLID Principles | Module separation, type system | Five principles of object-oriented design | Object-oriented codebases; module boundary review |
-| Event Sourcing Pattern | Event Sourcing | Event storage, state reconstruction, projections | Systems requiring full audit trail or temporal queries |
-| Diátaxis Framework | Document Design | Tutorial/How-to/Reference/Explanation 4-way classification | Documentation review or creation |
-| IEEE 830 (SRS) | Requirements | Software Requirements Specification format | Formal requirements documentation |
-| ISO 25010 | Quality Model | Software quality characteristics (8 characteristics, 31 sub-characteristics) | System quality attribute assessment |
-| TOGAF | Architecture | Enterprise architecture framework and ADM (Architecture Development Method) | Enterprise-scale architecture decisions |
-| C4 Model (Simon Brown) | Architecture | 4-level architecture diagramming (Context, Container, Component, Code) | Architecture documentation and communication |
-| Arc42 | Architecture | Pragmatic architecture documentation template (12 sections) | Documenting system architecture decisions |
-| Domain-Driven Design (Eric Evans) | Structure & Architecture | Bounded contexts, aggregates, ubiquitous language | Complex domains with rich business logic |
-| Google SRE Workbook | Operations | Error budgets, SLIs/SLOs, incident management | Production systems requiring reliability guarantees |
-| IEEE 14764 | Maintenance | Software maintenance process and classification (corrective/adaptive/perfective/preventive) | Systems with ongoing maintenance operations |
-| WCAG 2.1 | Accessibility | Web Content Accessibility Guidelines (A/AA/AAA conformance levels) | Public-facing web applications; legally mandated accessibility |
-
-## Bias Detection Criteria
-
-- If ⌈N/2.5⌉ or more of the Major Sub-areas (§Major Sub-areas) are not represented at all → **insufficient coverage**. **N** = the number of `###` subsections under §Major Sub-areas (count at review time — do not hard-code). At review time the reviewer counts the current `###` headings under §Major Sub-areas and computes the threshold from N, so adding or removing a sub-area updates the threshold automatically without editing this rule
-- If concepts from a specific area account for more than 70% of the total → **area bias**
-- If only the happy path is defined with no error path → **path bias**
-- If creation/use is defined but disposal/cleanup is missing → **incomplete lifecycle**
-- If 2 or more data sources lack a designated source of truth → **undesignated authority**
-- If the document design area is missing in a system where AI agents are consumers/executors → **missing consumer perspective**
-- If only synchronous request-response is considered with no async patterns (queues, events, callbacks) → **concurrency blindness**. Production systems require async for resilience and scalability
-- If only server-side logic is addressed with no client-side considerations → **deployment bias**. Full-stack systems need design decisions on both sides of the network boundary
-- If testing covers only unit tests with no integration or E2E strategy → **test level bias**. Each level catches different defect classes; missing any level leaves a verification gap (see also: structure_spec.md §Verification Structure)
-- If security addresses only authentication without authorization → **security scope bias**. Auth without authz means every authenticated user has full access (OWASP A01)
-- If only read operations are designed with no write/mutation considerations → **operation bias**. Ignoring write paths produces systems that fail under mutation load
+| Value commitment | Review signal |
+|---|---|
+| Diagnosability over false smoothness | Silent fallback, hidden repair, or unmarked degradation is suspect when it hides the failing boundary |
+| Artifact truth over response truth | Public responses may summarize durable artifacts but must not become the authority seat |
+| Accountability over automation theater | Agent autonomy must preserve owner, approval, audit, and recovery paths |
+| Evidence over plausibility | Generated or retrieved claims need provenance when they affect trust, release, or user decisions |
+| Explicit loss over invisible degradation | User-facing degradation is acceptable only when capability loss, trust status, diagnostics, and recovery are visible |
+| Least agency over broad capability | Agent functionality, permissions, and autonomy must be minimized separately |
+| Governance as engineering material | AI risk ownership, approval gates, incident disclosure, and continuous improvement are reviewable engineering concerns |
+| Accessibility and user agency | Speed or productivity claims do not justify excluding affected users or hiding control from operators |
 
-## Inter-Document Contract
+## Top-Down Concern Stack
 
-This section declares which file owns which cross-cutting topic, preventing rule duplication and phantom references.
+Reviewers should reason from the top down before diving into local implementation detail.
 
-### Rule Ownership
-
-| Cross-cutting Topic | Owner File | Other Files |
+| Layer | What to look for | Primary lens consumers |
 |---|---|---|
-| Dependency direction rules | dependency_rules.md | structure_spec.md (references only) |
-| Backward compatibility classification | dependency_rules.md | logic_rules.md (references only) |
-| Concept definitions | concepts.md | All other files reference, do not redefine |
-| Structural coherence rules | structure_spec.md §Golden Relationships | Other files reference |
-| Conciseness criteria | conciseness_rules.md | Other files reference |
-| Competency questions | competency_qs.md | Other files provide inference path targets |
-| Error handling design | logic_rules.md §Error Handling Logic | dependency_rules.md (cascading failure mechanisms) |
-| Performance optimization rules | logic_rules.md §Performance Logic | structure_spec.md (thresholds), domain_scope.md (SLOs) |
-
-### Required Substance per Sub-area
+| Purpose and value | Stakeholder promises, harms, accountability, tradeoffs, non-negotiable constraints | axiology, coverage, pragmatics |
+| Lifecycle and governance | Acquisition/supply, approval gates, risk ownership, incident response, retirement | coverage, axiology, evolution |
+| Architecture and state | Modules, interfaces, state transitions, source of truth, concurrency, data flow | structure, logic, dependency |
+| Contract and dependency truth | Types, schemas, APIs, package dependencies, provider/model/tool/corpus dependencies | dependency, logic, semantics |
+| Verification and operations | Tests, static checks, semantic eval, red-team evidence, release gates, observability, drift detection | pragmatics, coverage, evolution |
+| LLM-native behavior controls | Prompt/context contracts, output zero-trust, retrieval boundaries, agent agency, model routing, failure posture | logic, structure, dependency, axiology |
+| Case evidence and CQ library | Case-backed guideline cards and PASS/FAIL review questions | pragmatics, evolution, coverage |
 
-Each sub-area declared in Major Sub-areas must have corresponding substance in at least one of:
-- concepts.md: term definitions
-- logic_rules.md or structure_spec.md or dependency_rules.md: operational rules
-- competency_qs.md: verification questions
+## Major Sub-areas
 
-A sub-area with declaration but no substance in any file is a "ghost sub-area" and must either be populated or annotated with applicability conditions.
+Applicability markers:
 
-### Cross-cutting Concern Attribution
+- **required**: must be addressed in every software review.
+- **when applicable**: required when the target uses the relevant pattern.
+- **scale-dependent**: required beyond a documented scale, exposure, or risk threshold.
 
-When a concern spans multiple sub-areas, attribute it to the sub-area where the concern has its **primary enforcement point**:
+| Sub-area | Applicability | Review substance |
+|---|---|---|
+| Data and state | required | entities, schemas, source of truth, invariants, migrations, state transitions, consistency, retention/disposal |
+| Interface and contract | required | APIs, types, schemas, versioning, requirements, acceptance criteria, backward compatibility |
+| Error and failure posture | required | error taxonomy, fail-close gates, fail-loud diagnostics, recovery paths, user-facing loss markers |
+| Security and authorization | required | authn/authz, input/output validation, injection prevention, secrets, privacy, supply chain, abuse boundaries |
+| Verification and quality | required | unit/integration/E2E/static checks, semantic eval, quality attributes, release gates, measurable acceptance criteria |
+| Architecture and structure | required | module/layer boundaries, dependency direction, state ownership, deployment topology, consumer surfaces |
+| Operations and maintenance | required for operated systems | CI/CD, observability, incident response, SLOs, drift detection, maintenance classification, retirement |
+| Documentation and consumers | when applicable | human/agent readers, contract vs guide docs, authority seats, diagrams, onboarding and handoff paths |
+| LLM-native and agentic behavior | when applicable | model/provider routing, prompts, context, retrieval, tools, agents, eval, provenance, failure diagnostics |
+| AI governance and risk | when applicable | risk owner, approval gate, human oversight, transparency, red-team loop, incident disclosure, continuous improvement |
+| Accessibility and internationalization | scale-dependent | WCAG/current accessibility baseline, locale/time/currency/text-direction behavior, assistive technology support |
+
+## LLM-Native Activation Conditions
+
+Activate LLM-native review concerns when any of the following is true:
+
+- product behavior depends on a model call, agent loop, retrieval result, or generated output.
+- development/review/release workflow depends on LLM-generated artifacts.
+- prompt templates, tool schemas, eval rubrics, or model/provider routes influence behavior.
+- external content enters model context through files, webpages, RAG, search, or user-provided text.
+- model output can trigger tool calls, persistence, authority artifacts, user-visible decisions, or downstream sinks.
+
+When activated, the target must address:
+
+- LLM/runtime/middleware ownership split.
+- output zero-trust and sink-specific validation.
+- prompt injection and external-content authority limits.
+- RAG/vector ingestion, permission, poisoning, provenance, and audit boundaries.
+- agent functionality, permission, and autonomy minimization.
+- semantic evaluation and production drift monitoring.
+- fail-loud diagnostics for development/review/authority paths.
+- explicit degraded-state behavior for product paths.
+- AI governance/risk ownership when behavior can materially affect users, operators, security, or release decisions.
 
-1. **Primary enforcement point**: The sub-area whose rules would be violated if the concern is not addressed. Example: input validation spans Interface & Contract (API design) and Security & Auth (injection prevention). Primary enforcement: Security & Auth, because the security consequence is the enforcement driver
-2. **Secondary references**: Other sub-areas reference the primary sub-area's rules rather than duplicating them
-3. **Tie-breaking**: If enforcement is equally distributed, attribute to the sub-area with fewer existing items (load balancing)
+## Required Concept Categories
 
-### Classification Axis Relationships
+| Category | Risk if missing | Example failure |
+|---|---|---|
+| Happy path | Functional intent is incomplete | API returns 200 but response body semantics are unspecified |
+| Error path | Failures are defenseless or hidden | Runtime catches and ignores validation errors |
+| Boundary condition | Edge cases break correctness | Empty input, max value, clock skew, race, or overflow is unhandled |
+| Concurrency | Parallel or asynchronous access breaks safety | Race, deadlock, resource exhaustion, or ordering assumption corrupts state |
+| Lifecycle | Resources or obligations survive past use | Data, feature flags, services, or AI indexes have no retirement path |
+| Traceability | Review cannot explain why behavior changed | A prompt/provider change has no decision record or eval comparison |
+| Source of truth | Conflicts cannot be resolved | Cache, DB, generated artifact, and public response disagree |
+| Authority boundary | A layer silently takes over another layer's responsibility | Middleware repairs semantic meaning and becomes hidden policy authority |
+| Observability | Operators cannot diagnose behavior | Model/tool failures lack prompt, route, schema, or artifact refs |
+| Provenance | Evidence cannot be trusted | Retrieved or generated claims lack source and builder/agent trace |
+| Agency boundary | Automation exceeds intended control | Agent can call high-impact tools without approval or least privilege |
+| Semantic evaluation | Route success is mistaken for quality | Schema-valid model output is hallucinated or unfaithful |
+| Governance path | Risk has no accountable owner | AI feature ships without approval gate, incident path, or red-team feedback loop |
+
+## Reference Standards and Frameworks
+
+These anchors provide review signals, not checklist-compliance obligations unless the
+target explicitly claims conformance.
+
+| Anchor | Use in this domain |
+|---|---|
+| NIST AI RMF 1.0 | AI risk framing across design, development, deployment, and use |
+| NIST AI 600-1 GenAI Profile | GenAI governance, provenance, testing, incident disclosure, red-team loop |
+| ISO/IEC 42001 | AI management-system concepts: ownership, objectives, risk treatment, traceability, improvement |
+| NIST SSDF SP 800-218 and SP 800-218A | Secure development evidence for software and AI/foundation-model artifacts |
+| OWASP LLM Top 10 2025 | Prompt injection, output handling, excessive agency, vector/embedding, supply-chain and resource risks |
+| SLSA | Artifact provenance and verification summaries for supply-chain trust |
+| ISO/IEC/IEEE 12207:2026 | Full software lifecycle, including acquisition, supply, operation, support, maintenance, retirement |
+| ISO/IEC 25010:2023 | Quality characteristics as requirements, design objectives, tests, acceptance criteria, and measures |
+| ISO/IEC/IEEE 29148 | Requirements processes and information items; preferred over IEEE 830 for current requirements work |
+| WCAG 2.2 / ISO/IEC 40500:2025 | Current accessibility baseline for web/mobile/user-facing interfaces |
+| OWASP Top 10 | General web application security risks |
+| 12-Factor App, SRE, DORA | Operational design, reliability, deployability, and delivery performance |
+| DDD, C4, Arc42, Clean/Hexagonal Architecture | Architecture documentation and boundary reasoning |
 
-The domain files use three related concern axes — they are facets of the same domain, not independent classification systems:
+## Bias Detection Criteria
 
-| File | Axis | Facet |
-|---|---|---|
-| domain_scope.md | concern | What design concerns exist (scope) |
-| logic_rules.md | system construction concern | What concerns are governed by rules (rules) |
-| competency_qs.md | verification concern | What concerns must be verified (questions) |
+- If too many major sub-areas are absent, flag **coverage bias**. Count current sub-areas at review time and treat absence of roughly 40% or more as a strong signal.
+- If a review target includes LLM behavior but omits prompts, context, model/provider, tool, retrieval, eval, and governance concerns, flag **AI-era engineering blind spot**.
+- If fallback, repair, or graceful degradation hides the failing prompt, model, schema, tool, retrieval, or artifact boundary, flag **silent degradation bias**.
+- If LLM, runtime, and middleware responsibilities are not separated, flag **ownership boundary bias**.
+- If model output is trusted because the prompt requested a format, flag **output trust bias**.
+- If retrieved material can influence claims without source provenance and permission-aware retrieval, flag **retrieval authority bias**.
+- If agent capability, permission, and autonomy are discussed as one undifferentiated knob, flag **agency compression bias**.
+- If governance, approval, incident response, or human oversight is treated as external policy only, flag **governance externalization bias**.
+- If only implementation is discussed and acquisition/supply/operation/retirement are absent, flag **lifecycle narrowing bias**.
+- If only unit tests are discussed for behavior with integration, semantic, security, or operational risk, flag **verification level bias**.
+- If accessibility is outdated, qualitative, or omitted for a public/user-facing system, flag **accessibility currency bias**.
 
-### Sub-area to CQ Section Mapping
+## Inter-Document Contract
 
-| Sub-area | CQ Sections | Coverage |
+| Topic | Owner file | Other files |
 |---|---|---|
-| Data & State | CQ-D (Data Flow) | Full |
-| Interface & Contract | CQ-I (Change Impact), CQ-E (Error Handling), CQ-R (Requirements) | Full |
-| Security & Auth | CQ-SE (Security) | Full |
-| Verification & Quality | CQ-V (Testing/Verification), CQ-P (Performance) | Full |
-| Structure & Architecture | CQ-S (Structural Understanding), CQ-M (Event/Messaging) | Full |
-| Operations, Deployment & Maintenance | CQ-O (Deployment/Operations), CQ-MT (Maintenance) | Full |
-| Documentation & Consumers | CQ-A (AI Agent Collaboration) | Partial (AI-focused) |
-
-Cross-cutting CQ sections (not mapped to a single sub-area):
-- CQ-T (Types and Constraints) — spans Interface & Contract + Data & State
-- CQ-B (Boundary Conditions) — spans all sub-areas
-- CQ-C (Concurrency) — spans Data & State + Structure & Architecture
-- CQ-DE (Dependencies) — spans Structure & Architecture + Operations
+| Domain purpose, scope, value commitments, standards anchors | domain_scope.md | Other files reference |
+| Domain-local concept definitions, domain projections, and homonym guards | concepts.md | Other files reference; onto/productization core concepts remain canonical in `.onto/authority/`, `.onto/principles/`, or `.onto/processes/` |
+| Logical gates, contradiction rules, failure posture, trust rules | logic_rules.md | competency_qs.md asks; prompt_interface.md applies |
+| Structural seats and required relationships | structure_spec.md | domain_scope.md activates; competency_qs.md verifies |
+| Dependency direction, provider/model/tool/corpus dependencies, provenance dependencies | dependency_rules.md | structure_spec.md references |
+| Prompt, role, context, tool, response, sink interface criteria | prompt_interface.md | logic_rules.md and structure_spec.md reference |
+| Domain-specific CQs and PASS/FAIL criteria | competency_qs.md | All rule files provide inference paths |
+| Case-backed guideline library | extension_cases.md | competency_qs.md can reuse CQ seeds |
+| Concept economy and duplication policy | conciseness_rules.md | All files follow |
+| Closure axes for issue stance and synthesize | problem_framing_profile.md | Review runtime consumes |
+
+## Sub-area to CQ Mapping
+
+| Sub-area | CQ sections |
+|---|---|
+| Data and state | CQ-D, CQ-T, CQ-B, CQ-C, CQ-SE |
+| Interface and contract | CQ-I, CQ-R, CQ-E |
+| Error and failure posture | CQ-E, CQ-A, CQ-G |
+| Security and authorization | CQ-SE, CQ-A, CQ-DE, CQ-D |
+| Verification and quality | CQ-V, CQ-P, CQ-A, CQ-G |
+| Architecture and structure | CQ-S, CQ-M, CQ-C, CQ-DE |
+| Operations and maintenance | CQ-O, CQ-MT, CQ-G, CQ-DE |
+| Documentation and consumers | CQ-A, CQ-R, CQ-S |
+| LLM-native and agentic behavior | CQ-A, CQ-SE, CQ-DE, CQ-G |
+| AI governance and risk | CQ-G, CQ-A, CQ-O |
+| Accessibility and internationalization | CQ-R, CQ-V, CQ-G |
 
 ## Related Documents
-- concepts.md §Architecture Core Terms — definitions of terms within this scope
-- structure_spec.md §Required Module Structure Elements — specific rules for module structure, test organization
-- competency_qs.md — questions this scope must be able to answer
+
+- concepts.md - canonical terms and homonym guards
+- logic_rules.md - logical rules, trust gates, failure posture
+- structure_spec.md - required structures and relationships
+- dependency_rules.md - dependency and provenance rules
+- prompt_interface.md - prompt, role, tool, context, output, and sink criteria
+- competency_qs.md - domain competency questions
+- extension_cases.md - case-backed guideline cards
+- problem_framing_profile.md - closure axes for software-engineering review findings