onto-mcp 0.3.0

package/.onto/domains/business/conciseness_rules.md

@@ -0,0 +1,135 @@
+---
+version: 2
+last_updated: "2026-03-31"
+source: manual
+status: established
+---
+
+# Conciseness Rules (business)
+
+This document defines the business-domain rules used by conciseness.
+It controls where repetition is necessary, where it becomes harmful, and which thresholds should trigger consolidation review.
+
+## 1. Allowed Redundancy
+
+Each rule is tagged with a severity level:
+- **[MUST-ALLOW]**: Removing the redundancy would break inference, traceability, or execution.
+- **[MAY-ALLOW]**: The redundancy may remain when it serves a clearly different review purpose.
+
+### Performance and Measurement
+
+- [MUST-ALLOW] Leading and lagging indicators for the same objective appearing together. Removing either side breaks the causal interpretation of performance.
+- [MUST-ALLOW] Balanced Scorecard perspectives referring to the same KPI from different lenses. The perspectives are not duplicates because they support different judgments.
+- [MAY-ALLOW] The same metric appearing in `concepts.md §Benchmark Registry` and a CQ verification criterion, as long as the CQ cites the registry rather than redefining the number.
+
+### Strategy and Operating Translation
+
+- [MUST-ALLOW] A strategic claim in `domain_scope.md` and the operating consequence in `logic_rules.md` or `structure_spec.md`. These are not duplicates because one declares scope and the other declares behavior.
+- [MAY-ALLOW] A revenue model appearing in both strategic and operational contexts when the strategic version explains choice and the operational version explains delivery mechanics.
+- [MAY-ALLOW] The same case being referenced in both `extension_cases.md` and another file, provided only one file is the detailed owner and the others use it as a compressed anchor.
+
+### Source of Truth and Reference Copies
+
+- [MUST-ALLOW] An internal reference to an external authority such as a legal rule, accounting output, or benchmark source. Without the reference copy, the business domain loses reviewability.
+- [MUST-ALLOW] A benchmark value in `concepts.md §Benchmark Registry` and a qualitative interpretation of that benchmark in `logic_rules.md`. Numeric authority and business interpretation are different functions.
+- [MAY-ALLOW] The same stakeholder appearing under governance and ESG if one reference concerns control ownership and the other concerns impact ownership.
+
+### Modern Business Patterns
+
+- [MUST-ALLOW] A platform metric in both platform logic and governance analysis when the first explains economics and the second explains participant fairness or enforcement.
+- [MUST-ALLOW] Subscription metrics in both finance and customer-management contexts when one explains unit economics and the other explains retention operations.
+- [MUST-ALLOW] AI concepts appearing in economic and governance contexts when one explains value capture and the other explains control obligations.
+
+## 2. Removal Target Patterns
+
+Each rule is tagged with a severity level:
+- **[MUST-REMOVE]**: The duplication itself creates wrong inferences or conflicting authority.
+- **[SHOULD-REMOVE]**: The duplication adds complexity without adding a distinct review function.
+
+### Relation Redundancy
+
+- [MUST-REMOVE] Multiple causal chains that express the same business rule with no extra decision value. If both can change independently but should not, one should be removed.
+- [MUST-REMOVE] A subordinate tactic restated as if it were an independent strategy when it is already entailed by the superior strategic choice.
+- [SHOULD-REMOVE] Parallel lists of "important factors" that have the same members and no different ownership, threshold, or CQ impact.
+
+### Classification Redundancy
+
+- [SHOULD-REMOVE] Intermediate classifications with only one child and no distinct CQ, dependency, or constraint effect.
+- [SHOULD-REMOVE] Separate classifications for labels that differ only in wording but not in review behavior.
+- [SHOULD-REMOVE] Scale distinctions that do not change review behavior. If Micro, Small, Mid, or Large labels do not alter the rule, keep the rule at the broader level.
+
+### Definition Redundancy
+
+- [MUST-REMOVE] Competing definitions of the same metric, concept, or benchmark under different sections.
+- [MUST-REMOVE] Re-stating a benchmark number outside `concepts.md §Benchmark Registry` without a reference back to the canonical source.
+- [SHOULD-REMOVE] Re-explaining a concept in multiple files when the downstream file only needs to apply the concept.
+
+### Case Redundancy
+
+- [MUST-REMOVE] The same company case explained in detail in two or more files with no declared primary owner.
+- [SHOULD-REMOVE] Multiple cases used to prove the same exact logic when one case already anchors the behavior and the others add no new boundary condition.
+- [SHOULD-REMOVE] Extension cases that only restate existing CQ wording without adding a change event, impact pattern, or affected-file path.
+
+## 3. Minimum Granularity Criteria
+
+A sub-classification is justified only if it satisfies at least one of the following:
+
+1. **Competency-question difference**: It changes the answer or evaluation path for at least one CQ in `competency_qs.md`.
+2. **Constraint difference**: It introduces different metrics, thresholds, authorities, or time horizons.
+3. **Dependency difference**: It changes which teams, systems, or stakeholders depend on the concept.
+
+Examples:
+- Platform governance and corporate governance remain separate because they change different authorities and CQ paths.
+- Churn and NRR remain separate because both relate to retention but diagnose different economic behavior.
+- If two customer-segmentation labels lead to the same target, same metrics, and same execution path, they should be merged.
+
+## 4. Boundaries — Domain-Specific Application Cases
+
+The authoritative source for general boundary definitions is `roles/conciseness.md`. This section only states the business-domain-specific edge cases.
+
+### pragmatics boundary
+
+- conciseness asks whether an element should exist at all.
+- pragmatics asks whether the current amount or placement of information prevents effective use.
+- Example: a dashboard with too many KPIs but still structurally legitimate is a pragmatics issue. Three different definitions of CAC is a conciseness issue.
+
+### coverage boundary
+
+- conciseness removes unjustified duplication.
+- coverage adds missing concerns, rules, or CQ anchors.
+- Example: missing supply-chain risk logic is coverage. Repeating the same supply-chain rule across three files is conciseness.
+
+### logic boundary
+
+- logic determines whether two statements are functionally equivalent or whether one entails the other.
+- conciseness decides whether one of the equivalent statements should be removed after that equivalence is established.
+- Example: if a premium position already entails premium pricing, a separate "use premium pricing" tactic may be removable.
+
+### semantics boundary
+
+- semantics determines whether two terms refer to the same concept.
+- conciseness decides whether multiple names for that concept should be consolidated.
+- Example: "recurring revenue retention" and "NRR" may be the same concept. "financial risk" and "model risk" are not.
+
+## 5. Quantitative Criteria
+
+These thresholds trigger consolidation review. They do not force deletion automatically, but they require an explicit owner or exception rationale.
+
+| Criterion | Threshold | Review Action |
+|---|---|---|
+| Same detailed case appearing in multiple files | 2+ files with 3+ sentences each | Require a declared primary owner and compress other mentions |
+| Intermediate classification with one child | 1 child | Merge unless the child changes CQ, dependency, or authority behavior |
+| Empty classification | 0 concrete instances or no landing rule | Remove or mark as reserved for future extension |
+| CQ duplication | Same target, same reasoning path, same pass/fail behavior | Merge or justify distinct scope |
+| Benchmark duplication outside registry | 1+ uncited repeated numeric definitions | Replace with a reference to `concepts.md §Benchmark Registry` |
+| Repeated threshold across CQ sections | 2+ CQ sections using the same threshold with different formulas | Normalize formula and designate one canonical interpretation |
+| Same business pattern transferred across cases with no new boundary condition | 2+ cases | Merge into one stronger case or state the new boundary condition |
+| Scale-specific rule with no changed review behavior | 1 occurrence is enough | Collapse to the broader rule and remove tier-specific wording |
+
+## Related Documents
+
+- `concepts.md §Benchmark Registry` and `concepts.md §Homonyms Requiring Attention` — canonical numeric authority and concept-boundary checks used in duplication review
+- `structure_spec.md §Business System Required Elements` and `structure_spec.md §Authority and Responsibility Separation` — structural elements used to detect unjustified duplication of roles, systems, or hierarchies
+- `competency_qs.md §4. Revenue and Cost Structure (CQ-RC)` and `competency_qs.md §13. Scalability and Adaptation (CQ-SC)` — CQ sections used to test whether a distinction creates a real verification difference
+- `dependency_rules.md §Source of Truth Management` and `dependency_rules.md §Platform Dependency Chains` — authority and dependency rules that justify some reference copies
+- `logic_rules.md §Constraint Conflict Checking` and `logic_rules.md §Transfer Patterns` — rule sections used to test whether repeated statements are actually distinct or just rephrasings

