onto-mcp 0.3.0

package/.onto/domains/finance/conciseness_rules.md

@@ -0,0 +1,155 @@
+---
+version: 1
+last_updated: "2026-03-29"
+source: bundled-domain-baseline
+status: established
+---
+
+# Conciseness Rules (finance)
+
+This document contains the domain-specific rules that conciseness references during conciseness verification.
+It is organized in the order: **type (allow/remove) -> verification criteria -> role boundaries -> measurement methods**.
+
+---
+
+## 1. Allowed Redundancy
+
+Each rule is tagged with a severity level:
+- **[MUST-ALLOW]**: Redundancy that breaks the system if removed. Must be retained.
+- **[MAY-ALLOW]**: Redundancy kept for convenience. Can be consolidated, but only remove when the benefit clearly outweighs the consolidation cost.
+
+### Reporting Unit Related
+
+- [MUST-ALLOW] Parallel consolidated and separate financial statements — the same account (e.g., revenue) exists in both consolidated and separate bases. The consolidated scope includes subsidiary aggregation and intercompany elimination, so the figures and meaning differ from separate. Removing either makes inter-reporting-unit comparison and consolidation adjustment verification impossible.
+- [MUST-ALLOW] Parallel segment reporting and consolidated totals — segment-level revenue and operating income are components of consolidated totals, but intercompany transactions between segments and unallocated items mean they do not simply sum to the total. Removing segment figures makes divisional performance analysis impossible.
+
+### Temporal Attribute Related
+
+- [MUST-ALLOW] Dual classification of instant/duration attributes — even for the same account, instant (point-in-time) and duration (period) items have different temporal attribution. Example: Cash and cash equivalents is expressed as instant (closing balance) on the Statement of Financial Position and as duration (period change) on the Cash Flow Statement. Consolidating into a single attribute causes loss of temporal dimension information.
+- [MAY-ALLOW] Parallel presentation of opening and closing balances for Statement of Financial Position items — prior period-end (opening) and current period-end (closing) balances are displayed simultaneously for comparison purposes. The same figures can be referenced from prior period financial statements, but retain for comparison readability purposes.
+
+### Account Classification Related
+
+- [MUST-ALLOW] Dual existence of the same account due to current/non-current classification — other financial assets split into current and non-current are separate Facts because their maturity/recovery periods differ. Consolidation makes liquidity analysis impossible.
+- [MAY-ALLOW] Parallel presentation of labels and taxonomy element IDs — the taxonomy element ID is the primary identifier, but labels are retained for human readability. If only labels exist without taxonomy IDs, they are removal targets.
+
+### External Reference Related
+
+- [MUST-ALLOW] Parallel IFRS taxonomy mapping and FIBO mapping — the same concept is mapped to both IFRS taxonomy and FIBO. The two standards have different purposes (financial reporting vs. financial industry ontology) and structures, so they cannot be consolidated into a single mapping.
+- [MAY-ALLOW] Parallel company extension accounts and standard taxonomy accounts — per the original preservation principle, company-specific labels are retained while also mapped to canonical names. However, if the extension account is completely identical to the standard account with no additional information, consolidation is possible.
+
+---
+
+## 2. Removal Target Patterns
+
+Each rule is tagged with a severity level:
+- **[MUST-REMOVE]**: Redundancy whose mere existence causes errors or incorrect inferences.
+- **[SHOULD-REMOVE]**: Redundancy that is not very harmful but adds unnecessary complexity.
+
+### Taxonomy Redundancy
+
+- [MUST-REMOVE] Duplicate definition of multiple labels for the same taxonomy element as separate concepts — when several labels (e.g., "Revenue," "Sales," "Operating revenue") for a single taxonomy element ID are registered as separate concepts, use the synonym mappings in concepts.md to retain only the canonical name. Treating multiple labels as separate concepts causes double-counting in aggregation and comparison.
+- [MUST-REMOVE] Creating extension accounts that duplicate accounts already existing in the standard taxonomy — when an extension element exists with the same meaning and constraints as a standard element, mapping inconsistencies arise. Use the standard element first.
+
+### Relation Redundancy
+
+- [MUST-REMOVE] Multiple path aggregation between the same accounts — example: when both a current assets subtotal -> total assets path and individual current asset items -> total assets direct path exist simultaneously, aggregation logic is applied twice, causing amount inconsistencies.
+- [SHOULD-REMOVE] Explicit redeclaration of relationships already guaranteed by accounting identities — when Assets = Liabilities + Equity is guaranteed in logic_rules.md, there is no need to separately redefine "equity is assets minus liabilities" as a separate relationship on individual nodes.
+
+### Classification Redundancy
+
+- [SHOULD-REMOVE] Intermediate classification nodes with only 1 child account — example: when only a single item exists under "Other non-current assets," merge the intermediate node with the parent. However, retain if reserved for future expansion (see extension_cases.md).
+- [SHOULD-REMOVE] Classification nodes with no actual amount data (Facts) — empty account classifications unused by any reporting entity should be removed. However, retain if they are mandatory elements of the standard taxonomy.
+
+### Definition Redundancy
+
+- [MUST-REMOVE] Multiple calculation path definitions for the same derived metric — example: when ROE is simultaneously defined as "net income / total equity" and "net income / average equity," the results differ. Designate one definition as the authoritative version.
+- [SHOULD-REMOVE] Same verification logic (e.g., identity verification) copied across multiple financial statement modules — extraction to a common verification module is needed.
+
+---
+
+## 3. Minimum Granularity Criteria
+
+A sub-classification is permitted only if it satisfies **at least one** of the following. If none are satisfied, merge with the parent.
+
+1. **Competency question difference**: Does it generate a different answer to a question in competency_qs.md?
+2. **Constraint difference**: Do different constraints (temporal attribute, current/non-current classification, normal balance direction, cardinality) apply?
+3. **Dependency difference**: Does it belong to a different financial statement, segment, or reporting unit, or map to a different taxonomy element?
+
+Examples:
+- `Current other financial assets` and `Non-current other financial assets` are justified as separate classifications because different constraints (1-year maturity criterion, liquidity classification) apply.
+- If `Total assets` and `Assets total` both map to the same taxonomy element (ifrs:Assets) with the same constraints, they are candidates for merging.
+
+---
+
+## 4. Boundaries — Domain-Specific Application Cases
+
+The authoritative source for boundary definitions is `roles/conciseness.md`. This section describes only the specific application cases in the finance domain.
+
+### pragmatics boundary
+
+- conciseness: Does an unnecessary element **exist**? (structural level)
+- pragmatics: Does unnecessary information **hinder** query execution? (execution level)
+- Example: Unused note items are included in financial statement query responses -> pragmatics. Unused accounts are defined in the taxonomy structure -> conciseness.
+
+### coverage boundary
+
+- conciseness: Does something exist that should not? (reduction direction)
+- coverage: Is something missing that should exist? (expansion direction)
+- Example: Notes system is missing, making accounting policy disclosure impossible -> coverage. The same accounting policy is duplicated across multiple notes -> conciseness.
+
+### logic boundary (predecessor/successor relationship)
+
+- logic predecessor: determines logical equivalence (entailment)
+- conciseness successor: decides whether to remove after equivalence is confirmed
+- Example: The accounting identity (Assets = Liabilities + Equity) already entails the definition of equity -> logic determines equivalence -> conciseness determines "separate calculation relationship redeclaration for equity is unnecessary."
+
+### semantics boundary (predecessor/successor relationship)
+
+- semantics predecessor: determines semantic identity (synonym status)
+- conciseness successor: decides whether merging is needed after synonym confirmation
+- Example: "Revenue"/"Sales"/"Operating revenue" are the same taxonomy element -> semantics determines they are synonyms -> conciseness determines "consolidate to a single canonical name."
+
+---
+
+## 5. Quantitative Criteria
+
+Domain-observed thresholds for conciseness judgment. Each threshold is a review signal, not an automatic removal trigger.
+
+### Taxonomy Redundancy Thresholds
+
+- **Multiple labels per element**: same taxonomy element ID with 3+ different labels → consolidate to canonical name. Two labels may reflect legitimate regional variation; three almost certainly duplicates. (concepts.md §Core Synonym Mappings)
+- **Extension account ratio**: if >30% of an entity's accounts are extensions, review for over-extension. Many extensions may map to existing standard elements. (concepts.md §Extension Account Handling)
+- **Unused standard elements**: if >50% of standard taxonomy elements in a jurisdiction have zero usage across all entities → informational (valid placeholders, not removal targets)
+
+### Structural Redundancy Thresholds
+
+- **Intermediate hierarchy nodes**: node with exactly 1 child for >2 reporting periods → merge candidate. Exception: reserved by taxonomy standard
+- **Duplicate aggregation paths**: if the same account is reachable through 2+ aggregation paths → review for path consolidation. One canonical path must be designated
+- **Orphan notes**: notes extracted but linked to zero FinancialFacts → review for linkage error or removal. Notes from unstructured sources are most prone to this
+
+### Derived Metric Redundancy
+
+- **Multiple formula definitions**: same derived metric (e.g., ROE) defined with 2+ different formulas → consolidate to one authoritative definition. Document the formula choice rationale. (logic_rules.md §Derived Metric Calculation Rules)
+- **Cached vs computed metrics**: if a derived metric is stored both as a precomputed value and computable from underlying data → prefer on-demand computation. Store only when computation cost is prohibitive
+
+### Cross-Tier Duplication
+
+- **Tier-2/Tier-3 overlap**: same metric defined as both a taxonomy element (Tier-2) and an analytical convention (Tier-3) → consolidate to Tier-2 when the taxonomy element matches exactly. Retain Tier-3 separately only when the computation differs (e.g., "adjusted EBITDA" vs taxonomy operating income)
+
+### Review Output Conciseness
+
+- **Finding deduplication**: 3+ findings citing the same root cause (e.g., multiple extension accounts mapping to the same standard element) → consolidate into 1 finding with root cause + all affected accounts
+- **Cross-file deduplication**: issue flagged by both conciseness and a preceding agent (logic or semantics) → defer to the preceding agent's finding; add only the consolidation recommendation
+
+---
+
+## Related Documents
+
+- `concepts.md` — Term definitions, synonym mappings, homonym lists, extension account handling (semantic criteria for redundancy determination)
+- `structure_spec.md` — Isolated node rules, required relationships, ID system (structural removal criteria)
+- `competency_qs.md` — CQ-ID sections for minimum granularity judgment
+- `domain_scope.md` — Normative system classification (Tier system), cross-cutting concerns
+- `dependency_rules.md` — External standard reference rules, source of truth management (basis for allowing parallel mappings)
+- `logic_rules.md` — Accounting identities, derived metric formulas (criteria for logical equivalence determination)
+- `extension_cases.md` — Taxonomy change and extension account scenarios (basis for classification node retain/remove decisions)

