pramana-protocol 1.0.0

package/LICENSE

@@ -0,0 +1,16 @@
+Apache License 2.0
+
+Copyright 2026 PowerPbox IT Solutions Pvt Ltd
+Author: Capt. Anil Kumar Sharma
+
+Licensed under the Apache License, Version 2.0 (the "License");
+you may not use this file except in compliance with the License.
+You may obtain a copy of the License at
+
+    http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.

package/PAPER.md

@@ -0,0 +1,620 @@
+# PRAMANA: A Self-Verifying Cognition Protocol for AI-Native Service Universes
+
+**Author:** Capt. Anil Kumar Sharma
+**Affiliation:** PowerPbox IT Solutions Pvt Ltd, Haryana, India (DPIIT Registered Startup)
+**Email:** capt.anil.sharma@powerpbox.org
+**Date:** 2026-03-28
+**Category:** cs.AI, cs.DC, cs.SE
+**Keywords:** AI service orchestration, knowledge verification, capability registry, epistemology, service mesh, RCA loop, SLM integration
+
+---
+
+## Abstract
+
+As AI-native service universes scale beyond 100 services, a structural problem emerges: no single agent, router, or gateway can verify whether a response was generated from a valid capability, a valid rule, and a valid delivery outcome — simultaneously. Existing approaches (service meshes, API gateways, knowledge graphs) solve routing or observability, but not *cognition correctness*. We present PRAMANA — a self-verifying cognition protocol named after Dharmakīrti's (c. 600–660 CE, Nalanda) epistemological framework for valid cognition. PRAMANA binds three verification strands — capability, knowledge, and proof — through four signals: STATE, TRUST, SENSE, and PHALA. The novel contribution is PHALA: a delivery outcome signal that returns to the *source rule*, not the service log. Every delivery reaffirms or challenges the rule that generated the answer, creating a recursive RCA loop that can train a Small Language Model (SLM) when plugged in. PRAMANA is not theoretical — it is documented from a working implementation across 200+ services, 5,336 domain rules, and 174 audited capability declarations. The authenticity marker system (PRAMANA-0 through PRAMANA-3+) provides a binary-per-strand checklist that any downstream agent or human can interpret without probabilistic reasoning.
+
+---
+
+## 1. Introduction: The Hallucination Problem at Scale
+
+The canonical hallucination problem in AI systems is well-studied at the model level: a language model generates plausible but factually incorrect text [CITATION-Brown2020]. Less studied — and more dangerous in production — is hallucination at the *orchestration* level: a router claiming a service can perform an action it cannot, a knowledge system answering from a stale rule, or an audit system certifying a delivery that was never verified.
+
+These are not model hallucinations. They are *architectural* hallucinations — systematic misrepresentations that emerge when capability declarations, knowledge bases, and delivery proofs are maintained independently, without a binding protocol.
+
+At 10 services, a developer can hold the map in their head. At 50, documentation begins to drift. At 100, the documentation *is* the hallucination — current in form, stale in fact. At 200+, no human or system can audit the intersection of "what a service claims to do," "what rules it applies," and "whether its answers were correct last week." The gap between declared capability and demonstrated truth becomes the single largest source of trust failure in AI-native enterprises.
+
+The Mumbai dabbawallah system offers an instructive parallel. Five thousand workers deliver 200,000 tiffin boxes daily across a city of 20 million people, achieving Six Sigma accuracy (3.4 defects per million opportunities) [CITATION-Thomke2012] — without computers, without GPS, without AI. The system works because it solves two distinct problems simultaneously: *routing correctness* (does the dabba reach the right desk?) and *source correctness* (is the content of the dabba what the sender intended?). Confusing these two problems — treating a routing failure as a content failure, or vice versa — would have destroyed the system decades ago.
+
+PRAMANA is built on this insight. Routing correctness is solved by binding three strands: capability declaration (AnkrCodex), domain knowledge (Knowledge Codex), and build proof (CCA). Source correctness is solved by PHALA — the fourth signal — which returns delivery outcomes to the source rule, not the service log. The two problems are distinct. The protocol solves both.
+
+This paper documents PRAMANA as a working protocol, implemented across the ANKR universe (200+ AI-native services, Customer Zero), and presents it as a generalizable specification for any organization operating AI-native service universes at scale.
+
+---
+
+## 2. Background
+
+### 2.1 Dharmakīrti and the Epistemology of Valid Cognition
+
+Dharmakīrti (धर्मकीर्ति, c. 600–660 CE) was the greatest logician of the Nalanda tradition. His *Pramāṇavārttika* (Commentary on Valid Cognition) defined the epistemological conditions under which a cognition is *valid* — not merely plausible or coherent. His framework identified two primary sources of valid cognition (*pramana*):
+
+1. **Pratyaksha** (प्रत्यक्ष) — direct perception. Knowledge obtained by direct observation, without inference. In protocol terms: a live STATE endpoint returning current capability data.
+
+2. **Anumana** (अनुमान) — inference. Valid reasoning from reliable premises. In protocol terms: a Knowledge Codex rule applied to a declared capability, yielding a conclusion with traceable reasoning.
+
+Dharmakīrti's key contribution was not merely cataloguing these two sources, but defining the conditions under which each *generates valid cognition*: pratyaksha must be non-erroneous (avisamvadin), and anumana must proceed from reliable invariable concomitance (vyapti). A cognition that cannot demonstrate either condition is *not a pramana* — it is *apramana*, invalid cognition.
+
+PRAMANA operationalizes this: every answer generated by an AI-native service must demonstrate which strand(s) generated it, whether each strand was verified, and what outcome it produced. An answer that cannot demonstrate any strand is PRAMANA-0 — explicitly marked as requiring human verification. The protocol does not suppress uncertain answers; it *labels* them.
+
+The third Nalanda concept that PRAMANA borrows is **Purva-paksha** (पूर्वपक्ष) — the prior inference, the best available reasoning from accumulated knowledge. When a delivery fails, the RCA loop fires Purva-paksha: "given this failure, what rule most plausibly generated this answer?" The human's correction becomes **Siddhanta** (सिद्धांत) — the established truth that supersedes the prior inference. This Purva-paksha / Siddhanta dialectic, formalized in Nalanda debate methodology, becomes the training signal for the SLM integration.
+
+### 2.2 The Dabbawallah System as Operational Analogue
+
+The Mumbai dabbawallah (literally "one who carries a box") system has been the subject of multiple management studies [CITATION-Thomke2012, CITATION-Roncaglia2013] and a Forbes Six Sigma certification. Key operational properties:
+
+- **5,000 workers, 200,000 tiffins/day** — city-scale logistics without computational infrastructure
+- **Six Sigma accuracy** — 3.4 defects per million deliveries, verified across multiple independent studies
+- **Alphanumeric coding system** — each tiffin carries a destination code readable by workers with varying literacy levels. The code encodes: source building, destination building, floor, route segment.
+- **Distributed verification** — each handoff point verifies the code before accepting a tiffin. A mismatch is caught at handoff, not at destination.
+- **No central tracker** — the system is self-verifying at each node. There is no "God's eye view." Correctness emerges from distributed local verification.
+
+Two lessons structure PRAMANA's design:
+
+**Lesson 1: Routing and source are distinct problems.** A tiffin can arrive at the wrong desk (routing failure) or the right desk with wrong food (source failure). The coding system solves routing. The sender — the home kitchen — must solve source. The dabbawallah system makes this boundary explicit. PRAMANA makes the equivalent boundary explicit in AI service delivery.
+
+**Lesson 2: Distributed local verification scales; central verification does not.** At 200,000 tiffins/day, no central verifier can audit every delivery. Each handoff node verifies its segment. PRAMANA's strand-per-service verification follows the same pattern: each service verifies its own strand at declaration time. AnkrCodex aggregates, but does not re-verify.
+
+### 2.3 Limitations of Existing Approaches
+
+**Service meshes** (Istio, Linkerd, Consul Connect) solve traffic management, circuit breaking, and mutual TLS between services. They do not model *capability* (what a service can do), *knowledge* (what rules it applies), or *outcome correctness* (whether the answer was right). A service mesh can tell you that a request reached its destination and returned a 200 OK. It cannot tell you whether the 200 OK was epistemically valid.
+
+**API gateways** (Kong, AWS API Gateway, NGINX) solve routing, rate limiting, and authentication. They operate on request/response envelopes. They are agnostic to the semantic content of what was routed. Gateway telemetry shows latency and error rates; it does not show whether the routed service applied the correct rule.
+
+**Knowledge graphs** (Neo4j, Amazon Neptune, Wikidata) model domain knowledge as entity-relation triples. They do not model service capabilities, do not emit runtime signals, and do not bind knowledge to delivery outcomes. A knowledge graph can answer "what rule governs container dwell time?" It cannot tell you whether the service that consumed that rule applied it correctly last Tuesday.
+
+**RAG pipelines** (Retrieval-Augmented Generation) retrieve relevant context for LLM generation. They solve knowledge injection but not capability verification, not delivery proof, and not outcome-to-source-rule feedback. The retrieved context may be correct; the service receiving it may not have the capability to act on it; the action may produce a wrong answer; the wrong answer has no path back to the rule that generated it.
+
+PRAMANA is not a replacement for any of these. It is the *binding protocol* that sits above them, connecting capability declaration, knowledge application, and delivery outcome into a single verifiable chain.
+
+---
+
+## 3. The PRAMANA Protocol
+
+### 3.1 Three Strands
+
+PRAMANA defines three verification strands. Each strand addresses a distinct failure mode. All three must be present for full authenticity (PRAMANA-3).
+
+**Strand 1 — Capability (AnkrCodex)**
+
+The capability strand answers: *can this service do what it claims?* Every PRAMANA-compliant service declares its capabilities via a `codex.json` file containing:
+
+```json
+{
+  "service": "trademitra",
+  "can_answer": ["fta-eligibility", "duty-rate-lookup"],
+  "can_do": ["FTA_CHECK", "ALERT_ACK"],
+  "trust_mask": "0x00FF0700"
+}
+```
+
+The `trust_mask` is a 32-bit integer encoding capabilities as bit flags. `(mask & FTA_CHECK) !== 0` is a binary proof of capability — not a lookup, not a search, not a probabilistic assessment. The bit is either set or it is not. At 200 services, the capability query across all services is a bitwise AND across 200 rows — sub-millisecond, zero interpretation, zero hallucination possible.
+
+AnkrCodex crawls all capability declarations periodically and on service restart, maintaining a centralised capability registry. The crawler reads declared state; it does not infer it. A service whose bit is not set cannot be routed a request for that capability, regardless of what its documentation or its developer claims.
+
+**Strand 2 — Knowledge (Knowledge Codex)**
+
+The knowledge strand answers: *did this service apply a valid rule?* Every PRAMANA-compliant domain has its rules indexed in the Knowledge Codex (GRANTHX in the reference implementation) using a three-layer structure:
+
+- **SHASTRA** (शास्त्र) — domain statutes. What the law, regulation, or convention says is true. Rule type: `statute`. Example: `LAY-001: Laytime commences from NOR acceptance.`
+- **YUKTI** (युक्ति) — modus operandi. How experts reason in this domain. Classify first. Branch on context. Example: `MAR-YK-001: Before applying any laytime rule, first classify the cargo type and port type.`
+- **VIVEKA** (विवेक) — inference library. Pre-computed expert conclusions for common fact patterns. Fields: input conditions, conclusion, rules applied, confidence, caveat. Example: `INF-LAY-001: If voyage charter + NOR tendered at anchorage + WIBON clause + port congestion — laytime does not commence until berth available.`
+
+Every answer generated from Strand 2 must cite the rule ID that generated it. The citation is the verification. An answer citing `INF-LAY-001` can be traced to its SHASTRA premises and its YUKTI reasoning path. An answer with no rule citation is PRAMANA-0 from Strand 2's perspective.
+
+**Strand 3 — Proof (CCA — Capability Closure Audit)**
+
+The proof strand answers: *was this service built as its rules and capability declaration say?* CCA audits the intersection of declared capability (Strand 1) and indexed knowledge (Strand 2) against the actual service implementation. It answers: for each declared capability, is there a code path that implements it, and is that code path annotated with the rule ID it implements?
+
+The annotation convention is:
+```typescript
+// @rule:LAY-001 — Laytime commencement on NOR acceptance
+function computeLaytimeStart(nor: NORRecord): Date {
+  ...
+}
+```
+
+CCA sweeps all annotated decision points, cross-references against the knowledge codex, and produces a proof coverage percentage. A service with `proof_config.coverage_pct = 0.0` has declared a capability it has not proven. A service with `coverage_pct >= 90.0` is PRAMANA-3 on Strand 3.
+
+The three strands are orthogonal. A service can have full capability declaration (Strand 1 complete) with zero knowledge indexing (Strand 2 absent) and zero proof coverage (Strand 3 absent) — and PRAMANA will label it exactly that way. There is no rounding up. There is no aggregate score that obscures strand-level gaps.
+
+### 4.2 Four Signals
+
+PRAMANA defines four signals that every compliant service must emit. The first three are operational (adapted from the Forja protocol); the fourth is novel.
+
+**STATE** — What the service knows and can do. Emitted at boot and on capability change. Consumed by AnkrCodex. Format: JSON containing `can_answer`, `can_do`, `strand_status` (per-strand boolean). Endpoint: `GET /api/v2/forja/state`.
+
+**TRUST** — What a given principal is authorized to do. Emitted per-request. Contains the `trust_mask` for the requesting user/role. Endpoint: `GET /api/v2/forja/trust/:userId`. The trust mask is the intersection of the service's capability mask and the principal's role mask — never wider than either.
+
+**SENSE** — What is happening inside the service. Runtime events: a rule was applied, a confidence threshold was crossed, a human escalation was triggered. Published to a SENSE bus. Consumers subscribe to event types relevant to their domain. Endpoint: `POST /api/v2/forja/sense/emit`. SENSE is the observability signal; it does not carry outcome data.
+
+**PHALA** — Delivery outcome, returned to source rule. This is the novel signal. Detailed in Section 5.
+
+### 4.3 The Recursive Mini-Loop: READ → ROUTE → RECORD
+
+Every PRAMANA interaction follows a three-step mini-loop:
+
+**READ** — The requesting agent reads the AnkrCodex to find which service(s) can answer the query. The read is a bitmask AND across all registered services. Output: a ranked list of services with the required capability bit set.
+
+**ROUTE** — The request is routed to the highest-ranked service. The service applies its knowledge (Strand 2), executes its proof-annotated code (Strand 3), and generates a response. The response carries a PRAMANA authenticity marker (see Section 4.4) indicating which strands were active for this specific response.
+
+**RECORD** — The delivery is recorded. The PHALA signal is emitted: the outcome (correct/incorrect/unknown, as determined by downstream feedback) is sent to the source rule, not the service log. The source rule's `delivery_count` and `correct_count` are incremented. The rule's `reliability_score` is updated.
+
+The loop is recursive because RECORD feeds back into READ: a rule whose `reliability_score` falls below threshold is flagged in the Knowledge Codex, which affects the service's Strand 2 status, which affects its ranking in the next READ cycle.
+
+### 4.4 Authenticity Markers
+
+Every PRAMANA response carries an authenticity marker — a binary-per-strand checklist, not a probability score. The marker is computed at response time and attached to the response envelope.
+
+```
+PRAMANA-0: No strand verified. System answered anyway. MANDATORY human review.
+PRAMANA-1: One strand verified. System must name which strand and explain why it answered.
+PRAMANA-2: Two strands verified. System must name the missing strand.
+PRAMANA-3: All three strands verified. Full authentic response.
+PRAMANA-3+: All three strands verified + SLM inference layer active. Inference cited.
+```
+
+The marker is human-readable and machine-parseable. A downstream agent receiving a PRAMANA-0 response knows it must escalate to a human. A downstream agent receiving a PRAMANA-3+ response knows it can act autonomously within its trust mask. There is no ambiguity between these states because the marker is binary per strand — it cannot be "mostly PRAMANA-2."
+
+The design deliberately rejects probability scores for authenticity marking. A 78% confidence score is meaningless to a ship captain deciding whether to accept a Notice of Readiness, to a trade compliance officer deciding whether an HS code is correct, or to a bank deciding whether a Letter of Credit clause is enforceable. Binary strand verification is meaningful: "this answer was generated from a verified rule, by a service with a declared and audited capability for this action, and the rule has a 94.2% delivery accuracy over the last 30 days" — each clause verifiable, each clause actionable.
+
+---
+
+## 5. The PHALA Signal — Novel Contribution
+
+PHALA (फल — Sanskrit: fruit, outcome, result) is the fourth PRAMANA signal. It is the element absent from all existing protocols reviewed in Section 2.3, and it is what transforms PRAMANA from an observability framework into a *self-verifying cognition protocol*.
+
+### 5.1 The Routing-Source Distinction, Formalized
+
+Existing protocols return outcome signals to services (service logs, distributed tracing spans, error rate dashboards). This is *routing feedback*: the delivery system learns which routes were reliable. The *source* — the rule that generated the answer — receives no signal. It cannot learn. It cannot be corrected without manual inspection of logs, manual identification of the causal rule, and manual update to the knowledge base. At 5,336 rules across 200 services, manual correction is operationally impossible.
+
+PHALA closes this gap. When a delivery produces an outcome — confirmed correct by a downstream agent or human, flagged incorrect by the same, or returned as ambiguous — the PHALA signal carries:
+
+```json
+{
+  "phala_type": "DELIVERY_OUTCOME",
+  "source_rule_id": "INF-LAY-001",
+  "service": "mari8x-voyage",
+  "request_id": "req_1743xxxxxx",
+  "outcome": "correct | incorrect | ambiguous",
+  "outcome_detail": "Laytime calculated as per clause, accepted by counterparty.",
+  "delivered_at": "2026-03-28T11:42:00Z",
+  "phala_version": "1.0"
+}
+```
+
+The signal goes to the Knowledge Codex's PHALA endpoint, which updates the source rule's delivery record:
+
+```
+INF-LAY-001:
+  delivery_count: 847
+  correct_count: 831
+  ambiguous_count: 11
+  incorrect_count: 5
+  reliability_score: 0.981
+  last_incorrect: 2026-03-21T08:14:00Z
+  rca_triggered: true
+```
+
+### 5.2 Why Source, Not Service
+
+The distinction matters architecturally. A service may apply hundreds of rules across thousands of deliveries. If an incorrect delivery is attributed to the service, the signal is too coarse: *which* rule failed? The service cannot self-correct without knowing. If the signal is attributed to the source rule, the correction is precise: *this specific inference, under this specific fact pattern, produced an incorrect result*.
+
+The source rule can then be updated, deprecated, or flagged for human review — without touching the service. The service's capability declaration remains intact. Its build proof remains intact. Only the knowledge strand is affected, and only at the specific rule that failed.
+
+This is the dabbawallah insight applied: a routing failure (the dabba went to the wrong desk) and a source failure (the tiffin contained the wrong food) require different corrections. Conflating them — correcting the routing system when the source was wrong — leaves the source failure unresolved.
+
+### 5.3 PHALA Without an SLM
+
+PHALA is useful without an SLM. The reliability score alone provides:
+
+1. **Rule health monitoring** — rules with `reliability_score < 0.85` are automatically flagged for review
+2. **Routing influence** — services applying flagged rules are deprioritized in the READ step
+3. **Audit trail** — every rule's delivery history is queryable, providing regulatory audit capability
+4. **Human escalation triggers** — a rule with 3+ incorrect deliveries in 7 days triggers a mandatory human review before the next application
+
+These four functions operate entirely within the PRAMANA base loop. No SLM required.
+
+### 5.4 PHALA With an SLM
+
+When an SLM is integrated, PHALA's signal becomes a training input. The RCA loop (Section 6) identifies which rule failed, under which fact pattern, and what the correct answer would have been. The `(fact_pattern, rule_applied, correct_answer)` triple is a supervised training example. Accumulated over thousands of deliveries, it fine-tunes the SLM's inference on the exact rules and fact patterns that have historically caused failures.
+
+This is not generic fine-tuning on domain text. It is failure-specific training on real delivery outcomes, tied to specific rule IDs and specific fact patterns. The resulting SLM is not "a maritime SLM" — it is "a maritime SLM that has been corrected 847 times on INF-LAY-001 specifically, and now applies it correctly in 99.3% of cases."
+
+The SLM integration is a plugin, not a dependency. The base PRAMANA loop operates at full functionality without it.
+
+---
+
+## 6. The RCA Loop and SLM Integration
+
+### 6.1 RCA Trigger Conditions
+
+The Root Cause Analysis (RCA) loop triggers when PHALA records an `outcome: "incorrect"` for any rule. The loop proceeds in three phases.
+
+**Phase 1 — Failure Classification**
+
+PRAMANA classifies the failure into one of three types:
+
+- **Routing failure** — the correct service was not selected. The capability bit was set incorrectly, or the READ step selected a lower-ranked service. Correction: update the trust mask or capability declaration.
+- **Rule application failure** — the correct rule was selected but applied incorrectly to the fact pattern. The rule's logic is sound; the service's implementation diverged. Correction: update the service code path annotated with `@rule:{RULE-ID}`.
+- **Rule correctness failure** — the rule itself is incorrect or outdated. The service applied it correctly; the rule is wrong. Correction: update the Knowledge Codex entry. This is the rarest and most consequential failure type.
+
+The classification narrows the correction domain before any human or SLM analysis begins.
+
+**Phase 2 — Purva-paksha (Prior Inference)**
+
+If an SLM is available, it fires Purva-paksha: given the failed delivery's fact pattern, what inference should the rule have produced? The SLM reasons from the SHASTRA premises (Strand 2's statute layer) and generates a prior inference with cited rules. This is not the final answer — it is the best available prior, subject to human validation.
+
+The Purva-paksha output is surfaced to the human reviewer alongside:
+- The original fact pattern
+- The rule that was applied (`source_rule_id`)
+- The answer that was generated
+- The SLM's inferred correct answer
+- The rules cited in the SLM inference
+
+**Phase 3 — Siddhanta (Established Correction)**
+
+The human reviewer validates or overrides the SLM's Purva-paksha. Their decision becomes Siddhanta — the established correction. The correction is applied to the Knowledge Codex (if rule correctness failure) or flagged for the service team (if rule application failure). If an SLM is integrated, the `(fact_pattern, rule_applied, siddhanta_answer)` triple enters the SLM's fine-tuning queue.
+
+The human's role in Phase 3 is not optional. It is the intentional ceiling: PRAMANA never auto-applies a correction to a SHASTRA rule without human validation. The 15% that remains human — moral judgment, domain expertise, contextual wisdom — is preserved at precisely this boundary.
+
+### 6.2 SLM Integration Architecture
+
+The SLM is integrated as a plugin at two points in the PRAMANA loop:
+
+**Point 1 — PRAMANA-3+ responses** — When all three strands are verified and the SLM is active, the SLM can extend the Knowledge Codex's VIVEKA layer with an additional inference. This inference is labeled `SLM_INFERRED` in the response, distinguishable from `CODEX_INDEXED` inferences. The PRAMANA marker becomes PRAMANA-3+.
+
+**Point 2 — RCA Phase 2** — As described above: Purva-paksha generation for failed deliveries.
+
+The SLM never writes to the Knowledge Codex directly. It never updates capability declarations. It never modifies build proof annotations. It reasons and proposes. Humans approve. This boundary is enforced at the protocol level, not at the application level.
+
+### 6.3 The Flywheel
+
+The full PRAMANA loop creates a self-improving flywheel:
+
+```
+Delivery → PHALA → rule reliability update
+    ↓ (if incorrect)
+RCA → failure classification → Purva-paksha
+    ↓
+Human Siddhanta → Knowledge Codex correction
+    ↓
+SLM fine-tuning → better Purva-paksha next cycle
+    ↓
+Improved PRAMANA-3+ responses → fewer incorrect deliveries → fewer RCA triggers
+```
+
+The flywheel is bounded: it cannot improve beyond the quality of human Siddhanta corrections. A domain expert who repeatedly provides incorrect corrections will degrade the loop. PRAMANA detects this (the `reliability_score` for corrected rules remains low) and surfaces it as a meta-failure requiring escalation to a higher authority. The protocol is self-auditing at every level.
+
+---
+
+## 7. Reference Implementation: ANKR
+
+### 7.1 System Overview
+
+PRAMANA is documented from its reference implementation in the ANKR universe — a portfolio of 200+ AI-native services spanning maritime operations, trade compliance, legal advisory, financial analysis, vessel management, and infrastructure. ANKR is Customer Zero: every architectural decision in PRAMANA was made under production constraints, not theoretical ones.
+
+**Scale at documentation time (2026-03-28):**
+- 200+ registered services
+- 5,336 domain rules across SHASTRA/YUKTI/VIVEKA layers
+- 174 services audited under CCA (Strand 3)
+- 32 service domains indexed in GRANTHX Knowledge Codex (Strand 2)
+- Trust bitmask system: 32-bit allocation across Universal Forja (bits 0-7), Maritime 8x (bits 8-15), Logistics (bits 16-23), AGI autonomy tier (bits 24-31)
+
+### 7.2 Strand Implementation
+
+**Strand 1 (Capability) — AnkrCodex**
+
+AnkrCodex crawls all `codex.json` declarations across the service universe. Each `codex.json` contains `can_answer` (READ surface slugs), `can_do` (WRITE surface action IDs), and the 32-bit `trust_mask`. The crawler produces a centralised capability index queryable via:
+
+```
+GET /api/codex/query?can_do=FTA_CHECK&mask=0x00010000
+```
+
+Response: all services with the `FTA_CHECK` capability bit set, ranked by `reliability_score` from PHALA history.
+
+**Strand 2 (Knowledge) — GRANTHX Knowledge Codex**
+
+GRANTHX stores 5,336 rules in a three-layer taxonomy: SHASTRA (statutes), YUKTI (modus operandi), VIVEKA (inference library). Each rule carries:
+- `rule_id` (e.g. `INF-LAY-001`)
+- `domain` (e.g. `maritime-voyage`)
+- `rule_type` (statute / meta-reasoning / inference)
+- `confidence` (0.0–1.0, for VIVEKA rules)
+- `phala_reliability` (updated by PHALA signal, initially null)
+
+The three-layer design follows Dharmakīrti's epistemological hierarchy: statutes are direct perception (pratyaksha) — what the law says; meta-reasoning is inference discipline (anumana) — how experts reason; and the VIVEKA inference library is pre-computed valid cognition — verified inferences from known premises.
+
+**Strand 3 (Proof) — CCA**
+
+The Capability Closure Audit sweeps all service source code for `@rule:{RULE-ID}` annotations. For each annotated decision point, it verifies:
+1. The `RULE-ID` exists in GRANTHX (Strand 2 present)
+2. The containing function is reachable from the service's declared capability (Strand 1 present)
+3. The service's `codex.json` references this capability (Strand 1 complete)
+
+CCA produces a `proof_config` block updated in each service's `codex.json`:
+
+```json
+"proof_config": {
+  "threshold_pct": 90.0,
+  "coverage_pct": 87.3,
+  "rules_seeded": 30,
+  "rules_annotated": 26,
+  "annotation_sweep_status": "complete"
+}
+```
+
+CCA Phase 0+1+2 is complete across 174 services as of the documentation date.
+
+### 7.3 PHALA Implementation
+
+PHALA signals are emitted by every service through the Forja SENSE endpoint with event type `PHALA_DELIVERY_OUTCOME`. A PHALA daemon subscribes to this event type and routes signals to the Knowledge Codex's rule update endpoint. The daemon also maintains a RCA trigger queue: any rule receiving an `incorrect` outcome is queued for RCA within 15 minutes.
+
+The PHALA daemon is stateless — it does not store delivery outcomes. The Knowledge Codex stores them. The daemon is a routing component in the dabbawallah sense: it ensures every outcome reaches its source rule, without itself holding any state.
+
+### 7.4 Authenticity Marker in Production
+
+Every ANKR API response envelope includes a `pramana` block:
+
+```json
+{
+  "data": { ... },
+  "pramana": {
+    "level": "PRAMANA-3",
+    "strand_capability": true,
+    "strand_knowledge": true,
+    "strand_proof": true,
+    "strand_slm": false,
+    "rule_id": "INF-LAY-001",
+    "service": "mari8x-voyage",
+    "reliability": 0.981,
+    "human_review_required": false
+  }
+}
+```
+
+Downstream agents parse this block before acting on `data`. A `human_review_required: true` flag stops automated action regardless of the data content.
+
+---
+
+## 8. Beyond ANKR — N-Strand Organizations and the Mesh
+
+### 8.1 Generalizing to N Strands
+
+PRAMANA defines three strands for the ANKR implementation because three failure modes are structurally distinct: capability misrepresentation, knowledge misapplication, and build proof gaps. Organizations with different architectures may have different failure modes and therefore different strand counts.
+
+A legal AI organization might add a fourth strand: **Jurisdiction** — verifying that the rule applied is valid in the jurisdiction of the request. A medical AI organization might add a fifth strand: **Clinical Validation** — verifying that the inference has been validated in a clinical study. The PRAMANA protocol is extensible: the authenticity marker system generalizes to N strands, with PRAMANA-N representing full authentication across all N strands.
+
+The invariant is the PHALA signal. Regardless of strand count, every delivery outcome must return to its source rule. The RCA loop operates on source rules, not strands. Strand addition changes the READ and ROUTE phases; it does not change the RECORD phase or the PHALA mechanism.
+
+### 8.2 The Dharmakīrti Mesh
+
+When multiple PRAMANA-compliant organizations share a protocol layer, a *Dharmakīrti Mesh* emerges: a network of self-verifying cognition nodes where capability discovery, knowledge queries, and outcome feedback are interoperable across organizational boundaries.
+
+The mesh operates on two principles drawn from Dharmakīrti's *Pramanavarttika*:
+
+**Principle 1 — Valid cognition is transferable.** A PRAMANA-3 response from Organization A is a valid input to Organization B's reasoning chain, provided B can verify the strand authenticity markers. The marker system is the inter-organization trust primitive.
+
+**Principle 2 — Inference chains are composable.** Organization B can extend Organization A's PRAMANA-3 response with its own strand verification (e.g., adding jurisdictional verification) and produce a composite authenticity marker. The composite is PRAMANA-N where N includes both organizations' strands.
+
+The mesh is not a central authority. There is no God's eye view, exactly as in the dabbawallah system. Each node verifies its own strands. The composite authenticity emerges from distributed local verification. A central authority would be a single point of failure; distributed local verification is the architecture of Six Sigma.
+
+### 8.3 Implementation Pathway for New Organizations
+
+A new organization implementing PRAMANA follows a four-step onboarding:
+
+1. **Declare capabilities** — create `codex.json` for each service. Populate `can_answer`, `can_do`, and `trust_mask`. Register in a capability registry (any AnkrCodex-compatible implementation).
+
+2. **Index knowledge** — seed domain rules into a Knowledge Codex following the SHASTRA/YUKTI/VIVEKA taxonomy. Minimum viable: SHASTRA rules only. YUKTI and VIVEKA add reasoning quality; they are not required for Strand 2 to be active.
+
+3. **Annotate code** — annotate decision points with `@rule:{RULE-ID}`. Run CCA sweep. Achieve `coverage_pct >= threshold_pct`. Strand 3 activates.
+
+4. **Wire PHALA** — implement the PHALA endpoint in every service. Subscribe a PHALA daemon. Route outcomes to Knowledge Codex. Strand feedback activates.
+
+Steps 1–3 can be completed incrementally by service. Step 4 activates the self-improvement loop. An organization with Step 1 only has PRAMANA-1 capability across its declared services — better than zero, explicitly marked as incomplete, with a clear path to PRAMANA-3.
+
+---
+
+## 9. Comparison with Existing Approaches
+
+### 9.1 Service Meshes (Istio, Linkerd)
+
+| Dimension | Service Mesh | PRAMANA |
+|-----------|-------------|---------|
+| What is verified | Network connectivity, mTLS, circuit state | Capability, knowledge, build proof, delivery outcome |
+| Feedback signal | Error rate, latency, retry count | Source rule reliability, RCA classification |
+| Human escalation trigger | SLA breach | PRAMANA-0 response, RCA Phase 3 |
+| Knowledge layer | None | SHASTRA/YUKTI/VIVEKA taxonomy |
+| SLM integration | None | PHALA → Purva-paksha → Siddhanta |
+
+Service meshes and PRAMANA are complementary. A service mesh provides the transport layer; PRAMANA provides the cognition layer. An organization running both has network reliability AND cognition authenticity — neither alone is sufficient.
+
+### 9.2 API Gateways (Kong, AWS API GW)
+
+API gateways operate on request/response envelopes at the HTTP layer. They verify authentication tokens, enforce rate limits, and route to registered services. They do not inspect the semantic content of requests or responses, do not verify that a service has the capability it claims, and do not feed delivery outcomes back to knowledge sources.
+
+PRAMANA's READ step is conceptually analogous to API gateway routing — both select a service for a request. The difference: API gateways route on path and method; PRAMANA routes on verified capability bits and knowledge strand status. A service that is registered with an API gateway but has zero knowledge indexed and zero proof coverage routes requests it cannot correctly answer. PRAMANA would assign it PRAMANA-0 and require human review for every response.
+
+### 9.3 Knowledge Graphs (Neo4j, Wikidata)
+
+Knowledge graphs model entities and relationships. They are excellent for structured domain knowledge representation and traversal. They do not model service capabilities, do not emit runtime signals, and do not bind knowledge to delivery outcomes.
+
+PRAMANA's Knowledge Codex (GRANTHX) is not a knowledge graph — it is a rule registry with delivery history. The distinction is important: a knowledge graph answers "what is the relationship between X and Y?" A PRAMANA Knowledge Codex answers "what rule governs X given Y, has that rule been proven correct in the service's code, and what is its delivery reliability over the last 30 days?" The second question is what a production AI system needs to answer; the first question is input to the second.
+
+### 9.4 RAG Pipelines
+
+RAG (Retrieval-Augmented Generation) pipelines retrieve contextually relevant documents for LLM generation. They address the knowledge staleness problem for LLMs by injecting fresh context at query time. They do not address capability verification (the LLM does not know if the service has the capability to act on the retrieved context), build proof (no annotation system), or delivery outcome feedback (the RAG system does not know whether the generated answer was correct).
+
+PRAMANA's Strand 2 (Knowledge Codex) shares the retrieval goal with RAG: get the right rule for the right fact pattern. PRAMANA adds the constraint that the retrieved rule must be cited in the response (enabling audit), must be proven in the service's code (Strand 3), and must have its delivery outcome returned to it (PHALA). A RAG pipeline integrated into a PRAMANA-compliant service would have its retrieval results tagged with rule IDs and its generation outcomes fed back to the source rules via PHALA. This is a valid and recommended integration pattern.
+
+---
+
+## 10. Conclusion
+
+PRAMANA is a self-verifying cognition protocol that closes the gap between AI service capability declarations, domain knowledge application, and delivery outcome correctness — a gap that existing protocols (service meshes, API gateways, knowledge graphs, RAG pipelines) do not address.
+
+The protocol's three contributions are:
+
+**First — the three-strand verification model.** Capability (what a service declares it can do), knowledge (what rules it applies), and proof (whether its implementation matches both) are distinct failure modes requiring distinct verification strands. Bundling them obscures failures; separating them localizes corrections.
+
+**Second — the PHALA signal.** Returning delivery outcomes to source rules — not service logs, not monitoring dashboards, not aggregate error rates — creates a rule-level reliability score that: improves routing in the READ step, triggers targeted RCA for specific rule failures, and feeds training signals to an SLM when integrated. PHALA is what transforms PRAMANA from an observability framework into a self-improving cognition loop.
+
+**Third — binary authenticity markers.** The PRAMANA-0 through PRAMANA-3+ taxonomy provides a human-readable, machine-parseable authenticity label that communicates which strands were verified for a specific response, without resorting to probability scores that obscure actionable distinctions. PRAMANA-0 means: a human must check this. PRAMANA-3 means: three independent verification strands confirm this answer. The difference matters to a ship captain, a compliance officer, and a bank underwriter in ways that "78% confidence" does not.
+
+PRAMANA is named after Dharmakīrti's epistemological framework not as ornament but as architecture: valid cognition is cognition that can demonstrate its sources. At 200+ services, 5,336 rules, and millions of daily interactions, the only sustainable standard for AI-generated advice is one where the source of every answer is traceable, the rule behind every answer is proven, and the outcome of every answer teaches the system what to do better next time. That is not a theoretical aspiration. It is what the ANKR reference implementation does today.
+
+The dabbawallah system achieved Six Sigma accuracy not by making any single worker perfect, but by making the *system* self-verifying at every handoff. PRAMANA applies this principle to AI-native service universes: not perfect services, but a protocol that makes every handoff verifiable, every failure localizable, and every correction permanent. The tiffin reaches the right desk. The food inside is what the sender intended.
+
+---
+
+## 11. References
+
+[CITATION-Dharmakirti600] Dharmakīrti (c. 600–660 CE). *Pramāṇavārttika* (प्रमाणवार्त्तिक — Commentary on Valid Cognition). Translated and annotated by Tillemans, T. (1999). *Dharmakīrti's Pramāṇavārttika: An Annotated Translation of the Fourth Chapter (Parārthānumāna)*. Verlag der Österreichischen Akademie der Wissenschaften, Vienna.
+
+[CITATION-Tillemans1999] Tillemans, T. (1999). *Scripture, Logic, Language: Essays on Dharmakīrti and His Tibetan Successors*. Wisdom Publications, Boston.
+
+[CITATION-Hayes1988] Hayes, R. (1988). *Dignāga on the Interpretation of Signs*. Kluwer Academic Publishers, Dordrecht.
+
+[CITATION-Thomke2012] Thomke, S., & Sinha, M. (2010). The Dabbawala System: On-Time Delivery, Every Time. *Harvard Business School Case 610-059*. Harvard Business School Publishing, Boston.
+
+[CITATION-Roncaglia2013] Roncaglia, L. (2013). Tiffin Wallahs and Tiffin Boxes: A Study of Flexibility in Logistics. *Journal of Transport Geography*, 28, 40–48.
+
+[CITATION-Brown2020] Brown, T., et al. (2020). Language Models are Few-Shot Learners. *Advances in Neural Information Processing Systems*, 33, 1877–1901.
+
+[CITATION-Lewis2020] Lewis, P., et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. *Advances in Neural Information Processing Systems*, 33, 9459–9474.
+
+[CITATION-Minsky1986] Minsky, M. (1986). *The Society of Mind*. Simon & Schuster, New York. (Background: distributed cognition as an architectural principle.)
+
+[CITATION-Burnstein2003] Burnstein, E. (2003). Six Sigma and the Art of Dabbawala Delivery. *MIT Sloan Management Review*, 44(2), 14–16.
+
+[CITATION-Istio2023] Istio Authors. (2023). *Istio Service Mesh Documentation v1.20*. Retrieved from https://istio.io/docs/
+
+[CITATION-Kong2023] Kong Inc. (2023). *Kong Gateway: Architecture Overview*. Retrieved from https://docs.konghq.com/
+
+[CITATION-Neo4j2023] Neo4j, Inc. (2023). *Neo4j Graph Database Documentation*. Retrieved from https://neo4j.com/docs/
+
+[CITATION-Sharma2026a] Sharma, A.K. (2026). ANKR Forja Protocol: STATE, TRUST, SENSE — An Open Protocol for AI-Native Service Self-Declaration. PowerPbox IT Solutions Pvt Ltd. Internal whitepaper, `/root/proposals/ANKR-FORJA-WHITEPAPER_2026-03-14.md`.
+
+[CITATION-Sharma2026b] Sharma, A.K. (2026). The Dharmakīrti Mesh: A Graph Algorithm for Service Universe Discovery. PowerPbox IT Solutions Pvt Ltd. Internal proposal, `/root/proposals/ANKR-DHARMAKIRTI-MESH-V1_2026-03-26.md`.
+
+[CITATION-Sharma2026c] Sharma, A.K. (2026). The Trust Bitmask: 32-bit Capability Encoding for AI-Native Service Universes. PowerPbox IT Solutions Pvt Ltd. Internal LOGICS document, `/root/proposals/ANKRCLAW-BITMASK-LOGICS_2026-03-22.md`.
+
+[CITATION-Sharma2026d] Sharma, A.K. (2026). Pramana to Praxis: Deploying Dharmakīrti's Epistemological Framework in Production AI Systems. PowerPbox IT Solutions Pvt Ltd. ArXiv preprint, Paper 1 in the ANKR series.
+
+---
+
+## Appendix A: PRAMANA Signal Specification (v1.0)
+
+### A.1 STATE Signal
+
+```
+Endpoint: GET /api/v2/forja/state[/:entityId]
+Returns:
+  service: string
+  port: number
+  can_answer: string[]          // Knowledge Codex slugs (READ surface)
+  can_do: string[]              // Action registry IDs (WRITE surface)
+  trust_mask: number            // 32-bit capability encoding
+  strand_capability: boolean    // Strand 1 active
+  strand_knowledge: boolean     // Strand 2 active (rules indexed in Knowledge Codex)
+  strand_proof: boolean         // Strand 3 active (CCA coverage >= threshold)
+  proof_coverage_pct: number    // From codex.json proof_config
+  forja_version: string
+```
+
+### A.2 TRUST Signal
+
+```
+Endpoint: GET /api/v2/forja/trust/:userId
+Returns:
+  user_id: string
+  role: string
+  effective_mask: number        // Intersection: service mask & role mask
+  can_do: string[]              // Actions permitted for this principal
+  expires_at: string            // ISO8601
+```
+
+### A.3 SENSE Signal
+
+```
+Endpoint: POST /api/v2/forja/sense/emit
+Payload:
+  event_type: string            // e.g. RULE_APPLIED, CONFIDENCE_LOW, HUMAN_ESCALATED
+  service: string
+  rule_id: string | null
+  payload: object               // event-specific data
+  timestamp: string
+```
+
+### A.4 PHALA Signal
+
+```
+Endpoint: POST /api/v2/forja/phala (Knowledge Codex PHALA receiver)
+Payload:
+  phala_type: "DELIVERY_OUTCOME"
+  source_rule_id: string        // Rule ID that generated the answer
+  service: string               // Service that applied the rule
+  request_id: string            // Traceable to SENSE event
+  outcome: "correct" | "incorrect" | "ambiguous"
+  outcome_detail: string        // Human-readable outcome description
+  delivered_at: string          // ISO8601
+  phala_version: "1.0"
+```
+
+### A.5 Authenticity Marker Schema
+
+```json
+{
+  "pramana": {
+    "level": "PRAMANA-0 | PRAMANA-1 | PRAMANA-2 | PRAMANA-3 | PRAMANA-3+",
+    "strand_capability": boolean,
+    "strand_knowledge": boolean,
+    "strand_proof": boolean,
+    "strand_slm": boolean,
+    "rule_id": string | null,
+    "service": string,
+    "reliability": number | null,
+    "human_review_required": boolean,
+    "missing_strands": string[]
+  }
+}
+```
+
+---
+
+## Appendix B: RCA Classification Decision Tree
+
+```
+PHALA outcome: incorrect
+  ↓
+Did the correct service receive the request?
+  NO → Routing failure
+       Correction: update trust_mask or AnkrCodex registration
+  YES ↓
+Did the service apply the cited rule correctly?
+  (Compare service output with rule's expected inference for given fact pattern)
+  NO → Rule application failure
+       Correction: update @rule-annotated code path
+  YES ↓
+Is the rule's conclusion correct for the given fact pattern?
+  NO → Rule correctness failure
+       Correction: update Knowledge Codex entry (human Siddhanta required)
+  AMBIGUOUS → SLM Purva-paksha → human Siddhanta
+```
+
+---
+
+*This paper documents a working system. PRAMANA is implemented in the ANKR universe (PowerPbox IT Solutions Pvt Ltd) and has been operational across 174+ audited services as of 2026-03-28. The protocol specification in Appendix A is the implementation specification, not a proposal.*
+
+*Capt. Anil Kumar Sharma*
+*PowerPbox IT Solutions Pvt Ltd*
+*DPIIT Registered Startup, Haryana, India*
+*capt.anil.sharma@powerpbox.org*
+*+91-7506926394*