@mudraforge/statutory 2.8.1 → 2.10.0

package/docs/CORPUS_QUALITY.md

@@ -1,9 +1,9 @@
 # MudraForge Statutory Knowledge Quality Card
 
 > **Format Reference**: Inspired by Google's *Data Cards Playbook* and the OpenSSF Project Quality Standards.  
-> **Target Package**: `@mudraforge/statutory` v2.4.0  
+> **Target Package**: `@mudraforge/statutory` v2.10.0  
 > **Evaluation Mode**: Machine-audited against primary sources, official gazettes, and test fixtures.  
-> **Generated Timestamp**: 2026-10-25T19:16:47.828Z
+> **Generated Timestamp**: 2026-10-26T21:04:24.978Z
 
 ---
 
@@ -11,12 +11,12 @@
 
 | Dimension | Metric | Denominator / Baseline | Coverage Rate | Status |
 | :--- | :--- | :--- | :--- | :--- |
-| **Primary Source Citations** | 61 resolvable gazette URLs | 61 total citations declared | **100.0%** | VERIFIED |
-| **Temporal Validity Bounds** | 24 sections with explicit dates | 24 total bundled sections | **100.0%** | VERIFIED |
-| **Dual-Act 2025 Transition Bridges** | 8 direct tax provisions mapped | 9 direct tax provisions | **88.9%** | VERIFIED |
-| **Attached Administrative Circulars** | 25 official circulars | 6 sections across 4 domains | **100% Attached** | VERIFIED |
-| **Attached Return/Compliance Schemas** | 22 schemas/templates | 6 sections across 4 domains | **100% Attached** | VERIFIED |
-| **Cryptographic Merkle Verification** | 20 bundle files verified | SHA-256 Merkle root digest | **0 Mismatches** | VERIFIED |
+| **Primary Source Citations** | 76 resolvable gazette URLs | 76 total citations declared | **100.0%** | VERIFIED |
+| **Temporal Validity Bounds** | 29 sections with explicit dates | 29 total bundled sections | **100.0%** | VERIFIED |
+| **Dual-Act 2025 Transition Bridges** | 9 direct tax provisions mapped | 10 direct tax provisions | **90.0%** | VERIFIED |
+| **Attached Administrative Circulars** | 30 official circulars | 29 provisions across active domains | **100% Attached** | VERIFIED |
+| **Attached Return/Compliance Schemas** | 27 schemas/templates | 29 provisions across active domains | **100% Attached** | VERIFIED |
+| **Cryptographic Merkle Verification** | 86 bundle files verified | SHA-256 Merkle root digest | **0 Mismatches** | VERIFIED |
 
 ---
 
@@ -48,8 +48,10 @@
 
 | Section Code | Statutory Provision | Governing Statute | Temporal Window | Status | Citations | Circulars | Forms | 2025 Act Successor |
 | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- |
+| **ITA-SEC-79** | Carry Forward and Set Off of Accumulated Losses on Change in Shareholding | Income-tax Act, 1961 (Act No. 43 of 1961) | `1962-04-01` to `OPEN_ENDED` | `ACTIVE` | 3 | 1 | 1 | Income-tax Act, 2025 (Chapter on Set-off and Carry Forward of Losses) (Provisions on Loss Set-Off on Shareholding Continuity) |
 | **50B** | Special provision for computation of capital gains in case of slump sale | Income-tax Act, 1961 (Act No. 43 of 1961) | `2000-04-01` to `OPEN_ENDED` | `ACTIVE` | 3 | 2 | 2 | Income-tax Act, 2025 (Section 78 (Capital gains on slump sale of undertakings)) |
-| **206AB** | Special provision for deduction of tax at source for non-filers of income-tax return | Income-tax Act, 1961 (Act No. 43 of 1961) | `2021-07-01` to `OPEN_ENDED` | `ACTIVE` | 1 | 1 | 0 | Income-tax Act, 2025 (Section 397(3)) |
+| **115BAA-115JB** | Tax on income of certain domestic companies (Section 115BAA) and Minimum Alternate Tax (Section 115JB) | Income-tax Act, 1961 (Act No. 43 of 1961) | `2019-04-01` to `OPEN_ENDED` | `ACTIVE` | 3 | 1 | 1 | Income-tax Act, 2025 (Chapter XI (Corporate Taxation & Special Regimes)) |
+| **206AB** | Special provision for deduction of tax at source for non-filers of income-tax return (Omitted effective 1 April 2025) | Income-tax Act, 1961 (Act No. 43 of 1961) | `2021-07-01` to `2025-03-31` | `SUNSET_SUPERSEDED` | 1 | 1 | 0 | Finance Act, 2025 (Statutory Omission) (Section 206AB Omitted) |
 | **206C(1H)** | Collection of tax at source by seller on receipt of consideration for sale of goods (Omitted effective 1 April 2025) | Income-tax Act, 1961 | `2020-10-01` to `2025-03-31` | `SUNSET_SUPERSEDED` | 2 | 1 | 0 | Finance Act, 2025 (Statutory Sunset) (Section 206C(1H) Omitted) |
 | **194H** | Deduction of tax at source on commission or brokerage | Income-tax Act, 1961 (Act No. 43 of 1961) | `2001-06-01` to `2026-03-31` | `SUNSET_SUPERSEDED` | 3 | 1 | 1 | Income-tax Act, 2025 (Section 393(1), Table 4, Item (i)) |
 | **194C** | Deduction of tax at source on payments to contractors and sub-contractors | Income-tax Act, 1961 (Act No. 43 of 1961) | `1972-04-01` to `2026-03-31` | `SUNSET_SUPERSEDED` | 3 | 1 | 2 | Income-tax Act, 2025 (Section 393(1), Table 3, Item (i)) |
@@ -62,12 +64,15 @@
 | **8** | Tax liability on composite and mixed supplies and classification of bundled goods and services contracts | Central Goods and Services Tax Act, 2017 | `2017-07-01` to `OPEN_ENDED` | `ACTIVE` | 3 | 1 | 1 | N/A |
 | **10** | Composition levy and ineligible tax invoice restrictions | Central Goods and Services Tax Act, 2017 (Act No. 12 of 2017) | `2017-07-01` to `OPEN_ENDED` | `ACTIVE` | 2 | 1 | 0 | N/A |
 | **34** | Credit and debit notes statutory adjustments and return filing deadlines | Central Goods and Services Tax Act, 2017 (Act No. 12 of 2017) | `2017-07-01` to `OPEN_ENDED` | `ACTIVE` | 2 | 1 | 0 | N/A |