package/.onto/domains/finance/dependency_rules.md

@@ -0,0 +1,171 @@
+---
+version: 2
+last_updated: "2026-04-16"
+source: manual
+status: established
+---
+
+# Finance Domain — Dependency Rules
+
+Classification axis: **Dependency type** — rules classified by the nature of the relationship constraint.
+
+## Acyclic Rules
+
+No cycles are permitted in these relationship paths. Cycles indicate structural defects in the ontology.
+
+| ID | Rule | Description | Violation Handling |
+|---|---|---|---|
+| AC01 | No cycles in Entity → Statement → FinancialFact path | Unidirectional from reporting entity to financial figures | Block |
+| AC02 | No cycles in Concept hierarchy | Superordinate account → subordinate account hierarchy | Block |
+| AC03 | No cycles in Note → FinancialFact references | Notes reference main statements; main statements do not back-reference notes | Block |
+| AC04 | No cycles in Segment → Entity attribution | Segments belong to entities; entities do not belong to segments | Block |
+
+> **AC03 rationale:** Notes explain and supplement main statement items. If main statements referenced notes, a circular dependency would arise: the meaning of a figure depends on a note that depends on the figure. Notes annotate; figures do not annotate notes.
+
+### Intentional Bidirectional Patterns (Not Cycles)
+
+- **FinancialFact ↔ Period:** A Fact belongs to a Period (IN_PERIOD); a Period contains many Facts. This is a managed 1:N relationship, not a cycle. The Period is the source of truth for temporal context
+- **Concept ↔ FinancialFact:** A Concept defines the meaning (HAS_CONCEPT); many Facts instantiate the Concept. The Concept is the source of truth for semantics
+- **Cross-Statement Appearance:** Cash and cash equivalents appears in both BS and CF. This is intentional (DM01 allows it) — the same Fact can belong to multiple Statements
+
+## Direction Rules
+
+| ID | Relationship | Allowed Direction | Prohibited Direction | Violation Handling |
+|---|---|---|---|---|
+| DR01 | REPORTED_BY | Fact → Entity | Entity → Fact | Block |
+| DR02 | BELONGS_TO | Fact → Statement | Statement → Fact | Block |
+| DR03 | HAS_CONCEPT | Fact → Concept | Concept → Fact | Block |
+| DR04 | IN_PERIOD | Fact → Period | Period → Fact | Block |
+| DR05 | ANNOTATES | Note → Fact | Fact → Note | Block |
+| DR06 | IS_CHILD_OF | Child Concept → Parent Concept | — | Warning |
+| DR07 | DISCLOSES_POLICY | Note → Policy | Policy → Note | Block |
+| DR08 | IN_SEGMENT | Fact → Segment | Segment → Fact | Block |
+| DR09 | PART_OF | Segment → Entity | Entity → Segment | Warning |
+
+> **DR06 Warning:** The reverse direction (Parent → Child, i.e., HAS_CHILD) can be separately defined as a convenience relationship. It is not prohibited, but it must be derived from IS_CHILD_OF, not independently maintained. Independent maintenance creates synchronization risk.
+
+### Direction Rule Rationale
+
+The direction rules encode the ontology's semantic model:
+- **Facts are attributed** (to entities, statements, concepts, periods) — they are the "leaf" data
+- **Notes annotate** (facts and policies) — they provide supplementary context
+- **Concepts classify** (facts) — they define what the fact represents
+- **Segments partition** (facts within an entity) — they provide dimensional analysis
+
+Reversing any direction would change the semantic relationship. "Revenue is reported by Samsung" ≠ "Samsung is reported by Revenue."
+
+## Diamond Rules
+
+| ID | Situation | Allowed? | Rationale |
+|---|---|---|---|
+| DM01 | Same Fact belongs to multiple Statements | **Allowed** | Cash appears in both BS and CF — this is correct per IFRS |
+| DM02 | Same Concept used by multiple Entities | **Allowed** | ifrs:Revenue is shared across all companies — the concept is universal |
+| DM03 | Same Fact attributed to multiple Periods | **Prohibited** | A single financial figure belongs to exactly one period/point-in-time. Multiple periods = data duplication error |
+| DM04 | Same Fact attributed to multiple Entities | **Prohibited** | A fact is reported by one entity. Intercompany items are separate facts with separate entity attribution |
+| DM05 | Same Concept appears at multiple hierarchy levels | **Prohibited** | A concept has one parent in the hierarchy. Multiple parents = taxonomy structure error |
+
+### DM01 Resolution Protocol
+
+When the same Fact appears in multiple Statements (e.g., cash in BS and CF):
+- The Fact node is created once
+- Multiple BELONGS_TO edges point to different Statement nodes
+- The values must be identical — if BS cash ≠ CF closing cash, this is a cross-statement linkage violation (XL02 in logic_rules.md)
+
+## Referential Integrity
+
+| ID | Rule | Description | Violation Handling |
+|---|---|---|---|
+| RI01 | FinancialFact's HAS_CONCEPT target must exist | Referencing a non-existent account is prohibited | Block |
+| RI02 | Note's ANNOTATES target must exist | Referencing a non-existent note target is prohibited | Block |
+| RI03 | Temporary IDs treated as "warning" until converted to canonical | Reflects ID instability from unstructured sources | Warning |
+| RI04 | Period node must have valid date format (ISO 8601) | Start/end dates must be parseable and logically consistent | Block |
+| RI05 | Entity code must be a recognized identifier (stock code, LEI, etc.) | Prevents orphan entities without external linkage | Warning |
+
+> **RI03 real-world context:** Notes extracted from PDFs via OCR may not have stable identifiers across different extraction runs. Temporary IDs are assigned during extraction. When the same note is obtained from a structured source (XBRL), convert to the canonical ID and elevate to Block level (same as RI02).
+
+### Referential Integrity Verification Pipeline
+
+1. **At ingestion:** RI01 (concept exists), RI04 (date valid), RI05 (entity recognized)
+2. **After normalization:** RI03 upgrade (temporary → canonical IDs)
+3. **At query time:** RI02 (note targets exist), cross-statement consistency
+4. **Periodic audit:** orphan node detection (structure_spec.md §Isolated Node Prohibition)
+
+## Source Dependencies
+
+### Source of Truth Transition Rules
+
+| Priority | Source Type | Condition | Description | Data Quality |
+|---|---|---|---|---|
+| 1 | Structured (XBRL, API) | Structure complete and parsing successful | Machine-readable, taxonomy-tagged | Highest |
+| 2 | Semi-structured (HTML, tables) | Structured source incomplete or parsing failed | Requires parsing/extraction | Medium |
+| 3 | Unstructured (PDF, images) | Semi-structured not available | Requires OCR/NLP extraction | Lowest |
+
+- Source transitions are common: structured XBRL may be incomplete (e.g., notes not tagged), requiring fallback to semi-structured HTML or unstructured PDF for supplementary data
+- **SPOF risk:** When semi-structured is the sole source for a critical data element, a single parsing failure produces complete data loss. Mitigation: maintain at least 2 extraction methods for critical items
+- **ID system unification** must precede source transitions — if different sources assign different IDs to the same concept, referential integrity breaks during transition
+
+### Source Quality Metadata
+
+Every FinancialFact should carry source metadata:
+- **source_type:** XBRL / HTML / PDF / API
+- **source_confidence:** high (structured) / medium (semi-structured) / low (unstructured)
+- **extraction_date:** when the data was extracted
+- **filing_id:** the specific regulatory filing the data came from
+- **audit_status:** audited / reviewed / unaudited
+
+### Taxonomy/Instance Separation
+
+- **Taxonomy** (Concept hierarchy definitions) and **instances** (actual financial figures/Facts) have separate dependency paths
+- Taxonomy changes affect only Concept nodes; instance changes affect only FinancialFact nodes
+- When both change simultaneously (e.g., IFRS taxonomy update concurrent with new filing), referential integrity of HAS_CONCEPT relationships must be re-verified
+- Taxonomy version must be tracked per entity-period — different filings may use different taxonomy versions
+
+## Cross-Entity Dependencies
+
+### Entity Hierarchy
+
+- Parent entity → Subsidiary entity → Sub-subsidiary entity
+- Consolidation scope depends on control (IFRS 10): holding >50% voting rights or effective control
+- Associate: significant influence (typically 20-50% ownership) → equity method accounting
+- Joint venture: joint control → equity method (IFRS 11)
+- Changes in ownership percentage may trigger reclassification (subsidiary → associate or vice versa), which changes the consolidation method
+
+### Intercompany Transaction Dependency
+
+- Intercompany transactions must be eliminated in consolidation
+- Dependency chain: Intercompany Transaction Identified → Elimination Entry → Consolidated Figure Adjusted
+- Failure mode: intercompany sales not eliminated → revenue double-counted in consolidated IS
+- Verification: total intercompany sales in subsidiaries should net to zero in consolidated statements
+
+## Circular Dependency Detection
+
+### Unintentional Cycles (Defects)
+
+- **Concept ↔ Concept:** Concept A is a child of Concept B, and B is a child of A → hierarchy cycle → Block
+- **Entity ↔ Entity:** Entity A is a subsidiary of Entity B, and B is a subsidiary of A → ownership cycle → Block
+- **Fact ↔ Note ↔ Fact:** Fact A is annotated by Note X, which references Fact B, which is annotated by Note Y, which references Fact A → annotation cycle. Resolution: notes annotate facts, not other notes' references
+
+### Detection Method
+
+1. For Concept hierarchy: topological sort — if sort fails, cycle exists
+2. For Entity hierarchy: ownership graph traversal — if any entity is its own ancestor, cycle exists
+3. For Note-Fact references: ANNOTATES edges form a bipartite graph (Note → Fact) — if Note → Note edges exist, investigate
+
+## SE Transfer Verification
+
+| SE Pattern | Finance Equivalent | Key Difference |
+|---|---|---|
+| Acyclic Dependencies Principle (module DAG) | Acyclic Rules (AC01-AC04) | Both prohibit cycles; finance adds domain-specific intentional bidirectional patterns |
+| Dependency Inversion (depend on abstractions) | Concept hierarchy (depend on taxonomy, not raw data) | SE uses interfaces; finance uses taxonomy elements as the abstraction |
+| Referential Integrity (FK constraints) | RI01-RI05 | SE enforces at DB level; finance enforces at ontology validation + pipeline level |
+| Source of Truth Management | Source Priority (XBRL > HTML > PDF) | SE has single SoT; finance has hierarchical SoT with fallback chain |
+| Diamond Dependencies (version conflict) | DM01-DM05 | SE resolves with version managers; finance allows some diamonds (DM01, DM02) while prohibiting others |
+
+## Related Documents
+
+- structure_spec.md — Node and relationship structure where dependency rules apply
+- logic_rules.md — Accounting identities and rules complementing dependency rules
+- domain_scope.md — Source format axis, industry classification, normative tiers
+- concepts.md — Concept mapping system subject to referential integrity
+- extension_cases.md — Extension scenarios requiring dependency rule changes
+- competency_qs.md — Data quality questions (CQ-DQ) testing dependency enforcement