package/.onto/domains/business/dependency_rules.md

@@ -0,0 +1,113 @@
+---
+version: 2
+last_updated: "2026-03-31"
+source: manual
+status: established
+---
+
+# Business Domain — Dependency Rules
+
+This document defines the directional dependencies that make business systems executable rather than merely descriptive.
+
+## Strategy-Execution Dependency
+
+- Strategic objective -> execution program: a strategic claim that does not map to a concrete program, project, or operating change is not execution-ready.
+- Execution program -> resource allocation: a program without budget, people, and time allocation is not a real commitment.
+- Resource allocation -> KPI system: any committed resource should have a measurement logic that makes its performance visible.
+- KPI system -> strategic feedback: KPI results must be able to trigger continuation, revision, or abandonment of the original strategic objective.
+- Portfolio logic -> business-unit logic: when multiple businesses or product lines exist, resource allocation must state whether optimization is local or portfolio-wide.
+
+## Strategy-Marketing Dependency
+
+- Competitive posture -> STP: cost leadership, differentiation, or focus should constrain who is targeted and what evidence is used to persuade them.
+- STP -> marketing mix: positioning is upstream of price, channel, and promotional tone.
+- Marketing promise -> customer journey: a promise without a delivery path or onboarding logic is not commercially complete.
+- Brand strategy -> pricing and channel discipline: premium positioning can be destroyed by channels or discounts that contradict the intended signal.
+- Acquisition motion -> retention logic: rapid customer acquisition without an explicit retention or service path can create growth optics with weak economics.
+
+## Finance-Strategy Dependency
+
+- Investment criteria -> strategic option selection: strategies that require capital should state the decision rule that allowed the capital to be committed.
+- Capital structure -> investment hurdle rate: financing choices determine the relevant discount rate and acceptable return level.
+- Cash-flow planning -> operating scope: liquidity constraints should visibly limit rollout speed, hiring pace, or inventory intensity.
+- Unit economics -> scale decision: if contribution margin is negative, scale should not be treated as the primary fix unless there is a clearly stated transition mechanism.
+- Transition economics -> strategic resilience: subscription shifts, pricing changes, and platform subsidy phases should state how temporary financial pain is financed.
+
+## Organization-Strategy Dependency
+
+- Strategy type -> structure type: efficiency-oriented strategies need repeatable control; exploration-oriented strategies need flexibility and faster adjustment.
+- Structure type -> decision speed: deeper hierarchy and stronger control reduce local autonomy and response speed unless escalation design compensates.
+- Delegation -> monitoring -> incentive design: these three must be designed together, not sequentially.
+- Leadership model -> change capacity: the way leaders allocate authority directly affects whether change management is realistic or ceremonial.
+- Multi-business-unit scope -> control model: once the business diversifies, local optimization and enterprise governance can no longer be treated as the same layer.
+
+## Change Management Circular Dependency
+
+- New technology or process -> cooperation requirement -> first success -> broader adoption -> more cooperation forms a circular structure that must be entered intentionally.
+- Entry options include executive sponsorship, a narrow pilot, or an external proof point, but the chosen entry should match the real source of resistance.
+- If the business depends on short-term wins to persuade the organization, it must also show how those wins will be translated into the next adoption step.
+- If cooperation depends on incentives, the business should show which role controls those incentives.
+- A change initiative without an entry rule is effectively blocked before it starts.
+
+## Organization-Process Dependency
+
+- Organization change -> process redesign: changing reporting lines or decision rights should trigger process review, not just org-chart updates.
+- Process automation -> role redesign: automated work changes staffing, escalation, and accountability, not only labor hours.
+- Competency model -> hiring and development criteria: if competency definitions change, role qualification logic should change as well.
+- Decision authority -> execution responsibility: either one without the other creates bottlenecks or unmanaged risk.
+- Growth in scale -> information flow design: more layers require deliberate reporting and exception routing, or decisions slow down invisibly.
+
+## Operations-Quality Dependency
+
+- Throughput goals -> bottleneck investment: capacity investment should follow the bottleneck rather than local convenience.
+- Lean or Six Sigma initiative -> baseline and target metric: improvement programs need explicit measurement anchors.
+- Supply chain design -> risk posture: supplier concentration, geography, lead-time variance, and inventory policy should connect to risk response logic.
+- Quality system -> customer promise: premium positioning or regulated offerings require stronger quality controls than commodity operations.
+- Automation quality -> exception handling: the faster the automated process, the more important the exception path becomes.
+
+## Governance-ESG Relationship
+
+- Governance and ESG are separate but linked. Governance defines who decides and who oversees; ESG defines which stakeholder impacts are managed and disclosed.
+- Legal obligations outrank voluntary commitments unless a voluntary framework has been contractually or regulatorily adopted.
+- Board or oversight changes should trigger ESG-responsibility review when sustainability claims depend on governance ownership.
+- ESG disclosure changes should trigger governance review when new oversight, assurance, or data-control responsibilities are introduced.
+- Green claims, social claims, or impact claims without underlying control ownership should be treated as structurally weak.
+
+## M&A Dependency
+
+- Key-structure compatibility of finance, customer, product, and operations systems is a prerequisite to integration quality.
+- If identifiers are incompatible, the business should name whether it will use mapping tables, parallel-run phases, or canonical-key replacement.
+- Governance integration should specify which approval rights and control structures move first and which remain transitional.
+- Culture integration depends on stakeholder reconciliation, not only process integration.
+- The intended target structure after integration should be stated; otherwise the business is only describing coexistence, not integration.
+
+## Source of Truth Management
+
+- Financial facts should point to the authoritative ledger or finance system.
+- Strategic decisions should point to the approving body or decision record rather than a slide deck summary alone.
+- KPI values should point to one measurement system and one refresh cadence.
+- Customer, product, and supplier master data should each name a primary authority when multiple systems exist.
+- When a source of truth changes, dependent references must be updated as a migration, not opportunistically. Partial authority changes create silent conflict.
+
+## Platform Dependency Chains
+
+- Participant growth on one side depends on perceived value on the other side. Marketplace growth is therefore a two-sided dependency chain, not a single-funnel problem.
+- Take-rate changes depend on liquidity, trust, and side-specific surplus. Monetization cannot be changed independently of participant economics.
+- Governance rules depend on enforcement tools, appeal paths, and moderation capacity. Policy text without operating enforcement is not a real dependency closure.
+- Trust and safety incidents can break growth, monetization, and brand at once. Platform governance is upstream of multiple business outcomes.
+- Multi-homing reduces switching dependence and increases the importance of differentiated workflow, demand quality, or service tools.
+
+## AI/Data Dependency
+
+- AI output quality depends on data access, data quality, model choice, prompt or workflow design, and review process together.
+- Data rights are upstream of AI monetization. If reuse rights are unclear, the commercial model is unstable even if the product works.
+- Model deployment depends on override and rollback design. A production AI system without a fallback path is an operational dependency gap.
+- Human review load depends on model reliability, risk tolerance, and customer expectation. Review cost should be treated as part of the operating model.
+- Regulatory exposure depends on use case, not only on the model. The same model can require different control depth across different business decisions.
+
+## Related Documents
+
+- `domain_scope.md §Major Sub-areas` and `domain_scope.md §Inter-Document Contract` — the business concerns and ownership model that these dependencies serve
+- `concepts.md §Benchmark Registry` and `concepts.md §Governance/Risk Core Terms` — source concepts and benchmark authorities referenced by these dependencies
+- `structure_spec.md §Business System Required Elements`, `structure_spec.md §Digital Business Structure`, and `structure_spec.md §Authority and Responsibility Separation` — structures that make these dependencies visible
+- `logic_rules.md §Financial Decision-Making Logic`, `logic_rules.md §Change Management Logic`, and `logic_rules.md §AI Business Logic` — rule sections that interpret the consequences of broken dependencies