+| **IGST-SEC-16-LUT** | Zero rated supply and export of services under Letter of Undertaking (LUT) | Integrated Goods and Services Tax Act, 2017 (Act No. 13 of 2017) | `2017-07-01` to `OPEN_ENDED` | `ACTIVE` | 3 | 1 | 1 | Integrated Goods and Services Tax Act, 2017 (In Force) (Section 16) |
 | **RULE-48(4)** | Mandatory electronic invoicing (E-Invoicing), IRN generation, and invoice validity | Central Goods and Services Tax Rules, 2017 | `2020-10-01` to `OPEN_ENDED` | `ACTIVE` | 2 | 1 | 0 | N/A |
 | **51** | Tax deduction at source under Goods and Services Tax | Central Goods and Services Tax Act, 2017 (Act No. 12 of 2017) | `2018-10-01` to `OPEN_ENDED` | `ACTIVE` | 2 | 1 | 0 | N/A |
 | **16(2)** | Eligibility and conditions for taking input tax credit and mandatory 180-day payment rule | Central Goods and Services Tax Act, 2017 (Act No. 12 of 2017) | `2017-07-01` to `OPEN_ENDED` | `ACTIVE` | 4 | 1 | 1 | CGST Act, 2017 (In force) (Section 16(2), (3), (4), (5), (6)) |
 | **9(3)** | Reverse Charge Mechanism (RCM) mandatory tax liability on recipient, self-invoicing, payment voucher issuance, and electronic cash discharge | Central Goods and Services Tax Act, 2017 read with Notification No. 13/2017-Central Tax (Rate) | `2017-07-01` to `OPEN_ENDED` | `ACTIVE` | 3 | 1 | 1 | N/A |
 | **195** | Deduction of tax at source on foreign cross-border payments to non-residents, DTAA treaty benefits, documentation, Form 15CA/15CB, and cloud software exemption | Income-tax Act, 1961 read with Double Taxation Avoidance Agreements (DTAA) under Section 90 | `1962-04-01` to `OPEN_ENDED` | `ACTIVE` | 3 | 2 | 1 | Income-tax Act, 2025 Section 393(2) (Section 393(2) of Income-tax Act, 2025) |
+| **INDAS-21-109-FX** | Foreign Exchange Monetary Asset/Liability Revaluation and Cash Flow Hedge Accounting | Companies (Indian Accounting Standards) Rules, 2015 read with Section 133 of Companies Act, 2013 | `2016-04-01` to `OPEN_ENDED` | `ACTIVE` | 3 | 1 | 1 | Companies Act, 2013 (Indian Accounting Standards) (Ind AS 21 & Ind AS 109) |
 | **IRC-901-904** | Foreign Tax Credit authorization, separate basket limitation, and partnership pass-through reporting (Form 1116 / Schedule K-3) | Internal Revenue Code of 1986 (Title 26, U.S. Code) | `2021-01-01` to `OPEN_ENDED` | `ACTIVE` | 2 | 0 | 2 | Title 26, U.S. Code (Continuous) (26 U.S.C. §§ 901, 904(d), 904(j), 469) |
+| **ITA-SEC-92C-RULE-10CA** | Computation of Arm's Length Price (ALP), Range Concept and Secondary Adjustments | Income-tax Act, 1961 (Act No. 43 of 1961) | `2014-04-01` to `OPEN_ENDED` | `ACTIVE` | 3 | 1 | 1 | Income-tax Act, 2025 (Chapter on International Tax & Transfer Pricing) (Transfer Pricing Provisions) |
 | **MSMED-15-16** | Statutory payment timelines to Micro & Small Enterprises, compound penal interest, and income tax deduction disallowance | Micro, Small and Medium Enterprises Development Act, 2006 read with Income-tax Act, 1961 Section 43B(h) | `2006-10-02` to `OPEN_ENDED` | `ACTIVE` | 4 | 1 | 2 | Income-tax Act, 2025 Section 37(2)(g) (Section 37(2)(g) of Income-tax Act, 2025) |
 | **MSMED-SEC-7** | Composite criteria for classification of Micro, Small and Medium Enterprises, investment calculations, and statutory exclusion of export turnover | Micro, Small and Medium Enterprises Development Act, 2006 read with Ministry of MSME Notification S.O. 2119(E) | `2020-07-01` to `OPEN_ENDED` | `ACTIVE` | 2 | 1 | 1 | N/A |
 | **MCA-MSME-1** | Mandatory half-yearly reporting of outstanding dues exceeding 45 days to Micro & Small Enterprises (Form MSME-1) | Companies Act, 2013 read with Specified Companies (Furnishing of information about payment to micro and small enterprise suppliers) Order, 2019 | `2019-01-22` to `OPEN_ENDED` | `ACTIVE` | 2 | 1 | 1 | N/A |

package/docs/DOMAIN_BREADTH_AND_DEPTH_COMPARISON.md

@@ -2,7 +2,7 @@
 ## Public Package Seed vs. Full Sovereign Operating Engine
 
 > **Document Version**: `1.0.0`  
-> **Package**: `@mudraforge/statutory` (v2.4.0)  
+> **Package**: `@mudraforge/statutory` (v2.9.0)  
 > **Enterprise Sovereign Engine**: MudraForge Adesha Sovereign Runtime  
 > **Specification**: Google Open Knowledge Format (OKF v0.2)  
 

package/docs/ENTERPRISE_GOVERNANCE.md

@@ -3,7 +3,7 @@
 
 > **Document Type**: Architecture & Enterprise Governance Specification  
 > **Target Audience**: Chief Financial Officers (CFOs), Heads of Finance, Enterprise Security & Risk Teams  
-> **Underlying Substrate**: MudraForge Statutory Knowledge Layer (OKF)  
+> **Underlying Substrate**: MudraForge Statutory Knowledge Layer (OKF) — [`@mudraforge/statutory`](../README.md)  
 
 ---
 
@@ -17,25 +17,86 @@ When modern organizations adopt AI agents for finance operations, the primary ri
 
 MudraForge Adesha was designed to establish an impenetrable **Execution Boundary** between generative AI assistance and real-world money movement.
 
