pramana-protocol 1.0.0

package/PROTOCOL.md

@@ -0,0 +1,919 @@
+# PRAMANA/1.0
+
+## Open Protocol Specification for Authenticated AI Knowledge Delivery
+
+```
+Document:     PRAMANA/1.0
+Status:       OPEN DRAFT — Reference Implementation by ANKR
+Version:      1.0.0
+Date:         2026-03-28
+Author:       Capt. Anil Kumar Sharma
+              PowerPbox IT Solutions Pvt Ltd
+              capt.anil.sharma@powerpbox.org
+              +91-7506926394
+              DPIIT Registered Startup, Haryana, India
+```
+
+---
+
+## 1. Status of This Document
+
+This document describes an open protocol specification. Any system, organisation, or individual
+may implement the PRAMANA protocol. The protocol is not the exclusive property of any
+implementer. ANKR (PowerPbox IT Solutions Pvt Ltd) is the reference implementation author and
+maintains the canonical specification.
+
+The reference implementation is available at:
+- GitHub: https://github.com/rocketlang/forja-protocol
+- npm: ankr-forja (AnkrForja STATE/TRUST/SENSE/PHALA primitives)
+- npm: ankr-trust-constants (bitmask constants and strand type registry)
+
+This document establishes the priority date of 2026-03-28 for the PRAMANA/1.0 protocol design.
+Provisional patent applications covering PHALA signal routing, the PRAMANA Authenticity Marker
+System, SLM Self-Training via RCA Corrections, and Two-Wrong-Equals-Right Detection have been
+filed as of this date.
+
+Implementers are encouraged to contribute strand type registrations, extensions, and
+interoperability notes via the public repository.
+
+---
+
+## 2. Abstract
+
+PRAMANA/1.0 defines a protocol for AI knowledge delivery systems to verify, annotate, and
+continuously improve the authenticity of their outputs. The protocol introduces four signals
+(STATE, TRUST, SENSE, and the novel PHALA signal), a five-level Authenticity Marker system, and
+a recursive mini-loop operating at every stage of the delivery pipeline. PRAMANA addresses the
+structural inability of current AI systems to distinguish between what they know and what they
+merely compute — and to route that distinction to the user and back to the source rule in a
+machine-readable, actionable form.
+
+The word Pramana (Sanskrit: प्रमाण) means valid cognition — knowledge that can be authenticated
+as arising from a reliable source. In the epistemology of Dharmakīrti (Nalanda, c. 600–660 CE),
+Pramana is not merely belief but verifiable knowing. This protocol applies that standard to AI
+system output.
+
+---
+
+## 3. Introduction
+
+AI systems deployed in professional and regulatory domains produce outputs that users act upon.
+The quality of those outputs depends on three structurally independent factors:
+
+1. Whether the system is actually capable of answering the query type (capability).
+2. Whether the knowledge the system draws on is authoritative (knowledge authenticity).
+3. Whether the system has been independently verified to behave as specified (proof of
+   conformance).
+
+These three factors are not captured by a scalar confidence score. A system can be 98% confident
+in an answer that is produced by the wrong capability, drawn from an unverified knowledge source,
+and generated by a system that has never been independently audited. Conversely, a system may
+produce a correct answer at low statistical confidence because it is operating at the edge of its
+knowledge — but that answer may be fully authenticated because all three strands are present.
+
+PRAMANA/1.0 defines a minimal, extensible protocol that enables any AI knowledge system to:
+
+(a) Check the binary availability of independent validation strands at query time.
+(b) Annotate every output with a structured Authenticity Level.
+(c) Route delivery outcomes back to the specific knowledge rules that generated them.
+(d) Trigger root cause analysis at rule granularity, not service granularity.
+(e) Optionally connect a Small Language Model plugin to capture human-validated corrections as
+    fine-tuning data within the normal RCA workflow.
+
+The protocol is designed to be implemented incrementally. A minimum viable implementation
+requires one strand and basic PHALA routing. A full implementation provides all four signals,
+all five authenticity levels, and an SLM plugin interface.
+
+---
+
+## 4. Terminology
+
+The following terms are used throughout this specification. Where a term has a corresponding
+Sanskrit root, that root is noted for reference.
+
+**Strand**
+An independent, structurally distinct category of validation that can be applied to an AI system
+output. Each strand is checked at query time as a binary (present/absent). Strands are not
+additive sub-components of a single confidence score — they are orthogonal dimensions of
+authenticity. The minimum required strands for a PRAMANA/1.0 implementation are Capability and
+Knowledge. A third strand, Proof, is defined in this specification. Additional strands may be
+registered (see Section 15).
+
+**Signal**
+A structured data event emitted by a PRAMANA-compatible AI system at a defined point in the
+query lifecycle. This specification defines four signals: STATE, TRUST, SENSE, and PHALA.
+
+**Authenticity Level**
+A discrete classification from 0 to 3+ assigned to an AI system output, representing the count
+and combination of validation strands available at the time the output was generated. Authenticity
+Level is not a confidence score and must not be presented as one.
+
+**PHALA**
+(Sanskrit: फल — phala — outcome, fruit, result.) The fourth signal in the PRAMANA protocol. A
+PHALA signal carries a delivery outcome (success or failure) from the point of delivery back to
+the specific knowledge rule or rules that generated the AI response. PHALA is the mechanism by
+which the protocol closes the feedback loop at rule granularity. See Section 7.4.
+
+**RCA**
+Root Cause Analysis. In the context of this protocol, RCA is triggered at the rule level when
+a PHALA signal aggregate for a specific Rule ID crosses a failure threshold. RCA is a
+human-in-the-loop process. It cannot be fully automated (see Section 10.2).
+
+**Purva-paksha**
+(Sanskrit: पूर्वपक्ष — the prior position; the opposing view presented before the conclusion.)
+In the context of this protocol, the Purva-paksha is a hypothesis generated by an SLM Plugin
+during the RCA process — the SLM's inference about the cause of a failure and a proposed
+correction. The Purva-paksha is presented to a human expert for validation. It is an input to
+human judgment, not a replacement for it.
+
+**Siddhanta**
+(Sanskrit: सिद्धान्त — established conclusion; that which has been proven.) In the context of
+this protocol, the Siddhanta is the human expert's validated conclusion at the close of an RCA
+work item. The Siddhanta becomes the labeled training output in the SLM fine-tuning pair
+(see Section 10.3).
+
+**SLM Plugin**
+A Small Language Model optionally connected to the PRAMANA RCA loop. The SLM Plugin is scoped
+to one or more Rule IDs and fires Purva-paksha inferences during RCA. It receives fine-tuning
+updates from Siddhanta-labeled training pairs. The SLM Plugin interface is defined in
+Section 10.3.
+
+**Rule ID**
+A unique identifier assigned to each knowledge rule, statute, inference, or knowledge node in a
+PRAMANA-compatible system's Rule Registry. Rule IDs are the primary routing key for PHALA
+signals. Format is implementation-defined; the reference implementation uses the pattern
+`{DOMAIN}-{TYPE}-{NUM}` (e.g., `MAR-YK-007`, `INF-LL-001`).
+
+**Query Registry**
+A registry maintained by a PRAMANA-compatible system that maps query types to expected minimum
+Authenticity Levels and other per-query metadata.
+
+**Rule Registry**
+A registry maintained by a PRAMANA-compatible system that maps Rule IDs to knowledge content,
+PHALA aggregate counters, and SLM Plugin assignments.
+
+**Rule-Level Outcome Registry**
+A persistent store keyed by Rule ID, receiving PHALA signals and maintaining per-rule delivery
+outcome aggregates. Logically distinct from the service log or model log.
+
+---
+
+## 5. Protocol Overview
+
+A PRAMANA/1.0 compatible system implements the following lifecycle per query:
+
+```
+QUERY RECEIVED
+     |
+     v
+[STATE check]       — Is this system operational? What are its declared capabilities?
+     |
+     v
+[TRUST check]       — Is this user/role authorised for this query type?
+     |
+     v
+[Strand checks]     — For each defined strand: is it available? (binary per strand)
+     |
+     v
+[Authenticity Level assigned] — Based on strand count and identity
+     |
+     v
+[Rule IDs recorded] — Which rules contribute to this response?
+     |
+     v
+[OUTPUT DELIVERED]  — With PRAMANA annotation attached
+     |
+     v
+[SENSE emitted]     — System-level event (delivery attempted)
+     |
+     v
+[Outcome received]  — Success/failure signal from user or downstream system
+     |
+     v
+[PHALA generated]   — Routed to Rule-Level Outcome Registry per Rule ID
+     |
+     v
+[PHALA aggregate]   — Per Rule ID: counters updated, threshold check
+     |
+     v
+[RCA trigger?]      — If threshold crossed: open RCA work item
+     |
+     v
+[RCA loop]          — Human review, optional SLM Purva-paksha, Siddhanta capture
+     |
+     v
+[Training pair]     — Appended to SLM fine-tuning queue (if SLM Plugin present)
+```
+
+The recursive mini-loop READ → ROUTE → RECORD operates at every stage. Every check reads state,
+routes the query or signal appropriately, and records the outcome for the next stage.
+
+---
+
+## 6. The Three Strands
+
+### 6.1 Strand 1 — Capability
+
+**Strand Type ID:** `capability`
+
+**Definition:** Binary check — is the responding service or agent independently confirmed as
+capable of answering this query type via a centralised capability registry?
+
+**How to check:** Query a capability registry (AnkrCodex-compatible or equivalent) for the
+responding service's declared `can_answer` list. If the query type slug is present in the list,
+the strand is available.
+
+**AnkrCodex compatibility:** A service implementing the AnkrForja STATE endpoint
+(`GET /api/v2/forja/state`) and declaring `can_answer` in its `codex.json` is Strand 1 capable
+by default.
+
+**Absence implication:** The system has answered a query type that it has not declared as within
+its capability, or the capability registry is unavailable. The Authenticity Level cannot exceed
+PRAMANA-1 if Strand 1 is absent.
+
+### 6.2 Strand 2 — Knowledge
+
+**Strand Type ID:** `knowledge`
+
+**Definition:** Binary check — is the knowledge source used to generate the response
+independently confirmed as authoritative for the query domain, via a knowledge indexing system?
+
+**How to check:** Query a knowledge codex (GRANTHX-compatible or equivalent) for the Rule IDs
+or knowledge nodes cited in the response. If those IDs exist in the indexed codex and are
+classified as authoritative for the query domain, the strand is available.
+
+**GRANTHX compatibility:** A service whose LOGICS documents have been indexed in GRANTHX
+(or any compatible knowledge codex implementing the `.ib` or equivalent interchange format)
+is Strand 2 capable for the indexed rules.
+
+**Absence implication:** The system has answered using knowledge that has not been independently
+indexed or verified as authoritative. The Authenticity Level cannot exceed PRAMANA-2 if
+Strand 2 is absent.
+
+### 6.3 Strand 3 — Proof
+
+**Strand Type ID:** `proof`
+
+**Definition:** Binary check — has the responding service been independently verified to behave
+in accordance with its declared specification, via a conformance verification system?
+
+**How to check:** Query the service's PROOF endpoint (`GET /api/v2/forja/proof` in the reference
+implementation) or a centralised conformance registry. If the service's proof coverage meets the
+minimum threshold (default: 90% annotation coverage per the reference implementation), the
+strand is available.
+
+**CCA compatibility:** A service that has completed a Capability Closure Audit (CCA) and
+maintains `coverage_pct >= 90.0` in its `codex.json` `proof_config` block is Strand 3 capable.
+
+**Absence implication:** The service has not been independently verified to behave as specified.
+The Authenticity Level is PRAMANA-2 if Strands 1 and 2 are present but Strand 3 is absent.
+
+### 6.4 Partial Strand Operation
+
+A PRAMANA/1.0 implementation MUST NOT refuse to answer a query solely because one or more
+strands are unavailable. The protocol does not gate delivery on authentication — it annotates
+delivery with its authentication state. Refusing to answer is a policy decision by the
+implementing system and is outside the scope of this protocol.
+
+The minimum viable implementation requires one strand. A system with zero strands available
+assigns PRAMANA-0 and MUST attach the mandatory human review flag.
+
+### 6.5 Extended Strands
+
+Implementers may define additional strands beyond the three defined in this specification. Each
+extended strand MUST be registered with a unique Strand Type ID (see Section 15). Extended
+strands contribute to the Authenticity Level calculation as follows:
+
+- If all defined strands (including extended) are present: PRAMANA-3 (or PRAMANA-3+ if SLM
+  Plugin is active).
+- If any defined strand is absent: the level is determined by the count of present strands as
+  defined in Section 8.
+
+Extended strands MUST NOT change the Authenticity Level taxonomy. They extend the definition of
+"all strands present" but do not add new levels.
+
+---
+
+## 7. The Four Signals
+
+### 7.1 STATE
+
+**Method:** GET
+**Path:** `/api/v2/pramana/state[/:entityId]`
+
+The STATE signal declares what the system knows and is capable of. Any external system, agent,
+or capability registry may query STATE to discover the capabilities of this system without reading
+its source code or documentation.
+
+**Minimum required fields in STATE response:**
+
+```json
+{
+  "service": "string",
+  "version": "string",
+  "status": "online | degraded | offline",
+  "can_answer": ["query-slug-1", "query-slug-2"],
+  "can_do": ["ACTION_ONE", "ACTION_TWO"],
+  "strands_supported": ["capability", "knowledge", "proof"],
+  "pramana_version": "1.0"
+}
+```
+
+**Notes:**
+- `can_answer` is the READ surface. Each slug corresponds to a query type in the Query Registry.
+- `can_do` is the WRITE surface. Each item corresponds to an action the system can execute.
+- `strands_supported` lists the strands this system checks at query time.
+- STATE is a public endpoint. It does not require authentication.
+
+### 7.2 TRUST
+
+**Method:** GET
+**Path:** `/api/v2/pramana/trust/:userId`
+
+The TRUST signal declares what a specific user, role, or agent is authorised to do in this
+system. TRUST replaces custom RBAC middleware.
+
+**Minimum required fields in TRUST response:**
+
+```json
+{
+  "user_id": "string",
+  "role": "string",
+  "trust_mask": 0,
+  "can_query": ["query-slug-1"],
+  "can_execute": ["ACTION_ONE"],
+  "authenticity_level_floor": 1
+}
+```
+
+**Notes:**
+- `trust_mask` is a 32-bit integer encoding permissions as a bitmask. See the ankr-trust-constants
+  package for the canonical bit allocation.
+- `authenticity_level_floor` is the minimum Authenticity Level this user is permitted to receive.
+  If a query would produce an output below this floor, the system returns PRAMANA-0 with
+  disclosure rather than delivering the output. Default: 0 (no floor — deliver all outputs with
+  appropriate annotation).
+
+### 7.3 SENSE
+
+**Method:** POST
+**Path:** `/api/v2/pramana/sense/emit`
+
+The SENSE signal is a system-level event emitted at defined points in the query lifecycle. SENSE
+replaces custom notification pipelines. Subscribers receive SENSE events and may react without
+polling.
+
+**Minimum required fields in SENSE payload:**
+
+```json
+{
+  "event_type": "string",
+  "service": "string",
+  "timestamp": "ISO-8601",
+  "payload": {}
+}
+```
+
+**Standard SENSE event types defined by this specification:**
+
+| Event Type | When emitted |
+|---|---|
+| `query.received` | When a query is received by the system |
+| `query.answered` | When an output is delivered, with Authenticity Level |
+| `phala.generated` | When a PHALA signal is generated for a delivery outcome |
+| `rca.triggered` | When an RCA work item is opened |
+| `rca.closed` | When an RCA work item is closed with a Siddhanta |
+| `slm.training_pair_captured` | When a Siddhanta is captured as a training pair |
+| `slm.finetuning_triggered` | When a fine-tuning run is initiated |
+
+### 7.4 PHALA
+
+**Method:** POST
+**Path:** `/api/v2/pramana/phala`
+
+PHALA is the novel fourth signal. It carries a delivery outcome from the point of delivery back
+to the specific knowledge rules that generated the AI response. PHALA is the mechanism by which
+the protocol closes the feedback loop at rule granularity.
+
+#### 7.4.1 PHALA Payload Schema
+
+```json
+{
+  "signal_type": "phala",
+  "rule_id": "MAR-YK-007",
+  "applied_by": "mari8x-legal",
+  "query_context": "charter party clause, English law",
+  "outcome": "failure",
+  "strands_available": ["capability", "knowledge"],
+  "strand_missing": ["proof"],
+  "authenticity_level": "PRAMANA-2",
+  "rca_triggered": true,
+  "timestamp": "2026-03-28T14:23:00Z"
+}
+```
+
+**Field definitions:**
+
+| Field | Type | Required | Description |
+|---|---|---|---|
+| `signal_type` | string | MUST | Always `"phala"` |
+| `rule_id` | string | MUST | The Rule ID of the rule that generated the response. If multiple rules contributed, emit one PHALA per rule or use `rule_ids` (array variant). |
+| `rule_ids` | string[] | MAY | Array of Rule IDs when multiple rules contributed to a single response. |
+| `applied_by` | string | MUST | The service or agent that applied the rule. |
+| `query_context` | string | SHOULD | Human-readable description of the query context for RCA readability. |
+| `outcome` | enum | MUST | One of: `"success"`, `"failure"`, `"partial"`, `"indeterminate"` |
+| `strands_available` | string[] | MUST | Strand Type IDs that were available at query time. |
+| `strand_missing` | string[] | SHOULD | Strand Type IDs that were absent. SHOULD be present when `outcome` is `"failure"` or `"partial"`. |
+| `authenticity_level` | string | MUST | The Authenticity Level assigned at query time. |
+| `rca_triggered` | boolean | MUST | Whether this PHALA signal has triggered an RCA work item. |
+| `two_wrong_flag` | boolean | MAY | Present and `true` when a Two-Wrong-Equals-Right condition is detected for this output. |
+| `timestamp` | string | MUST | ISO-8601 timestamp of the delivery outcome event. |
+| `session_id` | string | MAY | Opaque session identifier for correlating multiple PHALA signals from a single user session. |
+| `batch_id` | string | MAY | Opaque batch identifier when PHALA signals have been batched (see Section 7.4.3). |
+
+#### 7.4.2 PHALA Routing
+
+PHALA MUST be routed to the Rule-Level Outcome Registry keyed by `rule_id`, not to the
+responding service's log and not to a centralised system log.
+
+The Rule-Level Outcome Registry is a persistent store. The implementing system is responsible
+for its durability. Loss of PHALA signals silently degrades the quality of the RCA trigger
+mechanism.
+
+Upon receipt of a PHALA signal, the Rule-Level Outcome Registry MUST:
+
+1. Increment the total PHALA count for the Rule ID.
+2. Increment the outcome-specific counter (success/failure/partial/indeterminate).
+3. Update the consecutive-failure counter: increment on `"failure"`, reset on any other outcome.
+4. Recompute the running confidence score as: `success_count / total_count`.
+5. Check whether the consecutive-failure counter exceeds the RCA trigger threshold.
+
+The RCA trigger threshold is configurable. The default in the reference implementation is 3
+consecutive failures.
+
+Implementing systems MAY maintain PHALA history as an append-only log per Rule ID, enabling
+time-series analysis of rule confidence over time.
+
+#### 7.4.3 PHALA Aggregation
+
+When multiple PHALA signals for the same Rule ID arrive within a configurable time window
+(default: 24 hours), the implementing system MAY batch them into an aggregate PHALA signal
+before checking the RCA trigger threshold.
+
+The purpose of batching is to suppress RCA triggers from isolated incidents (single users, edge
+cases, transient connectivity issues) while preserving the signal from systematic rule failures
+that affect multiple users over time.
+
+Batch behaviour is optional. A system that emits one PHALA per delivery outcome without batching
+is conformant. Batching is a quality-of-life optimisation, not a correctness requirement.
+
+When batching is active, the `batch_id` field in the PHALA payload MUST be populated with an
+opaque identifier shared by all signals in the batch. This allows RCA work items to reference
+the batch rather than individual signals.
+
+---
+
+## 8. Authenticity Markers
+
+Every AI system output in a PRAMANA/1.0 implementation MUST carry an Authenticity Level as a
+structured annotation. The annotation MUST be machine-readable. The annotation SHOULD also be
+human-readable in the user-facing rendering.
+
+A missing Authenticity Level MUST be treated as PRAMANA-0 by any consuming system.
+
+### 8.1 PRAMANA-0 — UNVERIFIED
+
+**Condition:** No strands are available at query time.
+
+**Mandatory annotation content:**
+- Level identifier: `"PRAMANA-0"`
+- Human-readable disclosure: This output has not been validated through any independent
+  verification process. Do not act on this output without independent expert review.
+- `human_review_required: true`
+
+**Display guidance:** Implement a visually distinct flag (e.g., a warning colour) in any
+user-facing rendering. The output may be displayed, but the human review flag must be prominent.
+
+### 8.2 PRAMANA-1 — SINGLE SOURCE
+
+**Condition:** Exactly one strand is available.
+
+**Mandatory annotation content:**
+- Level identifier: `"PRAMANA-1"`
+- `strand_present`: the Strand Type ID of the available strand.
+- Human-readable disclosure stating which strand is present.
+- Human-readable explanation of why the system answered despite the absence of the other strands.
+  Example: "This system's capability to answer this query type has been confirmed (Strand 1 —
+  Capability), but the knowledge source used has not been independently indexed (Strand 2 —
+  Knowledge absent), and this system has not been independently verified to behave as specified
+  (Strand 3 — Proof absent). Use this output for reference only."
+
+### 8.3 PRAMANA-2 — PARTIAL AUTHENTIC
+
+**Condition:** Exactly two strands are available.
+
+**Mandatory annotation content:**
+- Level identifier: `"PRAMANA-2"`
+- `strands_present`: array of Strand Type IDs of available strands.
+- `strand_missing`: Strand Type ID of the absent strand.
+- Human-readable disclosure naming the absent strand and its implication.
+  Example: "This output is produced by a system confirmed as capable (Strand 1) using verified
+  knowledge (Strand 2), but has not been independently verified to behave as specified
+  (Strand 3 — Proof absent). Suitable for professional use with awareness of this gap."
+
+### 8.4 PRAMANA-3 — AUTHENTIC
+
+**Condition:** All defined strands are available. No SLM Plugin active.
+
+**Mandatory annotation content:**
+- Level identifier: `"PRAMANA-3"`
+- `strands_present`: array of all Strand Type IDs.
+- Human-readable confirmation.
+
+No mandatory disclosure is required at PRAMANA-3 beyond the level identifier. Implementing
+systems MAY include additional strand details for auditability.
+
+### 8.5 PRAMANA-3+ — AUTHENTICATED AND INFERRED
+
+**Condition:** All defined strands are available AND an SLM Plugin has contributed domain
+inference to the response.
+
+**Mandatory annotation content:**
+- Level identifier: `"PRAMANA-3+"`
+- `strands_present`: array of all Strand Type IDs.
+- `slm_plugin_id`: identifier of the SLM Plugin that contributed to the response.
+- `slm_rules_applied`: array of Rule IDs for which the SLM Plugin fired inference.
+- Human-readable note that SLM inference was applied and the Rule IDs involved.
+
+PRAMANA-3+ is not a higher-confidence level than PRAMANA-3 — it is an informational variant.
+The SLM Plugin's presence indicates that the output incorporates domain inference beyond the
+base rules, which may increase specificity but also introduces SLM uncertainty. The annotation
+does not claim that SLM inference improves accuracy.
+
+---
+
+## 9. The Recursive Mini-Loop
+
+The protocol is structured around a recursive mini-loop that operates at every stage of the
+delivery pipeline:
+
+```
+READ   — check state before acting
+ROUTE  — send to the correct destination (strand check, rule lookup, PHALA routing)
+RECORD — log the outcome for the next stage
+```
+
+This loop is not a metaphor. Every implementing system MUST be able to answer:
+
+- At query time: READ (what is the STATE?), ROUTE (which strands are available?), RECORD (assign
+  Authenticity Level, record Rule IDs).
+- At delivery: READ (what Authenticity Level was assigned?), ROUTE (deliver with annotation),
+  RECORD (emit SENSE, await outcome signal).
+- At outcome: READ (what Rule IDs contributed?), ROUTE (PHALA to Rule-Level Outcome Registry),
+  RECORD (update counters, check RCA threshold).
+- At RCA: READ (what does the Rule-Level Outcome Registry show?), ROUTE (to human reviewer,
+  optional SLM Plugin), RECORD (Siddhanta, training pair).
+
+A system that skips any stage of the mini-loop has broken the feedback chain. PHALA signals
+that never reach the Rule-Level Outcome Registry make the RCA trigger inoperable. Authenticity
+Levels that are not recorded against the query make PHALA aggregation incomplete.
+
+---
+
+## 10. The RCA Loop
+
+### 10.1 Failure Classification
+
+When an RCA work item is opened for a Rule ID, the human reviewer MUST classify the failure into
+one of three categories:
+
+**Category A — Routing Failure:** The query was routed to the wrong service or the wrong rule.
+The rule itself is correct. Corrective action: fix the routing logic or query intent resolution.
+
+**Category B — Application Failure:** The rule was applied to the wrong context or with incorrect
+parameters. The rule itself is correct. Corrective action: fix the rule application logic or the
+context extraction.
+
+**Category C — Rule Failure:** The rule itself is incorrect, outdated, incomplete, or ambiguous.
+Corrective action: update, replace, or clarify the rule in the Rule Registry.
+
+The failure category MUST be recorded in the RCA work item. It is the primary driver of
+corrective action and of the SLM training signal (see Section 10.3).
+
+Implementers MAY define sub-categories within each category. The three top-level categories are
+mandatory and MUST NOT be collapsed.
+
+### 10.2 Human in Loop
+
+The RCA loop requires human judgment at the classification and Siddhanta stages. This is not
+optional and cannot be automated.
+
+The reason is structural: the PRAMANA protocol exists because AI systems cannot reliably
+distinguish between what they know and what they merely compute. Delegating RCA classification
+to the same class of system that produced the failure is circular. The human reviewer is the
+only party in the loop who can make the epistemological determination that the rule is wrong, or
+that the routing was wrong, or that the application was wrong — and who can bear responsibility
+for that determination.
+
+Implementing systems MUST NOT design RCA workflows that bypass human review for any failure
+category. Automated pre-classification (e.g., SLM Purva-paksha) is permitted as an input to
+human judgment but MUST NOT replace it.
+
+### 10.3 SLM Plugin Interface
+
+The SLM Plugin is an optional component of the PRAMANA RCA loop. When an RCA work item is
+opened, the implementing system MAY invoke the SLM Plugin interface.
+
+**SLM Plugin Interface — Request:**
+
+```json
+{
+  "plugin_interface": "pramana/slm-plugin/1.0",
+  "rule_id": "MAR-YK-007",
+  "rule_content": "string — full text of the rule",
+  "original_query": "string",
+  "original_response": "string",
+  "phala_signals": [
+    {
+      "outcome": "failure",
+      "query_context": "string",
+      "timestamp": "ISO-8601"
+    }
+  ],
+  "failure_category_hint": "A | B | C | unknown"
+}
+```
+
+**SLM Plugin Interface — Purva-paksha Response:**
+
+```json
+{
+  "plugin_interface": "pramana/slm-plugin/1.0",
+  "rule_id": "MAR-YK-007",
+  "purva_paksha": {
+    "failure_category": "C",
+    "hypothesis": "string — SLM's inference about the cause of failure",
+    "proposed_correction": "string — SLM's proposed corrected rule text or logic",
+    "confidence": 0.0
+  }
+}
+```
+
+The `confidence` field in the Purva-paksha is the SLM's own confidence in its hypothesis. It
+is presented to the human reviewer as context. It does not gate the human review or constrain
+the Siddhanta.
+
+### 10.4 Training Signal Capture
+
+When the human reviewer closes the RCA work item with a Siddhanta, the implementing system MUST
+automatically construct a training pair:
+
+**Training Pair Schema:**
+
+```json
+{
+  "training_pair_id": "uuid",
+  "rule_id": "MAR-YK-007",
+  "input": {
+    "query": "string",
+    "original_response": "string",
+    "phala_signals": [],
+    "purva_paksha": {}
+  },
+  "label": {
+    "failure_category": "C",
+    "siddhanta": "string — human-validated correction",
+    "corrected_rule": "string — updated rule text if applicable"
+  },
+  "captured_by": "string — reviewer identifier",
+  "captured_at": "ISO-8601"
+}
+```
+
+The `purva_paksha` field in the input is present only if an SLM Plugin was active. Its inclusion
+allows the fine-tuning run to learn from cases where the SLM's hypothesis was validated by the
+human (reinforcement) as well as cases where it was corrected (correction signal).
+
+Training pairs are appended to the SLM's fine-tuning queue. The implementing system MUST
+preserve training pairs durably. Loss of training pairs degrades the self-improvement loop.
+
+Fine-tuning triggering, batch sizing, and model versioning are implementation-defined. The
+reference implementation uses a batch size of 50 pairs and triggers fine-tuning automatically.
+
+---
+
+## 11. Minimum Viable Implementation
+
+A system claiming PRAMANA/1.0 compatibility MUST implement ALL of the following:
+
+1. **STATE endpoint** at a declared path returning at minimum: `service`, `version`, `status`,
+   `can_answer`, `strands_supported`, `pramana_version`.
+
+2. **TRUST endpoint** at a declared path returning at minimum: `user_id`, `role`, `trust_mask`.
+
+3. **At least one Strand** checked at query time, with binary result.
+
+4. **Authenticity Level assignment** for every output, based on strand availability.
+
+5. **PRAMANA annotation** attached to every output, machine-readable, including
+   `authenticity_level` and mandatory disclosures per Section 8.
+
+6. **Rule ID recording** — for every query, one or more Rule IDs contributing to the response
+   MUST be recorded and associated with the output.
+
+7. **PHALA signal generation** on delivery outcome, routed to a Rule-Level Outcome Registry
+   keyed by Rule ID.
+
+8. **Rule-Level Outcome Registry** maintaining per-Rule-ID counters (success, failure, total,
+   consecutive-failure).
+
+9. **RCA trigger** when consecutive-failure counter exceeds threshold.
+
+10. **Human-reviewable RCA work item** with failure classification.
+
+A system implementing fewer than all ten requirements is not PRAMANA/1.0 compatible. It MAY
+describe itself as a partial implementation and SHOULD specify which requirements it satisfies.
+
+---
+
+## 12. Full Implementation
+
+A full PRAMANA/1.0 implementation additionally provides:
+
+1. **All three strands** (Capability, Knowledge, Proof) checked at query time.
+2. **SENSE endpoint** with standard event types as defined in Section 7.3.
+3. **PHALA batching** (Section 7.4.3).
+4. **Two-Wrong-Equals-Right detection** (per provisional patent claim 4 in the PHALA Signal
+   patent application): `two_wrong_flag` populated in PHALA when detected.
+5. **SLM Plugin interface** (Section 10.3), including Purva-paksha/Siddhanta cycle.
+6. **Training pair capture and fine-tuning queue** (Section 10.4).
+7. **PRAMANA-3+** annotation support.
+8. **Query Registry** with per-query-type minimum expected Authenticity Level.
+9. **Session-level PHALA correlation** via `session_id`.
+10. **SENSE subscriptions** — downstream systems can subscribe to SENSE events without polling.
+
+The reference implementation (ANKR) provides all ten full implementation components. See
+Section 16 for reference implementation details.
+
+---
+
+## 13. Interoperability
+
+When two PRAMANA-compatible organisations exchange AI knowledge queries across a network
+boundary, the following rules apply:
+
+**13.1 Strand portability.** Strands checked by the sending organisation are NOT automatically
+inherited by the receiving organisation. Each organisation checks its own strands at its own
+query boundary. An output that arrives at PRAMANA-3 from Organisation A may be PRAMANA-1 at
+Organisation B if B has only one strand defined for its system.
+
+**13.2 PHALA forwarding.** An organisation that proxies a query to another PRAMANA-compatible
+system SHOULD forward PHALA signals received from the proxied system to its own Rule-Level
+Outcome Registry, translated to its own Rule ID namespace where applicable. If translation is
+not possible, PHALA signals SHOULD be logged for manual review.
+
+**13.3 Authenticity Level propagation.** When an output from Organisation A is incorporated
+into a composite output by Organisation B, Organisation B MUST annotate the composite output
+with the minimum Authenticity Level across all component outputs. Minimum propagation is
+mandatory. Averaging Authenticity Levels is prohibited.
+
+**13.4 Strand Type Registry.** Organisations wishing to define shared strands that can be
+mutually recognised SHOULD register their Strand Type IDs in the PRAMANA Strand Type Registry
+(see Section 15). Unregistered strand types may be used internally but MUST be prefixed with
+`x-` to indicate non-standard status.
+
+**13.5 STATE discovery.** A PRAMANA-compatible system MUST expose its STATE endpoint at a
+publicly resolvable URL for interoperability with external capability registries.
+
+---
+
+## 14. Security Considerations
+
+**14.1 Authenticity Level forgery.** An adversarial system could claim PRAMANA-3 for outputs
+generated without any strand verification. Consuming systems SHOULD verify Authenticity Level
+claims by querying the producing system's STATE endpoint and cross-checking declared
+`strands_supported` against the claimed level. Claims inconsistent with declared strand support
+MUST be downgraded to PRAMANA-0 by the consuming system.
+
+**14.2 PHALA signal injection.** A malicious actor could inject false PHALA signals to trigger
+spurious RCA events for a Rule ID, degrading the quality of the feedback loop or forcing
+unnecessary fine-tuning. Implementing systems MUST authenticate PHALA signal sources. Only
+delivery systems and authorised downstream systems SHOULD be permitted to emit PHALA signals for
+a given Rule ID.
+
+**14.3 Rule Registry integrity.** Rule IDs are the primary routing key for PHALA signals and the
+primary label in SLM training pairs. Corruption of the Rule Registry — including unauthorised
+addition, modification, or deletion of rules — directly corrupts the feedback loop and the SLM
+training signal. Rule Registries MUST be access-controlled and append-only for modifications
+(updates must be versioned, not destructive).
+
+**14.4 SLM Plugin isolation.** The SLM Plugin receives query contexts and full rule text. These
+may contain sensitive domain data. Implementing systems MUST apply the same access controls to
+the SLM Plugin interface as to the query processing pipeline. SLM Plugins MUST NOT be permitted
+to modify Rule Registry entries directly — corrections flow via the Siddhanta capture path, not
+direct write.
+
+**14.5 Human reviewer authentication.** RCA work items generate training data. The identity of
+the human reviewer who validates a Siddhanta MUST be recorded in the training pair
+(`captured_by` field). Implementing systems MUST authenticate human reviewers before they can
+close RCA work items. Unauthenticated Siddhanta submissions MUST be rejected.
+
+**14.6 Authenticity Level floor enforcement.** The `authenticity_level_floor` field in the TRUST
+response (Section 7.2) is a policy control that prevents low-authenticity outputs from reaching
+users who require higher assurance. Implementing systems MUST enforce this floor server-side,
+not rely on client-side enforcement.
+
+---
+
+## 15. IANA / Registry Considerations
+
+This specification defines a Strand Type Registry for PRAMANA/1.0. The registry maps Strand Type
+IDs to definitions.
+
+**Initial registered strand types:**
+
+| Strand Type ID | Name | Defined by |
+|---|---|---|
+| `capability` | Capability Strand | PRAMANA/1.0 (this specification) |
+| `knowledge` | Knowledge Strand | PRAMANA/1.0 (this specification) |
+| `proof` | Proof/Conformance Strand | PRAMANA/1.0 (this specification) |
+
+**Registration procedure:**
+Organisations wishing to register additional strand types SHOULD submit a registration request
+to the PRAMANA Strand Type Registry at the reference implementation repository
+(https://github.com/rocketlang/forja-protocol). A registration request MUST include: Strand
+Type ID (globally unique, no `x-` prefix), Strand Name, How to check (machine-readable
+description of the binary availability check), Absence implication, and Contact information.
+
+**Non-standard strand types:**
+Organisations implementing non-standard strands for internal use MUST prefix their Strand Type ID
+with `x-` (e.g., `x-regulatory-approval`). Non-standard types MUST NOT be used in
+interoperability scenarios without prior bilateral agreement.
+
+**Authenticity Level namespace:**
+The five Authenticity Levels defined in Section 8 (PRAMANA-0 through PRAMANA-3+) are reserved.
+No implementer may define additional levels within this namespace. Extended strands modify the
+definition of "all strands present" but do not add levels.
+
+---
+
+## 16. Reference Implementation — ANKR
+
+The ANKR reference implementation is maintained by PowerPbox IT Solutions Pvt Ltd.
+
+**Repository:** https://github.com/rocketlang/forja-protocol
+
+**npm packages:**
+- `ankr-forja` — AnkrForja STATE/TRUST/SENSE/PHALA primitives (version 0.2.2+)
+- `ankr-trust-constants` — bitmask constants and strand type registry (version 1.0.2+)
+
+**Reference implementation services:**
+- **AnkrForja** — implements all four signals (STATE, TRUST, SENSE, PHALA). Used by 205+
+  ANKR services.
+- **AnkrCodex** — Capability Strand registry. Crawls all Forja STATE endpoints across the ANKR
+  universe. Provides Strand 1 availability checks.
+- **GRANTHX** — Knowledge Strand registry. Indexes LOGICS documents in `.ib` format. Provides
+  Strand 2 availability checks.
+- **AnkrClaw CCA** — Proof Strand registry. Runs Capability Closure Audits. Provides Strand 3
+  availability checks.
+
+**The 32-bit Trust Bitmask:**
+The ANKR reference implementation encodes service capabilities as a 32-bit integer per service:
+- Bits 0–7: Universal Forja (READ, QUERY, WRITE, EXECUTE, APPROVE, AUDIT, ADMIN, SUPER)
+- Bits 8–15: Maritime 8x block
+- Bits 16–23: Logistics block
+- Bits 24–31: AGI autonomy tier
+
+This encoding allows AnkrCodex to answer "which of 200+ services can perform a given capability"
+via a single bitmask AND operation across 200 rows — sub-millisecond, zero interpretation,
+zero hallucination possible.
+
+---
+
+## 17. Authors
+
+```
+Capt. Anil Kumar Sharma
+Founder, PowerPbox IT Solutions Pvt Ltd
+DPIIT Registered Startup, Haryana, India
+capt.anil.sharma@powerpbox.org
++91-7506926394
+
+The ANKR system described in this document represents the output of a solo founder building
+with AI as co-author. Every protocol, architecture decision, and naming convention in this
+document was conceived and validated under conditions that have no precedent in institutional
+engineering. The Nalanda epistemological framework was not adopted as branding — it was
+recognised as the exact framework that the problem required.
+
+धर्मकीर्ति's Pramana ends at valid inference. So does this protocol.
+The 15% that remains human — moral judgment, creative originality, contextual wisdom —
+cannot be delegated to a machine. Not now. Not in any protocol version.
+
+Priority date: 2026-03-28
+```
+
+---
+
+*PRAMANA/1.0 — Open Protocol Specification*
+*© 2026 PowerPbox IT Solutions Pvt Ltd. Open protocol. Reference implementation Apache 2.0.*
+*capt.anil.sharma@powerpbox.org | +91-7506926394*