◎ OS PUB Apache 2.0 ← All specifications

P128 — AIEP — Semantic Branch Detection Evidence-Grounded Interpretation

Publication Date: 2026-03-01 Status: Open Source Prior Art Disclosure Licence: Apache License 2.0 Author/Organisation: Phatfella Ltd Schema: AIEP_OS_SPEC_TEMPLATE v1.0.1 — https://aiep.dev/schemas/aiep-os-spec-template/v1.0.1

Framework Context

[0001] This disclosure operates within an Architected Instruction and Evidence Protocol (AIEP) environment as defined in United Kingdom patent application number GB2519711.2, filed 20 November 2025, and GB2519798.9, filed 20 November 2025, the entire contents of which are incorporated herein by reference.

[0002] The present disclosure extends the Evidence Rail architecture defined in P37 and the dissent signal mechanism defined in P126 to the specific application of detecting questions with genuinely distinct valid interpretations under different frameworks, and producing evidence-grounded answers for each interpretation.

Field of the Disclosure

[0003] This disclosure relates to governed artificial intelligence reasoning substrates that detect interpretive ambiguity in incoming questions and surface multiple evidence-grounded answers corresponding to genuinely distinct semantic interpretations.

[0004] More particularly, the disclosure concerns a mechanism within a PIEA Evidence Rail substrate for: (a) applying heuristic ambiguity signals to classify whether a question warrants semantic branch analysis; (b) invoking a secondary AI inference call with a structured JSON-constrained prompt to determine whether the question has two genuinely distinct valid interpretations under different valid frameworks; (c) if ambiguity is confirmed, generating evidence-grounded answers for each interpretation and returning them as a SemanticBranch array; and (d) streaming the branch array to the client as a separate server-sent event after the primary response, and persisting the array alongside the response in the session store.

Background

[0005] A class of factual and analytical questions admits multiple valid answers depending on which interpretive framework is applied. Example: “who is responsible for regulating AI in the UK?” admits both a legal/statutory answer (specific regulatory bodies under existing frameworks) and a policy/governance answer (governmental departments and standards bodies with oversight responsibilities). Both answers are correct under their respective frameworks. A system that returns only one answer without noting the interpretive fork may inadvertently mislead users operating under the other framework.

[0006] Existing AI systems handle ambiguity by: (a) generating a single answer blending both frameworks without distinguishing them; (b) asking the user for clarification before answering; or (c) producing parallel responses only when the user explicitly requests them. None of these approaches: (a) detects interpretive ambiguity automatically using evidence-grounded analysis; (b) associates each interpretation with the specific evidence artefacts from which its answer is derived; or (c) streams the interpretations as a first-class, persistable, structured field on the response.

Summary of the Disclosure

[0007] A SemanticBranch record comprises: an interpretation string (one sentence describing the framework or lens under which the answer is valid); an answer string (2–3 sentence evidence-grounded answer); and an is_primary boolean indicating which branch most closely matches the conventional reading of the question.

[0008] The Ambiguity Heuristic Gate is applied before the secondary AI call. The gate checks whether the lower-cased question contains any member of a defined TRIGGERS set of substrings associated with interpretive ambiguity (e.g. "is ", "are ", "elected", "appointed", "responsible", "govern", "regulate", "define", "classified", "considered"). If no trigger matches, the function returns null without invoking a secondary AI call, eliminating unnecessary inference cost for questions that are unambiguous by construction.

[0009] If the gate passes and at least one evidence artefact is available, the Semantic Branch Detector invokes a secondary AI call on the same inference binding. The prompt is a structured JSON-constrained instruction containing: (a) the original question; (b) the leading 300 characters of text exerpts from up to three evidence artefacts; and (c) an explicit instruction to respond only with valid JSON, either {"is_ambiguous": false} or a six-field object containing is_ambiguous, primary_interpretation, primary_answer, alternative_interpretation, alternative_answer. No prose, markdown, or additional fields are permitted.

[0010] The response is parsed against the JSON schema. If the parsed object has is_ambiguous === false or is missing required fields, the function returns null. If the object is valid, two SemanticBranch records are constructed: one with is_primary: true using the primary_* fields, and one with is_primary: false using the alternative_* fields.

[0011] On the primary response path, the detectSemanticBranches() function is called after the dissent signal has been evaluated, using the driftRail (SSE path) or mergedRail (non-SSE path) as the evidence input. If branches are returned, they are: (a) streamed as a branches server-sent event on the SSE channel ({ "branches": SemanticBranch[] }); and (b) persisted to the KV session store as semantic_branches on the message record.

[0012] The branches event arrives at the client after the done event. The client’s askStream() handler invokes callbacks.onBranches?.(data.branches). The Chat component applies the branches to the active message record, which triggers a re-render of the <ReasoningReplay> component to display an Alternative Interpretation collapsible panel below the reasoning chain.