+> **The Core Thesis of Autonomous Finance**:  
+> *The dangerous moment in finance AI isn't when the model is wrong. It's when its output becomes a payment instruction.*  
+> 
+> In marketing, an AI hallucination is a typo. In accounts payable, an unhandled bank timeout can trigger a retry that double-pays a vendor.  
+> 
+> Hardening the financial runtime for **Adesha, MudraForge's organizational AI**, our principle is simple:  
+> **Reasoning can be probabilistic, but financial execution needs deterministic boundaries.**
+
+---
+
+## 2. The Three-Tier Architecture & Operational Boundaries
+
+To ensure complete clarity for developers, auditors, and enterprise clients, MudraForge establishes three distinct architectural tiers with strict operational boundaries:
+
+| Tier | Component | Repository & Distribution | Pricing & License | Operational Status |
+| :--- | :--- | :--- | :--- | :--- |
+| **Tier 1** | **Open-Source Statutory Commons** (`@mudraforge/statutory`) | Public GitHub (`mondeep0123/mudraforge-statutory`) & NPM Registry | **100% Free** (MIT License / CC BY 4.0 Data) | **`CURRENT_PRODUCTION`** (Working offline software) |
+| **Tier 2** | **Hosted Statutory API & Edge Sync** | Cloudflare Global Anycast Edge (`api.mudraforge.in`) | Best-Effort Free Beta (Metered Cloud API) | **`CURRENT_BETA`** (Edge endpoints & caching) |
+| **Tier 3** | **Commercial Adesha Runtime** | Enterprise Private VPC / On-Premise Worker Deployment | Commercial Enterprise SaaS | **`PILOT_STAGE_INTERNAL`** / **`SANDBOX_VALIDATED`** |
+
+### Precise Status Classifications across Capabilities
+
+To ensure epistemic honesty and prevent conflating tested prototypes with general availability:
+
+- **`CURRENT_PRODUCTION` (Working, Publicly Inspectable Software)**:
+  - Bundled OKF statutory corpus (29 provisions across 5 legal domains).
+  - Pure deterministic calculators in `src/calculators.js` (Corporate Tax, LUT Export, TP ALP, Section 79, Ind AS 21/109).
+  - Zero-network CLI (`mudraforge-statutory` doctor, crosswalk, diff, verify, browse).
+  - Cryptographic SHA-256 Merkle root integrity verifier (`npm run manifest:check`).
+  - Native AI Agent Skill (`SKILL.md`) for offline agent runtime inspection.
+
+- **`SANDBOX_VALIDATED` (Tested Under Realistic Simulation & Integration Sandboxes)**:
+  - Live Zoho Books general ledger balanced double-entry writeback (tested against sandbox and live accounts with readback).
+  - RazorpayX corporate banking sandbox payout dispatch (`SETTLEMENT_LIVE_SANDBOX`), HMAC-SHA256 webhook ingestion, and clearinghouse reversal interception.
+  - Multi-process lock contention testing verifying single-use lease acquisition across competing OS processes.
+
+- **`PILOT_STAGE_INTERNAL` / `PLANNED` (Enterprise Engagements Requiring Partner Onboarding)**:
+  - Direct host-to-host bank rail settlement (ICICI / HDFC corporate host-to-host RTGS/NEFT).
+  - Multi-region distributed lease coordination across Cloudflare Durable Objects.
+  - Hosted Model Context Protocol (MCP) server fleets and live multi-agent tool connectivity (strictly enterprise tier).
+
+---
+
+## 3. The Four Pillars of Autonomous Finance Execution
+
+1. **Retrieval is Not Verification**: Finding a document or matching keywords is not legal verification. Real accounting requires validating evidence against connected systems of record (including live Zoho Books / SAP ERP readback) and authenticated tenant statutory vaults.
+2. **Safe Tools Do Not Guarantee Safe Workflows**: An AI agent can call individually safe API tools and still coordinate an unauthorized or illegal transaction. Generative models coordinate investigations; deterministic code calculates statutory taxes and enforces ledger invariants (*Rule 11: Agreement with the Engine ≠ Agreement with the Law*).
+3. **Preventing Silent Financial Drift**: Deterministic code computes numbers. RFC 8785 JSON Canonicalization Scheme (JCS) and SHA-256 bind calculation results to a verifiable fingerprint. The hash does not compute—it detects changes between calculation, human authorization, and execution. If the result no longer matches the fingerprint, the workflow halts.
+4. **Testing Payment Boundaries Against Failure**: Single-use CAS leases prevent duplicate payments under concurrent races. Formal TLA+ modeling with the TLC Model Checker explored all 361 reachable states in our configured distributed model with 0 invariant violations and caught 4 injected defects.
+
 ---
 
-## 2. Seven-Stage Governance Chain of Custody
+## 4. Seven-Stage End-to-End AP Governance Lifecycle
 
 Every financial transaction in MudraForge Adesha passes through seven sequential verification gates before any funds can move or any ledger can mutate:
 
 ```
-1. Input Ingestion     ──► Digitally signed IRP e-Invoice QR code & binary hash verification
-2. Statutory Substrate ──► Deterministic tax calculation under Open Knowledge Format (OKF)
-3. Canonical Result    ──► Tamper-evident RFC 8785 (JCS) normalization & SHA-256 seal
-4. Presentation Lock   ──► Automated prose auditor verifies generative text matches numbers
-5. Single-Use Lease    ──► Cryptographically bound lease issued with Maker-Checker token
-6. Zero-Trust Outflow  ──► Atomic database Compare-and-Swap (CAS) prevents duplicate execution
-7. Ledger Equilibrium ──► Source-bound lines balanced to ₹0.00 posted post-bank UTR receipt
+Stage 1: Invoice Ingestion (IRP QR Code / PDF & Vendor Validation)
+    ↓
+Stage 2: OKF Rule Resolution (Sub-1ms Local Offline Lookup)
+    ↓
+Stage 3: Deterministic Statutory Computation (Excess Math & GST Unbundling)
+    ↓
+Stage 4: Cryptographic Payment Authorization Lease (Single-Use Atomic CAS Gate)
+    ↓
+Stage 5: Human-in-the-Loop Authority Harness (CFO Biometric Passkey / Mobile)
+    ↓
+Stage 6: Bank Rail Settlement (Host-to-Host Corporate RTGS / Sandbox Rail)
+    ↓
+Stage 7: General Ledger Balanced Double-Entry Writeback (ERP Equilibrium: ₹0.00 Discrepancy)
+```
+
+Run this audited 7-stage AP simulation directly in your local terminal:
+```bash
+npm run example:trace
 ```
 
 ---
 
-## 3. Cryptographic Single-Use Payment Authorization Leases
+## 5. Cryptographic Single-Use Payment Authorization Leases
 
 In Adesha, banking adapters (such as RazorpayX, Mercury, or host-to-host SFTP connections) operate within a **Zero-Trust Execution Boundary**.
 