package/.onto/domains/finance/domain_scope.md

@@ -0,0 +1,215 @@
+---
+version: 2
+last_updated: "2026-04-16"
+source: manual
+status: established
+---
+
+# Finance 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** financial reporting ontologies — structured representations of financial statements, taxonomy elements, accounting relationships, and derived metrics.
+
+> **Boundary with accounting domain**: The accounting domain covers transaction-level bookkeeping (journal entries, ledger, trial balance, closing procedures). This domain covers the output of accounting — financial statements, their structure, inter-statement relationships, and analytical use. Journal entry mechanics are accounting's jurisdiction; how financial statements are structured, cross-referenced, and queried is this domain's jurisdiction.
+
+> **Boundary with business domain**: The business domain covers business model analysis, strategy, market position, and competitive dynamics. This domain covers the financial data that quantifies business performance. Revenue growth analysis as a financial metric belongs here; revenue growth as a competitive strategy signal belongs to business.
+
+## Classification Axes
+
+| Axis | Values | Description |
+|---|---|---|
+| Reporting framework | IFRS / US-GAAP / Local GAAP (K-IFRS, J-GAAP, etc.) | Applicable accounting standard |
+| Reporting unit | Consolidated / Separate | Financial statement preparation unit |
+| Reporting frequency | Annual / Semi-annual / Quarterly / Interim | Disclosure frequency |
+| Industry classification | General / Financial (banking, insurance, securities) | Statement structure and chart of accounts differ |
+| Temporal attribute | instant / duration | Time attribution method of financial items |
+| Source format | Structured (XBRL) / Semi-structured (HTML) / Unstructured (PDF) | Data origin format |
+
+## Key Sub-Areas
+
+Classification axis: **Financial reporting concern** — Classified by the concern that the financial ontology must address.
+
+Applicability markers:
+- **(required)**: Must be addressed in any financial reporting ontology review. Absence indicates a fundamental gap
+- **(when applicable)**: Address when the system's scope includes the relevant feature. Condition type: feature existence (binary)
+- **(scale-dependent)**: Becomes required beyond a scale threshold documented per item. Condition type: scale threshold (quantitative boundary crossed)
+
+### Financial Statement Structure
+- **Statement Components** (required): Statement of Financial Position (BS), Income Statement (IS), Cash Flow Statement (CF), Statement of Changes in Equity, Statement of Comprehensive Income — components and interrelationships
+- **Statement Linkage** (required): Net income flowing from IS to equity changes, opening/closing balance consistency across BS periods, CF reconciliation to BS cash balances
+- **Financial Industry Statements** (when applicable): Insurance contract liabilities, loan receivables, regulatory capital ratios — additional or differently structured statements for banking, insurance, and securities industries
+
+### Chart of Accounts Classification
+- **5-Element Structure** (required): Assets/Liabilities/Equity/Revenue/Expenses hierarchical classification, current/non-current distinction, normal balance direction
+- **Account Hierarchy** (required): Parent-child account relationships, subtotal computation paths, roll-up logic from line items to totals
+- **Extension Accounts** (required): Company-specific taxonomy extensions beyond standard accounts, normalization mapping to canonical names
+
+### Accounting Identity and Constraints
+- **Fundamental Identities** (required): Assets = Liabilities + Equity (BS), revenue - expenses = net income (IS), opening cash + CF activities = closing cash (CF)
+- **Cross-Statement Linkage** (required): Net income from IS appears in equity changes, CF reconciles to BS cash balance, comprehensive income components appear in OCI statement
+- **Constraint Conflict Detection** (required): Consolidated ≥ separate total assets (general expectation), identity violations as data quality signals
+
+### Period and Point-in-Time
+- **Temporal Attribution** (required): instant (BS items, point-in-time) vs duration (IS/CF items, over-a-period) distinction and enforcement
+- **Period Matching** (required): Same-duration comparison enforcement (quarterly vs quarterly, annual vs annual), cumulative vs single-quarter distinction
+- **Restatement Management** (required): Version tracking for restated figures, final version determination, historical comparison across restatements
+
+### Consolidated and Separate Reporting
+- **Consolidation Scope** (required): Subsidiary inclusion criteria, consolidation adjustments, intercompany transaction elimination
+- **Segment Reporting** (required): Business segment and geographic segment dimensions, segment-level P&L, reconciliation to consolidated totals
+- **Associate and Joint Venture** (when applicable): Equity method accounting, proportionate consolidation, significant influence determination
+
+### Notes and Disclosure System
+- **Note Structure** (required): Reference relationships between notes and main statement items, note categorization (accounting policies, estimates, contingencies)
+- **Accounting Policy Disclosure** (required): Recognition, measurement, and presentation method choices disclosed per significant policy area
+- **Contingent Liabilities and Commitments** (required): Off-balance-sheet items, guarantees, pending litigation — items not on the main statements but material for analysis
+
+### Key Accounting Standards
+- **Revenue Recognition (IFRS 15)** (required): 5-step model (contract → performance obligations → transaction price → allocation → recognition), over-time vs point-in-time, variable consideration
+- **Financial Instruments (IFRS 9)** (required): Classification (amortised cost/FVOCI/FVPL), impairment (3-stage expected credit loss), hedge accounting basics
+- **Leases (IFRS 16)** (required): Right-of-use asset and lease liability recognition, operating/finance lease distinction elimination (lessee), impact on BS and ratios
+- **Business Combinations (IFRS 3)** (when applicable): Acquisition method, goodwill recognition, purchase price allocation, contingent consideration
+- **Impairment (IAS 36)** (when applicable): Cash-generating units, recoverable amount (higher of fair value less costs to sell and value in use), impairment indicators
+- **Fair Value Measurement (IFRS 13)** (when applicable): Fair value hierarchy (Level 1 quoted prices, Level 2 observable inputs, Level 3 unobservable inputs), valuation techniques
+
+### Derived Metrics and Analysis
+- **Profitability Metrics** (required): ROE, ROA, operating profit margin, net profit margin, EBITDA margin
+- **Leverage Metrics** (required): Debt ratio, debt-to-equity ratio, interest coverage ratio, net debt
+- **Liquidity Metrics** (required): Current ratio, quick ratio, cash conversion cycle
+- **Market Metrics** (when applicable): EPS, P/E ratio, P/B ratio, dividend yield, market capitalization
+- **Per-Share Metrics** (when applicable): Basic EPS, diluted EPS, book value per share
+
+### Regulatory and Compliance
+- **IFRS Compliance** (required): Conformance to applicable IFRS/IAS standards, first-time adoption considerations
+- **Audit Opinion** (required): Unqualified/qualified/adverse/disclaimer classification, going concern emphasis, key audit matters
+- **Disclosure Requirements** (required): Statutory disclosure framework by jurisdiction, mandatory vs voluntary disclosures
+- **Filing Requirements** (when applicable): SEC (10-K, 10-Q), FSC (사업보고서), FCA filings — jurisdiction-specific filing formats and deadlines
+
+## Normative System Classification
+
+Standards governing financial reporting operate at four distinct tiers.
+
+| Tier | Name | Enforcement Mechanism | Change Velocity | Examples |
+|------|------|----------------------|-----------------|---------|
+| Tier-1a | Accounting Standards | **Legal obligation** + auditor enforcement | Slow (years) | IFRS/IAS standards, US-GAAP ASC, local GAAP |
+| Tier-1b | Regulatory Requirements | **Securities regulator** enforcement | Medium (annual) | SEC filing rules, FSC disclosure regulations, stock exchange listing requirements |
+| Tier-2 | Taxonomy and Data Standards | Industry consortium enforcement, regulatory adoption | Medium (annual) | XBRL 2.1, IFRS Taxonomy, FIBO, ESEF |
+| Tier-3 | Industry Practice and Heuristics | Analyst convention, peer comparison | Fast (per analysis) | Non-GAAP metrics (adjusted EBITDA), industry KPIs, analyst consensus methods |
+
+**Ordering principle**: Tier-1a > Tier-1b > Tier-2 > Tier-3. Accounting standards override everything; regulatory requirements override data standards and practice; data standards override practice.
+
+Tier classification decision tree:
+1. **Tier-1a**: Is this rule from an IFRS/IAS/US-GAAP standard or local GAAP? Would non-conformance produce a qualified audit opinion?
+2. **Tier-1b**: If not Tier-1a, is this rule from a securities regulator (SEC, FSC, FCA)? Would non-conformance produce a filing rejection or regulatory action?
+3. **Tier-2**: If not Tier-1a/1b, is this rule from a data/taxonomy standard (XBRL, IFRS Taxonomy, FIBO)? Is it enforced by filing systems or data consumers?
+4. **Tier-3**: If none of the above, is this an industry practice, analyst convention, or common analytical method?
+
+## Cross-Cutting Concerns
+
+### Data Quality and Consistency
+
+Spans all sub-areas. Financial data must be internally consistent (identities hold, cross-statement linkages match) and externally consistent (comparable across entities and periods).
+
+- Internal: logic_rules.md §Accounting Identities + §Cross-Statement Linkage Rules
+- External: concepts.md §Extension Account Handling (normalization for comparability)
+- Temporal: logic_rules.md §Period Rules (period matching for valid comparison)
+
+### Source Trustworthiness
+
+Spans Financial Statement Structure, Notes System, and Regulatory Compliance. Data from different sources (XBRL, HTML, PDF) has different reliability levels.
+
+- Source priority: dependency_rules.md §Source of Truth Transition Rules
+- Audit status: reviewed (quarterly) vs audited (annual) vs unaudited
+- Restatement handling: extension_cases.md §Restatement Processing
+
+## Required Concept Categories
+
+| Category | Description | Risk if Missing | Example of Failure |
+|---|---|---|---|
+| Reporting entity | Legal entity that prepares financial statements | Cannot attribute financial data to an entity | Revenue figure exists but no entity reference — cannot determine whose revenue it is |
+| Financial item | Monetary information at the account level | No queryable data | Ontology has structure but no actual financial figures loaded |
+| Reporting period | Time range of financial information | Temporal analysis impossible | Revenue figure exists without period — cannot determine which year it belongs to |
+| Accounting policy | Recognition, measurement, and presentation choices | Comparison produces misleading results | Two companies' inventory figures compared without noting one uses FIFO and the other weighted average |
+| Note information | Detailed descriptions of main statement items | Contingent liabilities and off-balance-sheet risks invisible | Material litigation pending but not discoverable because notes are excluded from the ontology |
+| External reference | Taxonomy and standard linkage information | Inter-entity comparison impossible | Each entity's "revenue" stored under different concept IDs with no normalization mapping |
+| Segment information | Business division-level data | Diversified company analysis impossible | Conglomerate's overall revenue is available but cannot break down which division contributes what |
+| Audit status | Audit opinion and assurance level | Data reliability unknown | Restated quarterly figures treated with same confidence as audited annual figures |
+
+## Reference Standards
+
+This file is the **single source of truth for external standard version information** within the finance domain.
+
+| Standard | Version/Year | Application Area | Core Content |
+|----------|-------------|-----------------|--------------|
+| IFRS | 2024 (annual bound volume) | Accounting standards | 17 IFRS + 29 IAS standards governing recognition, measurement, presentation, disclosure |
+| XBRL | 2.1 (2003, maintained) | Data taxonomy | Structured financial reporting specification — instances, taxonomies, linkbases |
+| IFRS Taxonomy | 2024 | Taxonomy elements | ~6,000 elements mapping to IFRS disclosure requirements |
+| FIBO | Ongoing (W3C EDMC) | Financial ontology | Financial Industry Business Ontology — entities, instruments, regulatory concepts |
+| US-GAAP | ASC (codification, updated) | US accounting standards | ~90 topics codified by FASB |
+| ESEF | 2020 (EU regulation) | European filing | European Single Electronic Format — mandatory XBRL tagging for IFRS annual reports in EU |
+| K-IFRS | 2024 (aligned with IFRS) | Korean accounting | Korean adoption of IFRS with local amendments |
+
+## Bias Detection Criteria
+
+### Coverage Distribution
+
+- If more than 70% of questions concentrate on a single financial statement (e.g., BS only) → **statement bias**
+- If only one of consolidated/separate is addressed → **reporting unit gap**
+- If only a single point in time is addressed with no time series → **temporal bias**
+
+### System Completeness
+
+- If the notes area is completely ignored → **notes absence** (contingent liabilities, policies invisible)
+- If only raw items are addressed with no derived metrics → **analysis gap**
+- If only a single industry (general or financial) is addressed → **industry bias**
+- If source format is not differentiated (XBRL vs PDF treated identically) → **source quality blindness**
+
+### Analytical Depth
+
+- If no inter-entity comparison capability exists → **comparability absence**
+- If restatement handling is undefined → **version management gap**
+- If segment reporting is absent for multi-segment entities → **segment blindness**
+- If audit opinion/status is not tracked → **assurance level ignorance**
+
+## Inter-Document Contract
+
+### Rule Ownership
+
+| Cross-cutting Topic | Owner File | Other Files |
+|---|---|---|
+| Accounting identities and math | logic_rules.md §Accounting Identities | structure_spec.md (references), dependency_rules.md (references) |
+| Concept definitions and synonyms | concepts.md | All other files reference, do not redefine |
+| Dependency direction rules | dependency_rules.md §Direction Rules | structure_spec.md (references) |
+| Source of Truth priority | dependency_rules.md §Source of Truth Transition Rules | domain_scope.md (tier mapping) |
+| Structural requirements | structure_spec.md §Required Node Types, §Required Relationships | Other files reference |
+| Conciseness criteria | conciseness_rules.md | Other files reference |
+| Competency questions | competency_qs.md | Other files provide inference path targets |
+| Constraint conflict resolution | logic_rules.md §Constraint Conflict Checking | dependency_rules.md (cascading failures) |
+
+### Sub-area to CQ Section Mapping
+
+| Sub-area | CQ Sections | Coverage |
+|---|---|---|
+| Financial Statement Structure | CQ-FS | Full |
+| Chart of Accounts Classification | CQ-CA | Full |
+| Accounting Identity | CQ-AI | Full |
+| Period/Point-in-Time | CQ-TP | Full |
+| Consolidated/Separate | CQ-CS | Full |
+| Notes and Disclosure | CQ-ND | Full |
+| Key Accounting Standards | CQ-AS | Full |
+| Derived Metrics | CQ-DM | Full |
+| Regulatory and Compliance | CQ-RC | Full |
+
+Cross-cutting CQ sections:
+- CQ-IE (Inter-Entity Comparison) — spans Chart of Accounts, Derived Metrics, Consolidated/Separate
+- CQ-TS (Time Series) — spans all sub-areas with temporal dimension
+- CQ-DQ (Data Quality) — spans all sub-areas; enforcement through logic_rules.md identities
+
+## Related Documents
+- concepts.md — Synonym mappings, homonyms, interpretation principles, taxonomy element definitions
+- competency_qs.md — Competency questions organized by CQ-ID sections
+- structure_spec.md — Node types, relationships, and structural requirements
+- logic_rules.md — Accounting identities, period rules, IFRS-specific rules
+- dependency_rules.md — Acyclic, direction, diamond, referential integrity rules
+- extension_cases.md — Taxonomy change, new entity, multi-country scenarios
+- conciseness_rules.md — Allowed/prohibited redundancy patterns