package/.onto/domains/business/domain_scope.md

@@ -0,0 +1,240 @@
+---
+version: 2
+last_updated: "2026-03-31"
+source: manual
+status: established
+---
+
+# Business Domain — Domain Scope Definition
+
+This is the reference document used by coverage to identify what should exist but is missing when reviewing a business system.
+This domain applies when **reviewing** business plans, operating models, growth strategies, and management system design.
+
+## Major Sub-areas
+
+Classification axis: **management concern** — classified by the business concerns that a viable and governable business system must address.
+
+Applicability markers:
+- **(required, scale: X-Y)**: Must be addressed whenever the target falls inside the stated scale range. Absence indicates a coverage gap.
+- **(when applicable, scale: X-Y)**: Address only when the business actually uses the pattern and the target falls inside the stated scale range.
+- **(reference)**: Context provider only. Informative, not a mandatory coverage anchor.
+
+Scale handling rule:
+- If the target is `scale unknown`, review generic structure and decision logic, but do not fail the target for missing tier-specific controls until the scale input contract is satisfied.
+
+### Strategic Management
+- **Competitive Analysis** (required, scale: Micro-Large): Porter's Five Forces, substitute pressure, competitor response patterns, and market attractiveness. Micro businesses may use qualitative analysis; Mid/Large businesses should make industry structure explicit.
+- **Resource-Based Strategy** (required, scale: Micro-Large): VRIO, core capability identification, dynamic capabilities, and sustainability of advantage. Claimed data moats, ecosystem control, or brand assets must be tested for rarity and imitability, not just asserted.
+- **Growth Strategy** (required, scale: Micro-Large): Ansoff Matrix, adjacency logic, portfolio posture, and the rationale for market penetration, market development, product development, or diversification.
+- **Value Innovation** (when applicable, scale: Micro-Large): Blue Ocean strategy, strategy canvas, and ERRC logic when the business claims category creation or non-price differentiation.
+- **Business Development** (when applicable, scale: Small-Large): partnerships, channel expansion, M&A, regional expansion, and ecosystem entry. Founder-led opportunistic dealmaking in a Micro business is not treated as a full business-development system unless it is formalized.
+
+### Marketing
+- **Market Strategy** (required, scale: Micro-Large): STP, customer selection criteria, willingness-to-pay logic, and explicit target-customer rationale.
+- **Marketing Mix** (required, scale: Micro-Large): 4P or 7P alignment with the target segment, including service operations and physical evidence where relevant.
+- **Customer Management** (required, scale: Micro-Large): customer journey, conversion logic, retention design, brand equity, and feedback loops between customer behavior and strategic decisions.
+- **Digital and Growth Marketing** (when applicable, scale: Micro-Large): funnel measurement, attribution logic, experimentation, product-led growth, lifecycle messaging, and paid/organic channel mix.
+
+### Finance
+- **Investment Decision-Making** (required, scale: Micro-Large): capital budgeting, payback logic, NPV or IRR where appropriate, and explicit treatment of downside cases. Micro firms may use simpler survival-oriented screens, but capital commitments still require a decision rule.
+- **Capital Structure** (required, scale: Small-Large): cost of capital, debt-equity mix, funding strategy, and financing constraints. For Small and above, WACC or an explicit substitute discount-rate rationale should exist.
+- **Working Capital Management** (required, scale: Micro-Large): cash runway, CCC, liquidity planning, receivables/inventory/payables management, and crisis response triggers.
+- **Corporate Valuation** (when applicable, scale: Small-Large): DCF, relative valuation, scenario ranges, and value-driver assumptions for fundraising, M&A, or strategic review.
+- **Accounting Standards Reference** (reference): revenue recognition and detailed financial-statement compliance are governed by the accounting domain. This domain uses accounting outputs as decision inputs, not as the primary rule system.
+
+### Operations Management
+- **Process Optimization** (required, scale: Micro-Large): Lean, process flow clarity, waste identification, baseline measurement, and operational improvement logic.
+- **Constraint Management** (required, scale: Micro-Large): TOC, bottleneck identification, throughput logic, and avoidance of local optimization.
+- **Supply Chain Management** (when applicable, scale: Small-Large): procurement, logistics, inventory policy, supplier concentration, lead-time risk, and resilience design once direct founder coordination no longer scales.
+- **Quality Management** (required, scale: Small-Large): TQM, cost-of-quality reasoning, defect prevention, and repeatability controls. Micro businesses may apply lightweight quality checks, but formal quality systems become material as process volume rises.
+- **Automation** (when applicable, scale: Micro-Large): automation scope boundaries, baseline measurement, discrepancy adjudication authority, ROI conversion logic, and role redesign after automation.
+
+### Organization & HR
+- **Organizational Structure** (required, scale: Micro-Large): Mintzberg structure fit, reporting hierarchy, coordination mechanism, and the match between structure and strategy.
+- **Organizational Theory** (required, scale: Small-Large): Agency Theory, stakeholder alignment, incentive design, and delegated authority controls once ownership, management, and execution are no longer the same person or team.
+- **Human Resource Management** (required, scale: Small-Large): competency model, performance management, role design, succession logic, and talent pipeline for key positions.
+- **Change Management** (when applicable, scale: Small-Large): Kotter, ADKAR, sponsorship structure, short-term-win design, and circular dependency resolution between adoption and cooperation.
+- **Leadership** (when applicable, scale: Micro-Large): leadership style, delegation, culture formation, and management-system maturity.
+
+### Innovation Management
+- **Disruptive Innovation** (when applicable, scale: Micro-Large): sustaining vs. disruptive innovation, response options for incumbents, and the organizational implications of attacking non-consumption or the low end.
+- **Technology Adoption** (when applicable, scale: Micro-Large): Technology Adoption Lifecycle, Chasm strategy, whole-product design, and adoption-risk segmentation.
+- **Design Thinking** (when applicable, scale: Micro-Large): user research, problem framing, prototyping, and iteration where uncertainty is customer-need driven.
+- **R&D Management** (when applicable, scale: Small-Large): technology roadmaps, innovation portfolio balancing, open-innovation interfaces, and governance of experimentation spend.
+
+### Governance & Risk
+- **Corporate Governance** (required, scale: Mid-Large): board or equivalent oversight, internal controls, audit logic, escalation design, and separation between decision rights and control rights.
+- **Risk Management** (required, scale: Micro-Large): risk identification, response strategy, residual-risk ownership, and crisis escalation. COSO-style formalization becomes more explicit with scale, but risk blindness is a gap at every size.
+- **Business Law** (required, scale: Micro-Large): contracts, regulatory compliance, intellectual property, labor obligations, and legal constraints on growth or automation.
+- **ESG** (when applicable, scale: Small-Large): environmental and social disclosure obligations, stakeholder-impact management, and the boundary between governance structures and sustainability claims.
+
+### Modern Extensions
+- **Platform Business** (when applicable, scale: Micro-Large): multi-sided markets, network effects, take rate logic, participant governance, and cross-side incentive balance.
+- **Subscription Economy** (when applicable, scale: Micro-Large): MRR/ARR, churn, retention cohorts, LTV/CAC, pricing resets, and J-curve transition management.
+- **AI Business** (when applicable, scale: Micro-Large): data moat claims, model economics, AI product design, explainability, appeal paths, and regulatory exposure for algorithmic decisions.
+
+## Required Concept Categories
+
+These categories must be available somewhere in the business knowledge system.
+
+| Category | Description | Risk if Missing |
+|---|---|---|
+| Revenue model | Revenue generation structure, pricing system, and unit of monetization | No basis for commercial viability |
+| Cost structure | Fixed/variable cost logic, cost attribution, and operating leverage | Profitability cannot be tested |
+| Value proposition | The concrete customer benefit and differentiation logic | Market fit is unverified |
+| Competitive strategy | Industry position, advantage source, and growth direction | Strategic choices lack basis |
+| Risk management | Risk register, response design, and residual-risk ownership | Shocks cannot be absorbed or escalated properly |
+| Performance measurement | KPI definitions, cadence, and leading/lagging split | Improvement cannot be directed or verified |
+| Organization design | Decision rights, reporting hierarchy, and execution ownership | Strategy cannot be executed consistently |
+| Source of truth | The designated authority when strategic, financial, or operational data conflicts | Decisions will be made on inconsistent facts |
+
+## Reference Standards/Frameworks
+
+| Standard/Framework | Application Area | Core Content | When to Apply |
+|---|---|---|---|
+| Porter's Five Forces | Strategic management | Industry structure and competitive intensity analysis | Any strategy review with external competition |
+| VRIO | Strategic management | Sustainability test for resources and capabilities | When advantage claims are made |
+| Ansoff Matrix | Growth strategy | Product-market growth directions | When growth direction or adjacency expansion is reviewed |
+| Business Model Canvas | Business model design | Nine-block business model framing | When revenue logic or operating model needs explicit articulation |
+| Balanced Scorecard | Performance management | Financial, customer, internal process, and learning perspectives | Small-Large organizations with formal KPI systems |
+| Lean / TPS | Operations management | Waste elimination and flow improvement | Any process-improvement review |
+| Six Sigma / DMAIC | Quality and process improvement | Variation reduction through measurement-driven improvement | Mid-Large operating environments with repeatable processes |
+| Theory of Constraints | Operations management | Throughput focus via bottleneck management | When flow constraints or capacity saturation exist |
+| Kotter's 8 Steps / ADKAR | Change management | Organizational change sequencing and adoption readiness | When adoption depends on organizational cooperation |
+| COSO ERM | Governance and risk | Enterprise risk management structure | Small-Large risk-system design; most formal at Mid-Large |
+| GRI / SASB / ISSB | ESG | Sustainability disclosure and reporting frameworks | When ESG disclosure or stakeholder-impact reporting exists |
+| SaaS Metrics | Subscription business | MRR, ARR, churn, NRR, LTV/CAC | When recurring-revenue models are present |
+
+## Scale Tier Definitions
+
+Scale is determined by employee count only. Lifecycle signals are tracked separately and never override tier assignment.
+
+| Scale State | Employee Count Rule | Review Meaning | Typical Coordination Pattern |
+|---|---|---|---|
+| scale unknown | No verified employee-count evidence | Tier-sensitive conclusions must be deferred or downgraded | Generic structure review only |
+| Micro | `[1,10)` | Very small operating organization | Direct coordination, founder-centered execution |
+| Small | `[10,100)` | Functionally differentiated small business | Emerging specialization and repeatable processes |
+| Mid | `[100,1000)` | Formally managed organization | Delegated authority, explicit coordination systems |
+| Large | `[1000,∞)` | Enterprise-scale organization | Cross-business-unit governance and formal control systems |
+
+Interpretation rules:
+- Use the half-open intervals exactly as written.
+- `0 employees`, founder-only entities, or targets with no verified headcount remain `scale unknown`.
+- `pre_revenue`, `founder_led`, `regulated_business`, `single_product`, and `multi_business_unit` are lifecycle or context flags, not scale tiers.
+- Tier-sensitive checks may produce `SKIP-scale` or `SKIP-scale-unknown`, but generic review of structure, decision rights, and economic logic should still proceed.
+
+### Scale Assessment Input Contract
+
+| Field | Requirement | Notes |
+|---|---|---|
+| `employee_count` or `employee_count_range` | Required for deterministic tiering | Exact count preferred; a range is acceptable only if it resolves to one tier |
+| `as_of` | Required | Headcount is time-sensitive |
+| `source` | Required | User statement, filing, org chart, HR source, or equivalent |
+| `confidence` | Recommended | `high`, `medium`, or `low` |
+| `lifecycle_flags` | Optional | `pre_revenue`, `founder_led`, `multi_business_unit`, `regulated_business`, etc. |
+
+Resolution rules:
+- If evidence spans multiple tiers, keep `scale unknown`.
+- If sources conflict, prefer the narrower range from the stronger source; otherwise keep `scale unknown`.
+- Lifecycle flags refine interpretation but do not change the scale state.
+
+## Bias Detection Criteria
+
+- If 3 or more of the major sub-areas are missing entirely -> **insufficient coverage**
+- If one area accounts for more than 70% of the content -> **area bias**
+- If the revenue model exists with no cost structure -> **revenue-cost imbalance**
+- If strategy exists with no execution path or operating consequences -> **execution path absence**
+- If only qualitative goals exist with no measurable indicators -> **unmeasurable warning**
+- If strategy is stated without competitive analysis -> **strategy basis absence**
+- If relevant modern extensions (platform, subscription, AI) are missing for an applicable business model -> **modern business model blind spot**
+- If 2 or more key data items have no designated source of truth -> **undesignated authority**
+- If execution plans exist with no organization design or decision owner -> **execution owner unclear**
+- If multiple normative systems (law, industry standard, self-regulation) apply but priority is unspecified -> **normative priority absence**
+- If mandatory norms and voluntary norms are applied with the same force -> **normative strength confusion**
+- If KPI targets exist but no qualitative judgment principle exists for conflict resolution -> **qualitative judgment absence**
+- If platform participant rules are set unilaterally with no governance or appeal path -> **platform governance bias**
+- If AI decisions have no explainability, contestability, or override path -> **algorithmic accountability absence**
+- If subscription changes (pricing, downgrade, cancellation) ignore customer-impact analysis -> **subscriber impact not evaluated**
+- If Mid/Large control frameworks are applied to Micro/Small targets without adaptation -> **scale mismatch (over-application)**
+- If Mid/Large organizations are reviewed only with Micro/Small informal heuristics -> **scale mismatch (under-formalization)**
+- If a tier-sensitive judgment is made without verified employee-count evidence -> **scale context unverified**
+
+## Inter-Document Contract
+
+This section declares which file owns which cross-cutting topic so that the business domain can expand without duplicating rules or leaving orphan concepts.
+
+### Rule Ownership
+
+| Cross-cutting Topic | Owner File | Other Files |
+|---|---|---|
+| Concept definitions | `concepts.md` | All other files reference, do not redefine |
+| Financial decision-making rules | `logic_rules.md §Financial Decision-Making Logic` | `dependency_rules.md` references only |
+| Strategy analysis rules | `logic_rules.md §Strategy Analysis Logic` | `structure_spec.md` references only |
+| Organizational structure rules | `structure_spec.md §Organization-Strategy Fit` | `logic_rules.md` references only |
+| Dependency chain rules | `dependency_rules.md` | `structure_spec.md` references only |
+| Source-of-truth designation | `dependency_rules.md §Source of Truth Management` | `structure_spec.md` references only |
+| Competency questions | `competency_qs.md` | Other files provide inference-path targets |
+| Conciseness criteria | `conciseness_rules.md` | Other files reference only |
+| Extension scenarios | `extension_cases.md` | `competency_qs.md` provides one-way CQ linkage |
+| Benchmark registry | `concepts.md §Benchmark Registry` | Other files reference with `as_of` metadata |
+| Change management rules | `logic_rules.md §Change Management Logic` | `dependency_rules.md §Change Management Circular Dependency` |
+| Platform business rules | `logic_rules.md §Platform Business Logic` | `structure_spec.md §Digital Business Structure` |
+| Automation scope rules | `logic_rules.md §Operations Management Logic` | `dependency_rules.md §Organization-Process Dependency` |
+| Supply-chain and operations-quality rules | `dependency_rules.md §Operations-Quality Dependency` | `logic_rules.md §Operations Management Logic` |
+| ESG relationship rules | `dependency_rules.md §Governance-ESG Relationship` | `concepts.md §Governance/Risk Core Terms`; `competency_qs.md` references only |
+| Scale tier definitions and applicability ranges | `domain_scope.md §Scale Tier Definitions` | `competency_qs.md` and coverage planning inherit only |
+| Bias detection criteria | `domain_scope.md §Bias Detection Criteria` | `competency_qs.md` may consume as warnings only |
+
+### Required Substance per Sub-area
+
+Each sub-area declared in `§Major Sub-areas` must have corresponding substance in at least one of:
+- `concepts.md`: term definitions and interpretation anchors
+- `logic_rules.md`, `structure_spec.md`, or `dependency_rules.md`: operational rules and structural constraints
+- `competency_qs.md`: verification questions
+
+A declared sub-area with no substance in any of those files is a **ghost sub-area** and must either be populated or explicitly narrowed by applicability.
+
+### Cross-cutting Concern Attribution
+
+When a concern spans multiple sub-areas, attribute it to the sub-area with the **primary enforcement point**:
+
+1. The primary enforcement point is the sub-area whose rules would be violated if the concern were ignored.
+2. Other sub-areas should reference the primary rule rather than redefine it.
+3. If enforcement is genuinely split, attribute the concern to the area with the fewer existing items and cross-reference the rest.
+
+### Classification Axis Relationships
+
+The business domain uses three related concern axes. They are facets of the same system, not separate taxonomies.
+
+| File | Axis | Facet |
+|---|---|---|
+| domain_scope.md | management concern | What business concerns exist |
+| logic_rules.md / structure_spec.md / dependency_rules.md | operational concern | What rules govern those concerns |
+| competency_qs.md | verification concern | What must be answerable during review |
+
+### Sub-area to CQ Section Mapping
+
+| Sub-area | CQ Sections | Coverage |
+|---|---|---|
+| Strategic Management | CQ-SM | Full |
+| Marketing | CQ-MK | Full |
+| Finance | CQ-FI | Core financial decision-making |
+| Operations Management | CQ-OP | Full |
+| Organization & HR | CQ-OH | Core organizational design |
+| Innovation Management | CQ-IN | Full |
+| Governance & Risk | CQ-GR | Full |
+| Modern Extensions — Platform | CQ-PL | Focused |
+| Modern Extensions — Subscription | CQ-SB | Focused |
+| Modern Extensions — AI Business | CQ-AB | Focused |
+
+Cross-cutting CQ sections:
+- `CQ-RC` spans Finance + Marketing + Modern Extensions where pricing, unit economics, and return attribution intersect.
+- `CQ-CM` spans Organization & HR + Operations Management + Innovation Management where change crosses structure, process, and adoption.
+- `CQ-SC` spans Strategic Management + Governance & Risk + extension events such as M&A, regional expansion, and business-model transfer.
+
+## Related Documents
+
+- `concepts.md §Strategic Management Core Terms` and `concepts.md §Governance/Risk Core Terms` — canonical concept definitions for this scope
+- `structure_spec.md §Business System Required Elements` and `structure_spec.md §Authority and Responsibility Separation` — structural requirements implied by this scope
+- `dependency_rules.md §Source of Truth Management` and `dependency_rules.md §Governance-ESG Relationship` — dependency and authority rules consumed by this scope
+- `competency_qs.md §3. Finance (CQ-FI)` and `competency_qs.md §9. Governance and Risk (CQ-GR)` — verification entry points that consume this scope