@@ -64,7 +125,7 @@ A payment lease is cryptographically bound to seven immutable parameters:
 
 ---
 
-## 4. Presentation Consistency Lock & Automated Prose Auditor
+## 6. Presentation Consistency Lock & Automated Prose Auditor
 
 Generative language models regularly drop trailing zeros or swap figures when drafting summaries for human reviewers. 
 
@@ -77,22 +138,20 @@ Adesha enforces a **Presentation Consistency Lock**:
 
 ---
 
-## 5. Enterprise Risk & Operational Controls
-
-### 1. Penny-Drop Verification
-Before any vendor account can be bound to a payment lease, it must complete an automated automated penny-drop verification via NPCI/IMPS with a verified name-match score $\ge 95\%$.
+## 7. OpenSSF Packaging vs. Full Security Assurance
 
-### 2. 48-Hour Change-Control Cooling Lock
-Any alteration to vendor bank details in the enterprise master triggers an immediate **48-hour cooling-off lock**, requiring dual CFO re-authorization before leases can bind to the updated account.
-
-### 3. Structural Secret Isolation
-Banking API credentials (API keys, OAuth client secrets, mTLS certificates) reside inside an isolated secret boundary accessible exclusively through a cryptographic signing module that demands an active, unconsumed `PaymentAuthorizationLease`.
+In accordance with OpenSSF (Open Source Security Foundation) npm best practices:
+- **Packaging Hygiene**: Zero runtime dependencies, offline-first execution, and `.npmrc` with `ignore-scripts=true` neutralize install-time supply chain attacks.
+- **Cryptographic Non-Tampering**: SHA-256 Merkle root manifests certify byte-level distribution fidelity.
+- **Epistemic Honesty**: These packaging strengths do not replace independent legal counsel, statutory audit certification, or runtime multi-region crash testing. Organizations must evaluate autonomous finance systems against end-to-end integration boundaries.
 
 ---
 
-## 6. Commercial Engagement & Enterprise Pilots
+## 8. Commercial Engagement & Enterprise Pilots
+
+The full Adesha Autonomous Governance Runtime is delivered as a managed enterprise deployment integrated with your corporate ERP (Zoho Books, SAP S/4HANA, NetSuite) and banking partners.
 
-The full Adesha Autonomous Governance Runtime is delivered as a managed enterprise deployment integrated with your corporate ERP (Zoho Books, SAP, NetSuite) and banking partners.
+To evaluate Adesha in read-only shadow mode against historical accounts payable records, review the [Supervised Shadow Pilot Evaluation Guide](./PILOT_EVALUATION_GUIDE.md).
 
 For enterprise architecture discussions, pilot deployments, or API keys:
 - **Email**: [hello@mudraforge.in](mailto:hello@mudraforge.in) or [support@mudraforge.in](mailto:support@mudraforge.in)

package/docs/PILOT_EVALUATION_GUIDE.md

@@ -1,149 +1,214 @@
-# MudraForge Adesha — Proposed Accounts Payable Pilot Evaluation Guide
-## Protocol for Bounded Historical Shadow Audits
+# MudraForge Adesha — Supervised Shadow Pilot Evaluation Guide
+## Benchmarking Autonomous Finance AI Against Historical Accounts Payable Records
 
-> **Document Type**: Proposed Enterprise Pilot Specification  
-> **Status**: Proposed Pilot Protocol (Not evidence of an active commercial customer deployment)  
+> **Document Type**: Enterprise Pilot Specification  
+> **System Under Evaluation**: MudraForge Adesha (Autonomous Finance AI)  
+> **Open Trust Anchor**: `@mudraforge/statutory` (MIT Zero-Dependency Substrate)  
+> **Execution Mode**: Supervised Read-Only Shadow Execution (Archival AP Records)  
 > **Target Audience**: Chief Financial Officers (CFOs), Heads of Tax, Accounts Payable Directors, Enterprise Risk Officers  
 
 ---
 
-## 1. Context & Purpose
+## 1. Executive Context & Purpose
 
-This document outlines a proposed, non-invasive evaluation protocol for enterprise finance teams seeking to assess the statutory accuracy and audit capabilities of MudraForge Adesha.
+This document specifies the protocol for conducting a **Supervised Shadow Pilot** of MudraForge Adesha within an enterprise finance department.
 
-A core operational challenge in corporate finance operations is ensuring consistent adherence to complex statutory withholding regimes, cumulative financial-year threshold tracking, and commercial delayed-payment regulations without disrupting active business operations. 
+In high-consequence corporate finance, autonomous systems must establish empirical accuracy and deterministic reliability before receiving operational authority. Modern accounts payable operations face immense regulatory pressure across direct tax withholding (TDS/TCS), commercial delayed payment laws (MSMED Act, Section 43B(h)), and evolving statutory transitions (the transition from the Income-tax Act, 1961 to the Income-tax Act, 2025). Human AP clerks and rigid rule engines frequently make systematic errors on cumulative thresholds, gross vs. basic tax bases, and legislative sunset dates.
 
-This proposed pilot enables an organization to test MudraForge's deterministic statutory engine against **historical, customer-approved accounts payable records** in a strictly read-only, advisory setting before considering any live workflow integration.
+MudraForge Adesha is an autonomous finance AI engineered to govern end-to-end accounts payable workflows. Rather than requesting live operational authority on day one, Adesha is evaluated in a **supervised shadow mode** against historical, customer-approved accounts payable datasets. 
 