[0013] The Alternative Interpretation UI panel renders two BranchCard elements side-by-side (stacked on mobile viewports): one tagged “Primary” showing the primary interpretation and its evidence-grounded answer; one tagged “Alternative” showing the alternative interpretation and its evidence-grounded answer. Both cards visually differentiate via distinct background and border colours to prevent conflation.

Detailed Description

[0014] SemanticBranch Interface. Defined as:

interface SemanticBranch {
    interpretation: string;  // one sentence: framework/lens for this reading
    answer: string;          // 2-3 sentence evidence-grounded answer
    is_primary: boolean;     // true = primary/conventional reading
}

[0015] Heuristic Trigger Set. The TRIGGERS set is intentionally conservative, covering only substrings associated with questions about assignment of responsibility, governance, classification, and definition — the categories most likely to admit genuine dual-framework ambiguity. Questions that are purely factual with a single numerical or named answer (e.g. “what is the boiling point of water?”) do not contain trigger substrings and therefore do not incur the secondary AI call.

[0016] Evidence Grounding Contract. The secondary AI call is supplied with evidence excerpts from the same EvidenceRef artefacts that grounded the primary response. The structured prompt instructs the model to derive both interpretatations and answers from the supplied evidence. This maintains the AIEP principle that all answers must be traceable to retrieved, hashed source artefacts. A semantic branch whose answer cannot be traced to the current evidence rail is rejected by the JSON schema gate (absent required fields) and not surfaced.

[0017] JSON Safety. The response parser uses raw.match(/\{[\s\S]*\}/) to extract the first JSON object literal before attempting JSON.parse(), tolerating minor model-generated padding. The entire parse is wrapped in a try-catch that returns null on any failure, making the feature non-fatal. A branch detection failure does not affect the primary response, the reasoning chain, or the session persistence.

[0018] Distinction from Dissent (P126). P126 dissent is triggered by low confidence tier or sparse evidence — it signals unreliability of the response as a whole. P128 semantic branching is triggered by interpretive ambiguity in the question itself, independent of evidence quality. A question may produce both a dissent signal (evidence sparse) and a semantic branch result (question is interpretively ambiguous). The two mechanisms are orthogonal and their outputs are surfaced separately in the UI.

[0019] SSE Ordering. The branches event is sent after done. Clients must not assume that done terminates the event stream; additional events may follow. The stream is terminated by the server closing the writable stream end. The done event signals completion of the primary inference; post-done events (contradiction, dissent, branches) are supplementary analysis results.

Claims Narrative

[0020] The novel aspects of this disclosure are: (1) a heuristic ambiguity gate that classifies questions against a defined trigger set before invoking a secondary inference call, eliminating cost for unambiguous questions; (2) a JSON-constrained secondary inference prompt that produces structured is_ambiguous and dual-interpretation fields from the same evidence artefacts used for the primary response; (3) the SemanticBranch record type as a first-class persistable field on the session message store; (4) streaming semantic branch results as a branches server-sent event after done on the same SSE channel; (5) the client-side <ReasoningReplay> panel unifying reasoning chain replay (P127) and semantic branch display (P128) in a single collapsible component; and (6) the architectural distinction between confidence-based dissent (P126) and interpretive-ambiguity-based branching (P128), enabling simultaneous emission of both on a single response.

Brief Description of the Drawing

FIG. 1 — Semantic Branch Detection Pipeline

   question + driftRail
   ┌───────────────────────────────────────────────────────────┐
   │  detectSemanticBranches(ai, model, question, evidence)    │
   │                                                           │
   │  1. Heuristic Gate — check TRIGGERS set                   │
   │     └─ no match → return null (no AI call)               │
   │                                                           │
   │  2. evidence.length === 0 → return null                  │
   │                                                           │
   │  3. Secondary AI call — JSON-constrained prompt           │
   │     └─ { is_ambiguous, primary_*, alternative_* }        │
   │                                                           │
   │  4. Parse + validate → SemanticBranch[] | null           │
   └───────────────────────────────────────────────────────────┘
                │ SemanticBranch[]
                ▼
   piea-worker SSE path
   ┌───────────────────────────────────────────────────────────┐
   │  send("done", { response_id })                           │
   │  [contradiction + dissent already sent]                  │
   │  send("branches", { branches })                          │
   │  session.messages.push({ ..., semantic_branches })       │
   └───────────────────────────────────────────────────────────┘
                │
                ▼
   piea-ui Chat.tsx
   ┌───────────────────────────────────────────────────────────┐
   │  onBranches: Message.semantic_branches = branches        │
   │  render: <ReasoningReplay branches={...} />              │
   │    └─ Alternative Interpretation panel                   │
   │       ├─ BranchCard "Primary"                            │
   │       └─ BranchCard "Alternative"                        │
   └───────────────────────────────────────────────────────────┘