----
+In this mode, Adesha reconstructs past vendor invoices, line items, and payment cycles in read-only memory, compares its deterministic legal determinations and simulated double-entry journal postings against the enterprise's historical enterprise resource planning (ERP) ledger entries, and generates an audit-grade reconciliation report highlighting variances, compliance risks, and cash-flow exposures.
+
+### The Role of the Open Trust Anchor (`@mudraforge/statutory`)
+A foundational risk in applying AI to enterprise finance is the hazard of ungrounded generative hallucinations. Adesha addresses this through architectural decoupling:
+- **Autonomous Reasoning & Governance (Adesha Proprietary Platform)**: Ingests unstructured invoices, interprets complex scopes of work, arbitrates commercial discrepancies, and formulates payment authorization leases.
+- **Deterministic Statutory Substrate ([`@mudraforge/statutory`](https://www.npmjs.com/package/@mudraforge/statutory))**: An open-source, zero-dependency legal knowledge format (OKF v0.2) and deterministic mathematical engine. All statutory determinations, cumulative thresholds, and tax formulas are calculated deterministically. Enterprise tax counsel and internal audit teams can inspect, verify, and run this substrate locally on-premise without external network communication.
 
-## 2. Pilot Objective
+---
 
-The primary objective of the proposed pilot is to evaluate historical vendor transactions against machine-readable statutory baselines to identify potential discrepancies in:
-1. **Withholding Tax (TDS) Classification**: Proper categorization under Section 194C (Contractors: 1% individual vs. 2% company), Section 194J (Technical Services 2% vs. Professional 10%), Section 194I (Rent: 2% machinery vs. 10% land/building), and Section 194H (Commission: 2% post-October 2024 vs. 5% prior).
-2. **Cumulative FY Threshold Handling**: Verifying whether cumulative vendor payments properly triggered statutory deduction gates upon crossing legal limits (e.g., Section 194Q ₹50 Lakhs excess, Section 194C ₹1 Lakh aggregate / ₹30,000 single bill).
-3. **GST Unbundling Adherence**: Checking whether withholding tax was deducted strictly on basic contract value or incorrectly calculated on gross invoice amounts including separately stated GST (CBDT Circular No. 23 of 2017).
-4. **Legislative Sunset Adherence**: Confirming that seller TCS under Section 206C(1H) was not applied to transactions post-1 April 2025.
-5. **MSME Delayed Payment Compliance**: Flagging payments to verified Micro and Small enterprises exceeding 15 days (oral) or 45 days (written agreement) under Sections 15 and 16 of the MSMED Act, 2006, along with associated Section 43B(h) disallowance risks.
+## 2. Core Pilot Objectives
+
+The Supervised Shadow Pilot benchmarks Adesha's autonomous decision-making against settled historical records across five primary compliance domains:
+
+1. **Withholding Tax (TDS/TCS) Classification & Rate Application**:
+   - Proper section categorization: Section 194C (Contractors: 1% individual vs. 2% company), Section 194J (Technical Services 2% vs. Professional 10%), Section 194I (Rent: 2% machinery vs. 10% land/building), and Section 194H (Commission: 2% post-October 2024 vs. 5% prior).
+   - Higher rate withholding for non-filers under Section 206AB (pre-1 April 2025) and invalid/inoperative PANs under Section 206AA (20% flat).
+2. **Cumulative Financial-Year Threshold & Excess Math**:
+   - Verification of cumulative purchase gates under Section 194Q: ensuring withholding is calculated strictly on the incremental purchase value exceeding ₹50 Lakhs within the financial year, rather than the entire invoice amount.
+   - Aggregate contractor thresholds under Section 194C (single invoice > ₹30,000 or aggregate > ₹1,00,000).
+3. **GST Basic Value Unbundling Adherence**:
+   - Verifying adherence to CBDT Circular No. 23 of 2017: confirming withholding was applied strictly to the basic taxable value and not computed on gross invoice totals inclusive of separately itemized CGST, SGST, or IGST.
+4. **Legislative Sunsets & Dual-Act Temporal Crystallization**:
+   - Confirming that seller TCS under Section 206C(1H) was omitted for transactions on or after 1 April 2025.
+   - Governing withholding crystallization by the earlier-event rule (earlier of credit in books or payment disbursement), correctly distinguishing between the Income-tax Act, 1961 and the Income-tax Act, 2025 (effective 1 April 2026).
+5. **MSME Delayed Payment Compliance & Section 43B(h)**:
+   - Tracking statutory payment clocks under Sections 15 and 16 of the MSMED Act, 2006 (15 days for unwritten terms, maximum 45 days for written agreements).
+   - Flagging compound interest liabilities at three times the RBI repo rate and identifying disallowance risks under Section 43B(h) of the Income-tax Act for amounts unpaid to Micro and Small suppliers at fiscal year-end, while applying the statutory trader exclusion (Office Memorandum 2/1(5)/2021).
 
 ---
 
-## 3. Proposed Candidate Inputs & Progressive Staging
+## 3. Candidate Ingestion Schema & Phased Staging
 
-To minimize operational effort for the customer's finance team, the proposed evaluation follows a staged approach:
+To minimize operational demands on enterprise accounting personnel, the pilot follows a two-stage progressive protocol:
 
-- **Stage 1 (Initial Calibration Sample — 30 to 50 Invoices)**: Begin with a targeted, representative sample of 30 to 50 historical invoices with known deduction outcomes and supporting records. This verifies column mappings, confirms ingestion formatting, and calibrates baseline rules with minimum time investment from the client.
-- **Stage 2 (Expanded Audit — 200 to 500 Invoices)**: Once the workflow, field mapping, and review protocols are established in Stage 1, the evaluation can expand to a full quarter's volume (200 to 500 records) to assess broad cumulative thresholds (such as Section 194Q and 194C cumulative annual limits).
+### Phase 1: Calibration & Field Alignment (30 to 50 Historical Invoices)
+A representative batch of 30 to 50 settled vendor invoices with known tax and payment outcomes is ingested. This phase validates data field mappings, verifies vendor classification schemas, and establishes baseline reconciliation rules with negligible customer effort.
 
-To perform the evaluation, the customer provides an export (CSV or structured tabular extract) containing the following fields:
+### Phase 2: Comprehensive Historical Shadow Benchmark (200 to 500 Historical Invoices)
+Following Phase 1 calibration, the evaluation expands to a full quarter's transaction volume (200 to 500 invoices). This volume enables robust validation of cumulative vendor spend thresholds (Section 194Q, Section 194C) and multi-month MSME payment clock tracking.
 
-| Field Group | Required Parameters | Purpose in Evaluation |
+### Data Ingestion Parameters
+The customer provides an archival tabular export (CSV, XLSX, or JSON extract) containing the following fields:
+
+| Field Group | Required Parameters | Analytical Purpose in Shadow Pilot |
 | :--- | :--- | :--- |
-| **Transaction Metadata** | Invoice Number, Invoice Date, Booking Date | Evaluates temporal validity and applicable legislative regime (1961 Act vs. 2025 Act). |
-| **Vendor Identity** | Vendor Legal Name, Entity Type (Individual, Firm, Co.), Vendor PAN, GSTIN | Determines applicable rate schedules (e.g. 1% vs 2% under 194C; 20% under 206AA if PAN missing). |
-| **Financial Values** | Basic Taxable Amount, CGST, SGST, IGST, Total Invoice Gross Amount | Verifies basic-value unbundling vs. gross withholding. |
-| **Statutory Classification** | Line-item expense description, historical TDS section applied, historical TDS amount deducted | Compares historical treatment against engine ground truth. |
-| **Settlement Dates** | Payment / Clearance Date, Payment Method | Measures settlement timelines against the MSMED statutory payment clock. |
-| **Enterprise Attributes** | Vendor MSME Registration Type (Micro, Small, Medium, Trader), Udyam Number (if on file) | Filters MSME delayed-payment rules (applying trader exclusion under OM 2/1(5)/2021). |
+| **Transaction Metadata** | Invoice Number, Invoice Date, ERP Booking Date | Establishes temporal validity, accounting credit timestamp, and legislative regime. |
+| **Vendor Identity** | Vendor Legal Name, Entity Type (Individual, LLP, Corporate), Vendor PAN, GSTIN | Determines applicable statutory rate tiers, corporate status, and Section 206AA rate penalties. |
+| **Financial Values** | Basic Taxable Amount, Itemized CGST, SGST, IGST, Total Gross Invoice Value | Assesses adherence to GST unbundling standards vs. gross withholding. |
+| **Historical ERP Classification** | Line-item description, historical TDS section applied, historical TDS amount withheld | Benchmarks human/ERP decisions against Adesha's deterministic statutory engine. |
+| **Settlement Details** | Payment / Bank Clearance Date, Historical Payment Method, Bank UTR (if recorded) | Measures settlement intervals against MSMED Act statutory clocks. |
+| **Vendor Master Attributes** | MSME Registration Category (Micro, Small, Medium, Trader), Udyam Number (if on file) | Drives MSME statutory interest calculations and Section 43B(h) disallowance risk analysis. |
 
 ---
 
-## 4. Processing Workflow & Exception Handling
+## 4. Adesha Shadow Execution Pipeline
 
-The evaluation runs as an offline, non-intrusive batch process:
+The Supervised Shadow Pilot operates entirely offline as a non-intrusive analytical pipeline:
 
 ```
-[Customer AP Extract] ──► Input Validation ──► Statutory Rule Engine ──► Discrepancy Analysis ──► Human Review Gate
-                                                                                                    ↓
-                                                                                        [Advisory Audit Report]
+[Customer Archival AP Extract]
+              │
+              ▼
+┌────────────────────────────────────────┐
+│  Phase 1: Ingestion & Input Validation │
+│  - Field schema verification           │
+│  - Tax identifier syntax validation    │
+└────────────────────────────────────────┘
+              │
+              ▼
+┌────────────────────────────────────────┐
+│  Phase 2: Semantic Reasoning & Parsing │
+│  - Scope of work analysis              │
+│  - Contractual term classification     │
+└────────────────────────────────────────┘
+              │
+              ▼
+┌────────────────────────────────────────┐
+│  Phase 3: Deterministic Grounding      │
+│  (@mudraforge/statutory)               │
+│  - Cumulative FY threshold evaluation  │
+│  - Statutory withholding rate derivation│
+│  - MSMED 15/45-day clock calculation   │
+└────────────────────────────────────────┘
+              │
+              ▼
+┌────────────────────────────────────────┐
+│  Phase 4: Simulated AP Orchestration   │
+│  - Single-use payment lease derivation │
+│  - Double-entry ERP journal simulation │
+└────────────────────────────────────────┘
+              │
+              ▼
+┌────────────────────────────────────────┐
+│  Phase 5: Reconciliation & Variance    │
+│  - Delta analysis vs. historical ERP   │
+│  - Fail-closed ambiguity isolation     │
+└────────────────────────────────────────┘
+              │
+              ▼
+[Advisory Discrepancy & Verification Report]
 ```
 
-### The Human-in-the-Loop Ambiguity Standard
-In real-world finance operations, certain vendor invoices present legal ambiguities that cannot be resolved from numbers alone (e.g., mixed composite contracts involving both equipment supply and installation labour).
+### The Fail-Closed Ambiguity Standard
+In corporate finance, certain transactions contain contractual ambiguities that cannot be resolved solely from ledger metadata (for example, composite contracts spanning both equipment hardware supply and specialized engineering services).
 
-- **Explicit Fail-Closed Policy**: The evaluation engine does not guess or force an arbitrary classification on ambiguous transactions.
-- **Flagged Review Categories**: When input data lacks sufficient granularity (such as missing scope-of-work documentation or ambiguous GST itemization), the system categorizes the record as `REQUIRES_HUMAN_REVIEW` with an explicit note explaining the legal assumption required.
+- **Strict Fail-Closed Policy**: Adesha does not generate arbitrary tax assumptions or probabilistic guesses on ambiguous transactions.
+- **Flagged Review Categories**: When archival data lacks necessary granularity (such as missing scope-of-work documentation or unbundled tax breakdowns), Adesha categorizes the item as `REQUIRES_HUMAN_REVIEW` accompanied by an explicit legal justification detailing the evidentiary prerequisite.
 
 ---
 
-## 5. Pilot Deliverables
+## 5. Pilot Deliverables & Tri-Part Variance Classification
+
+At the conclusion of the evaluation, the enterprise finance leadership receives a comprehensive **Advisory Accounts Payable Discrepancy & Verification Report** comprising:
 
-At the conclusion of the evaluation, the customer receives an **Advisory Accounts Payable Discrepancy & Verification Report** comprising:
+### 1. Executive Summary
+- Total transaction count evaluated vs. records with complete statutory determinability.
+- Aggregate count and value of historical transactions matching statutory baseline.
+- Aggregate count and value of identified statutory variances and compliance risks.
 
-1. **Executive Findings Summary**:
-   - Total records evaluated vs. records with complete statutory determinability.
-   - Aggregate count of matched historical treatments.
-   - Aggregate count of flagged statutory variances.
-2. **Detailed Discrepancy Register (Tri-Part Classification)**:
-   Findings are strictly classified into three distinct categories to avoid premature legal assumptions:
-   - **Category A — Confirmed Calculation Differences**: Mathematical or rounding discrepancies on settled statutory rates, unbundled GST arithmetic, or clearly crossed financial thresholds.
-   - **Category B — Potential Statutory Discrepancies**: Inconsistent rates or threshold treatments where all input facts (PAN, entity type, invoice date) appear complete on the face of the record.
-   - **Category C — Items Requiring External Documentation Verification**: Apparent rate differences that may be legally justified by unrecorded external documents (e.g. an Assessing Officer certificate for lower deduction under Section 197, a Section 194C(6) goods transporter ownership declaration, or an MSME trader NIC classification exclusion). The report flags these as *verification checkpoints* rather than claiming a tax error.
-3. **Statutory Audit Trail**:
-   - For every flagged variance: the exact governing statute, applicable section code, official Gazette citation, and relevant CBDT/CBIC executive circular.
-4. **Unresolved Assumptions Log**:
-   - Comprehensive inventory of records requiring internal company tax counsel determination.
+### 2. Tri-Part Variance Classification Register
+To provide actionable clarity without premature legal assumptions, all identified variances are categorized into three distinct classes:
 
-> **Important Commercial Notice**: The pilot report is strictly analytical and advisory. MudraForge does not guarantee that a pilot will discover historical errors, recoverable tax sums, or cash savings; the value of the evaluation is establishing an empirical baseline of compliance consistency.
+- **Category A — Confirmed Calculation & Threshold Variances**:
+  Direct mathematical, rounding, or threshold calculation errors on settled law. Examples include withholding tax deducted on gross invoice totals instead of net basic amounts, or Section 194Q applied to the full invoice rather than the excess over ₹50 Lakhs.
+- **Category B — Statutory Rate & Classification Discrepancies**:
+  Inconsistent statutory classifications where all transaction attributes (PAN, entity type, invoice date) are complete on the face of the record. Examples include applying Section 194C (2%) to professional services governed by Section 194J (10%), or applying Section 206C(1H) post-sunset.
+- **Category C — Documentation Verification Checkpoints**:
+  Instances where historical treatment differed from statutory defaults but may be legally substantiated by external documents not present in the tabular ledger. Examples include lower-withholding certificates issued under Section 197, goods transporter declarations under Section 194C(6), or MSME trader NIC classification exclusions. These items are presented as *verification checkpoints* for internal tax counsel rather than asserting non-compliance.
 
-### What the Proposed Pilot Demonstrates vs. What It Cannot Establish
+### 3. Statutory Audit Trail
+Every identified variance includes direct, canonical citations to the governing statute, section number, official Gazette notification, and relevant CBDT/CBIC executive circular.
 
-| What the Pilot Can Demonstrate | What It Cannot Establish by Itself |
+### 4. Shadow Double-Entry Journal Reconciliation
+For every invoice, Adesha generates a simulated double-entry journal voucher (Debit Expense, Debit Input Tax, Credit Vendor Payable, Credit TDS Payable). This simulated voucher is compared against the historical ERP general ledger journal to highlight booking discrepancies.
+
+### Analytical Scope & Boundary Commitments
+
+| What the Supervised Shadow Pilot Demonstrates | What It Cannot Establish by Itself |
 | :--- | :--- |
-| The engine can process customer-supplied historical invoice extracts. | It can seamlessly ingest every ERP or arbitrary billing format without custom mapping. |
-| Calculations agree with independently verified tax outcomes on clear-cut cases. | Every statutory interpretation or tax deduction across all scenarios is legally infallible. |
-| Discrepancies and assumptions are fully traceable to primary gazette citations. | The client will necessarily achieve a specific financial saving or tax recovery. |
-| Repeat runs on the same input data produce mathematically identical results. | Production deployment readiness, real-time banking security, or live ERP integration. |
+| Adesha accurately parses and interprets historical AP extracts. | Instantaneous ingestion of proprietary ERP schemas without initial field mapping. |
+| Mathematical and statutory determinations strictly agree with independent tax ground truth. | Legal infallibility across non-standard or unresolved statutory litigation edge cases. |
+| Complete audit traceability from every recommendation to primary gazette citations. | Guaranteed immediate financial recovery or cash tax refunds. |
+| Repeat deterministic runs on identical archival inputs produce mathematically identical results. | Production-grade real-time banking security or live ERP multi-region high availability. |
 
 ---
 
-## 6. Security, Confidentiality & Data Handling
+## 6. Security, Confidentiality & Data Protection
 
-> **Confidentiality Note on Historical Data**: Historical accounts payable records are not zero-risk. Invoices contain confidential supplier identities, commercial pricing structures, PANs, and banking metadata. Running locally or within customer-designated infrastructure minimizes external exposure, but strict data handling, field masking, and deletion agreements remain mandatory prerequisites before transferring any real records.
+Corporate accounts payable records contain commercially sensitive supplier pricing, bank account details, and corporate tax identifiers. The Supervised Shadow Pilot adheres to strict security protocols:
 
-To protect enterprise data, the pilot protocol defines clear operational boundaries:
+### Baseline Execution Boundaries
+- **On-Premise / Private Cloud Execution**: The pilot engine and open `@mudraforge/statutory` substrate can run entirely within the enterprise's private network or local workstation environment with zero external data egress.
+- **Strictly Read-Only Ingestion**: Adesha accesses only the historical extract provided by the customer. It possesses zero programmatic access to active ERP systems, production databases, or banking networks.
 
-### Verified Baseline Capabilities
-- **Local / On-Premise Execution Option**: The core evaluation engine and statutory commons can execute locally within the customer's designated environment with zero external network connectivity.
-- **Read-Only Scope**: The evaluation accesses only historical records provided by the customer. It contains no programmatic write access to the customer's ERP, general ledger, or banking infrastructure.
-
-### Pilot Prerequisites (To Be Agreed in Writing Prior to Initiation)
-Prior to transferring any sample data or initiating evaluation scripts, the parties will establish:
-1. **Bilateral Non-Disclosure Agreement (NDA)**: Governing proprietary financial and supplier pricing data.
-2. **Customer-Side Field Masking / Anonymization**: The customer may optionally hash or mask sensitive fields (such as bank account numbers or internal vendor IDs) prior to transmission.
-3. **Data Retention & Disposal Schedule**: Agreement on secure disposal of evaluation extracts within a defined period (e.g., 30 days post-report delivery).
-4. **Environment Specification**: Mutual agreement on whether processing occurs on customer-controlled workstations or a private cloud environment.
+### Information Governance Protocols
+Prior to ingesting customer records, standard enterprise safeguards are established:
+1. **Bilateral Non-Disclosure Agreement (NDA)**: Protecting all vendor commercial terms, volume discounts, and operational financial metrics.
+2. **Customer-Side Pseudonymization**: The enterprise may hash or redact sensitive identifiers (such as bank account numbers or internal vendor keys) prior to transmission.
+3. **Data Disposal Mandate**: Certified cryptographic deletion of all evaluation datasets upon delivery and acceptance of the final audit report.
 
 ---
 
-## 7. Strict Operational Boundaries
+## 7. Strict Operational Safeguards
 
-To prevent operational ambiguity, the boundaries of this proposed pilot are explicitly defined:
+To maintain clear enterprise governance, the pilot operates under absolute operational restrictions:
 
-- **No Live Ledger Mutations**: The pilot will not post journal entries, alter general ledger balances, or modify vendor records in the customer's accounting system (SAP, Zoho Books, Tally, NetSuite).
-- **No Money Movement**: The pilot does not connect to banking APIs, issue payment orders, or disburse funds.
-- **No Regulatory Filing**: The pilot does not generate or submit Form 26Q returns or TDS challans to the Income Tax Department.
-- **Not Formal Legal Advice**: Deliverables constitute technical compliance analysis and do not replace legal opinions from the customer's statutory tax auditors or legal counsel.
+- **Zero Live Ledger Mutations**: Adesha will not write back journals, alter vendor balances, or modify general ledger accounts in SAP, Zoho Books, NetSuite, Oracle, or Tally.
+- **Zero Banking Rail Access**: Adesha does not connect to corporate banking APIs, initiate wire transfers, or hold authority to disburse funds.
+- **Zero Regulatory Submissions**: Adesha will not generate or transmit Form 26Q quarterly returns or TDS challans to government portals.
+- **Technical Advisory Designation**: All deliverables constitute technical compliance analysis and do not replace formal legal or statutory audit opinions from certified enterprise tax counsel.
 
 ---
 
-## 8. Success & Evaluation Criteria
+## 8. Quantitative Evaluation & Acceptance Benchmarks
 
-Before initiating a pilot, both parties agree to measurable evaluation benchmarks:
+The success of the Supervised Shadow Pilot is measured against objective, pre-agreed quantitative benchmarks:
 
-| Criterion | Definition | Evaluation Metric |
+| Evaluation Benchmark | Objective Definition | Success Threshold |
 | :--- | :--- | :--- |
-| **Input Completeness** | Sufficiency of customer data to determine statutory applicability | Percentage of records with complete necessary fields ($\ge 90\%$ target) |
-| **Calculation Accuracy** | Agreement on clear-cut cases governed by settled law | $100\%$ mathematical and threshold agreement on verified records |
-| **Ambiguity Handling** | Clean separation of uncertain cases without hallucinated conclusions | $100\%$ of incomplete or composite records flagged for human review |
-| **Statutory Traceability** | Every variance cited to primary gazette or executive circular | $100\%$ citation resolution to official government sources |
-| **Audit Reproducibility** | Repeated runs across the same dataset produce identical outputs | Zero variance across repeat deterministic runs |
+| **Input Completeness** | Proportion of archival records with sufficient parameters to evaluate statutory applicability | $\ge 90\%$ of provided dataset |
+| **Calculation Accuracy** | Agreement with settled statutory ground truth on unambiguous records | $100\%$ precision on verified provisions |
+| **Ambiguity Isolation** | Strict fail-closed categorization of records lacking necessary documentation | $100\%$ isolation of uncertain records |
+| **Citation Traceability** | Traceability of every flagged variance to deep primary government endpoints | $100\%$ verified canonical citations |
+| **Deterministic Reproducibility** | Mathematical identity across repeat runs on the same input dataset | Zero variance across repeated runs |
 
 ---
 
-## 9. Initiating a Pilot Discussion
+## 9. Initiating a Supervised Shadow Pilot
+
+To schedule an architecture review, receive sample ingestion schemas, or coordinate a Supervised Shadow Pilot for your finance organization:
 
-To discuss a proposed historical AP evaluation, review sample schema formats, or coordinate data requirements:
-- **Email**: [hello@mudraforge.in](mailto:hello@mudraforge.in) or [support@mudraforge.in](mailto:support@mudraforge.in)
+- **Enterprise Inquiries**: [hello@mudraforge.in](mailto:hello@mudraforge.in) or [support@mudraforge.in](mailto:support@mudraforge.in)
 - **Direct Founder Contact**: Mondeep Engti at [mondeepe@gmail.com](mailto:mondeepe@gmail.com)
-- **Official Documentation**: [https://mudraforge.in/docs](https://mudraforge.in/docs)
+- **Technical Architecture Documentation**: [https://mudraforge.in/docs](https://mudraforge.in/docs)
+- **Open Trust Anchor Repository**: [https://github.com/mondeep0123/mudraforge-statutory](https://github.com/mondeep0123/mudraforge-statutory)

package/docs/PROVENANCE.md

@@ -8,17 +8,17 @@ This document records the cryptographic provenance, normative specifications, an
 
 | Item | Value |
 |---|---|
-| **Package Release** | **`v2.8.1`** (Stable Patch Release) |
+| **Package Release** | **`v2.9.0`** (Production Release) |
 | **Knowledge Specification** | **Google Open Knowledge Format (OKF v0.2) + MudraForge Statutory Schema Extension** |
 | **Regulatory Snapshot** | **CBDT / CBIC / MCA / MSME Baseline: October 2026** |
-| **Corpus Quality Card** | 100% Citation Resolution (15/15 URLs) in [`docs/CORPUS_QUALITY.md`](./CORPUS_QUALITY.md) |
+| **Corpus Quality Card** | 100% Primary Citation Resolution (76/76 URLs verified; 108 citations across 29 provisions) in [`docs/CORPUS_QUALITY.md`](./CORPUS_QUALITY.md) |
 | **Architecture Decision Records** | 6 Normative ADRs documented in [`docs/ARCHITECTURE_DECISIONS.md`](./ARCHITECTURE_DECISIONS.md) |
 | **Vendor Conformance Suite** | 12/12 Passing Fixture Tests in [`conformance/`](../conformance/) |
 | **End-to-End Execution Trace** | Audited 7-stage AP lifecycle in [`examples/`](../examples/) (`npm run example:trace`) |
 | **Enterprise Assurance Preview** | Formal TLA+ & mutation defenses in [`docs/ADESHA_ASSURANCE_OVERVIEW.md`](./ADESHA_ASSURANCE_OVERVIEW.md) |
-| **Integrity Root** | SHA-256 root manifest in [`okf/manifest.json`](../okf/manifest.json) (reproducible byte-level non-tampering proof) |
+| **Integrity Root** | SHA-256 root manifest in [`okf/manifest.json`](../okf/manifest.json) (`sha256-4bbe36c3db841b833dd2bebbd6c1c5ed735498e7b20d1221c323ceb211529fe0` across 86 files) |
 | **Temporal Framework** | Dual-Act Bridge: *Income-tax Act, 1961* & *Income-tax Act, 2025* |
-| **Verification Gate** | 100% Pass across cumulative thresholds, legislative sunsets, and excess math |
+| **Verification Gate** | 100% Pass across all 80 test suites (cumulative thresholds, legislative sunsets, and excess math) |
 
 ---