# Aphoria Patent Figures

**Subject:** Method and System for Detecting Epistemic Conflicts in Computer Code and Configuration
**Date:** 2026-02-04

These figure descriptions are intended for a patent draftsperson to render as formal patent drawings.

---

## FIG. 1: System Architecture Block Diagram

**Purpose:** High-level view of the invention's components and data flow.

**Elements:**

```
┌─────────────────────────────────────────────────────────────────────────────┐
│                                                                             │
│   ┌──────────────┐                                                          │
│   │ Source Code  │                                                          │
│   │    Input     │ (.rs, .py, .yaml, .json, .toml)                          │
│   └──────┬───────┘                                                          │
│          │                                                                  │
│          ▼                                                                  │
│   ┌──────────────────────────────────────┐                                  │
│   │         PARSER MODULE (102)          │                                  │
│   │  ┌────────────┐  ┌─────────────-───┐ │                                  │
│   │  │File Walker │  │Language Detector│ │                                  │
│   │  └─────┬──────┘  └───────┬──────-──┘ │                                  │
│   │        └────────┬────────┘           │                                  │
│   │                 ▼                    │                                  │
│   │        ┌────────────────┐            │                                  │
│   │        │Extractor Engine│            │                                  │
│   │        └───────┬────────┘            │                                  │
│   └────────────────┼─────────────────────┘                                  │
│                    │                                                        │
│                    ▼                                                        │
│   ┌──────────────────────────────────────┐                                  │
│   │    TRANSFORMATION ENGINE (104)       │                                  │
│   │                                      │                                  │
│   │  Raw Text ──► Semantic Triple        │                                  │
│   │  "verify=False" ──► {S,P,O}          │                                  │
│   └────────────────┬─────────────────────┘                                  │
│                    │                                                        │
│                    ▼                                                        │
│   ┌──────────────────────────────────────┐     ┌────────────────────────┐   │
│   │   CONFLICT DETECTION ENGINE (106)    │◄────┤ KNOWLEDGE GRAPH DB     │   │
│   │                                      │     │      (108)             │   │
│   │  • Query matching assertions         │────►│  • RFC Assertions      │   │
│   │  • Compare object values             │     │  • Vendor Docs         │   │
│   │  • Identify conflict conditions      │     │  • Org Policies        │   │
│   └────────────────┬─────────────────────┘     │  • Authority Weights   │   │
│                    │                           └─────────▲──────────────┘   │
│                    ▼                                     │                  │
│   ┌──────────────────────────────────────┐     ┌─────────┴──────────────┐   │
│   │       SCORING MODULE (110)           │     │  TRUST PACK MODULE     │   │
│   │                                      │     │       (112)            │   │
│   │  Score = (W_auth - W_code) × D       │     │  • Signature Verify    │   │
│   │                                      │     │  • Policy Merge        │   │
│   └────────────────┬─────────────────────┘     └────────────────────────┘   │
│                    │                                                        │
│                    ▼                                                        │
│   ┌──────────────────────────────────────┐                                  │
│   │           OUTPUT (114)               │                                  │
│   │  Ordered List of Conflicts           │                                  │
│   │  Ranked by Conflict Score            │                                  │
│   └──────────────────────────────────────┘                                  │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘
```

**Reference Numerals:**

- 100: System for detecting configuration conflicts
- 102: Parser module
- 104: Transformation engine
- 106: Conflict detection engine
- 108: Knowledge graph database
- 110: Scoring module
- 112: Trust pack module
- 114: Output interface

**Description:**
FIG. 1 illustrates a system (100) for detecting configuration conflicts in source code. The system comprises a parser module (102) that ingests source code files and extracts configuration statements. A transformation engine (104) converts extracted configurations into normalized semantic triples. A knowledge graph database (108) stores authoritative assertions with associated authority weights. A conflict detection engine (106) queries the database to identify conflicts between code-derived triples and authoritative assertions. A scoring module (110) calculates conflict scores based on authority weight differentials. A trust pack module (112) enables injection of cryptographically-signed organizational policies into the knowledge graph.

---

## FIG. 2: Knowledge Graph Schema

**Purpose:** Detailed view of the data structure used to store and link concepts.

**Elements:**

```
                    ┌─────────────────────────┐
                    │   SOURCE NODE (202)     │
                    │   "RFC 5246"            │
                    │   Tier: 0 (Regulatory)  │
                    │   Weight: 1.0           │
                    └───────────┬─────────────┘
                                │
                   Assertion Edge (206)
                   ├─ Predicate: "enabled"
                   ├─ Value: "true"
                   ├─ Signature: [Ed25519]
                   └─ Timestamp: 2024-01-01
                                │
                                ▼
┌───────────────────────────────────────────────────────────────────┐
│                      CONCEPT NODE (204)                           │
│                  "tls/cert_verification"                          │
│                                                                   │
│   Incoming Assertions:                                            │
│   ┌─────────────────┬─────────────────┬─────────────────┐         │
│   │ RFC 5246        │ Vendor Docs     │ User Config     │         │
│   │ W=1.0, V=true   │ W=0.7, V=true   │ W=0.5, V=false  │         │
│   └─────────────────┴─────────────────┴─────────────────┘         │
└───────────────────────────────────────────────────────────────────┘
                                ▲
                   Assertion Edge (206)
                   ├─ Predicate: "enabled"
                   ├─ Value: "false"
                   ├─ Signature: [Ed25519]
                   └─ Timestamp: 2026-02-04
                                │
                    ┌───────────┴─────────────┐
                    │   SOURCE NODE (202)     │
                    │   "User Code"           │
                    │   Tier: 3 (Expert)      │
                    │   Weight: 0.5           │
                    └─────────────────────────┘
```

**Reference Numerals:**

- 202: Source node
- 204: Concept node
- 206: Assertion edge

**Description:**
FIG. 2 depicts the knowledge graph schema where source nodes (202) representing origins of authority (RFC documents, vendor documentation, user code) are linked to concept nodes (204) representing configuration topics via assertion edges (206). Each assertion edge carries properties including the predicate type, asserted value, cryptographic signature, and timestamp. Multiple contradictory assertions may coexist attached to a single concept node, with conflicts resolved by comparing authority weights.

---

## FIG. 3: Semantic Triple Transformation Flowchart

**Purpose:** The process of converting raw code into a queryable semantic format.

**Elements:**

```
        ┌─────────────────────────────────────┐
        │           START (302)               │
        │   Read Source File Line             │
        │   Input: "verify = False"           │
        └───────────────┬─────────────────────┘
                        │
                        ▼
        ┌─────────────────────────────────────┐
        │      PATTERN MATCHING (304)         │
        │   Apply Regex/AST Rules             │
        │   Match: verify = <BOOL>            │
        └───────────────┬─────────────────────┘
                        │
                        ▼
        ┌─────────────────────────────────────┐
        │      CONTEXT EXTRACTION (306)       │
        │   File: client.py                   │
        │   Language: Python                  │
        │   Scope: function ssl_connect()     │
        └───────────────┬─────────────────────┘
                        │
                        ▼
        ┌─────────────────────────────────────┐
        │    SUBJECT NORMALIZATION (308)      │
        │   Map: python/.../verify            │
        │   To:  tls/cert_verification        │
        │   (Using Ontology Alias Table)      │
        └───────────────┬─────────────────────┘
                        │
                        ▼
        ┌─────────────────────────────────────┐
        │     OBJECT NORMALIZATION (310)      │
        │   Map: Python "False"               │
        │   To:  Boolean(false)               │
        │   (Canonical Type System)           │
        └───────────────┬─────────────────────┘
                        │
                        ▼
        ┌─────────────────────────────────────┐
        │     TRIPLE CONSTRUCTION (312)       │
        │   Subject: tls/cert_verification    │
        │   Predicate: enabled                │
        │   Object: false                     │
        └───────────────┬─────────────────────┘
                        │
                        ▼
        ┌─────────────────────────────────────┐
        │            END (314)                │
        │   Output: Semantic Triple           │
        └─────────────────────────────────────┘
```

**Reference Numerals:**

- 302: Start – read source file
- 304: Pattern matching step
- 306: Context extraction step
- 308: Subject normalization step
- 310: Object normalization step
- 312: Triple construction step
- 314: End – output triple

**Description:**
FIG. 3 illustrates the transformation pipeline for converting source code configurations into semantic triples. The process begins with reading a source file line (302) and applying pattern matching rules (304) to identify configuration statements. Context extraction (306) captures metadata including file path, language, and scope. Subject normalization (308) maps language-specific variable names to canonical ontology concepts using an alias table. Object normalization (310) converts language-specific values to canonical types. Triple construction (312) assembles the final semantic triple for graph insertion.

---

## FIG. 4: Conflict Detection Algorithm Flowchart

**Purpose:** The core logic for determining if a configuration conflict exists.

**Elements:**

```
        ┌─────────────────────────────────────┐
        │           START (402)               │
        │   Input: Code Claim Triple (C)      │
        │   C = {tls/cert_verify, enabled,    │
        │        false, W=0.5}                │
        └───────────────┬─────────────────────┘
                        │
                        ▼
        ┌─────────────────────────────────────┐
        │       QUERY GRAPH (404)             │
        │   Find assertions matching          │
        │   C.Subject = tls/cert_verify       │
        └───────────────┬─────────────────────┘
                        │
                        ▼
        ┌─────────────────────────────────────┐
        │   ASSERTIONS FOUND? (406)           │
        │                                     │
        └───────────────┬─────────────────────┘
                        │
            ┌───────────┴───────────┐
            │ NO                    │ YES
            ▼                       ▼
   ┌────────────────┐     ┌─────────────────────────────────────┐
   │   PASS (408)   │     │   FOR EACH AUTHORITY A (410)        │
   │   No authority │     │   A = {tls/cert_verify, enabled,    │
   │   governs this │     │        true, W=1.0, src=RFC5246}    │
   └────────────────┘     └───────────────┬─────────────────────┘
                                          │
                                          ▼
                          ┌─────────────────────────────────────┐
                          │   COMPARE VALUES (412)              │
                          │   A.Value vs C.Value                │
                          │   true vs false                     │
                          └───────────────┬─────────────────────┘
                                          │
                              ┌───────────┴───────────┐
                              │ MATCH                 │ MISMATCH
                              ▼                       ▼
                     ┌────────────────┐     ┌─────────────────────────────────────┐
                     │ CONTINUE (414) │     │   CALCULATE SCORE (416)             │
                     │ Check next     │     │   Score = (W_auth - W_code) × D     │
                     │ authority      │     │   Score = (1.0 - 0.5) × 1.0 = 0.5   │
                     └────────────────┘     └───────────────┬─────────────────────┘
                                                            │
                                                            ▼
                                            ┌─────────────────────────────────────┐
                                            │   THRESHOLD CHECK (418)             │
                                            │   Score >= Block_Threshold?         │
                                            └───────────────┬─────────────────────┘
                                                            │
                                        ┌─────────┬─────────┴─────────┬─────────┐
                                        │ ≥0.5    │ ≥0.2, <0.5        │ <0.2    │
                                        ▼         ▼                   ▼
                               ┌─────────────┐ ┌─────────────┐ ┌─────────────┐
                               │ BLOCK (420) │ │ FLAG (422)  │ │ PASS (424)  │
                               │ High-sev    │ │ Medium-sev  │ │ Low-sev     │
                               │ conflict    │ │ warning     │ │ info only   │
                               └─────────────┘ └─────────────┘ └─────────────┘
                                        │             │               │
                                        └─────────────┼───────────────┘
                                                      ▼
                                        ┌─────────────────────────────────────┐
                                        │            END (426)                │
                                        │   Output: Conflict List             │
                                        │   [{src, score, verdict}...]        │
                                        └─────────────────────────────────────┘
```

**Reference Numerals:**

- 402: Start – receive code claim triple
- 404: Query knowledge graph
- 406: Decision – assertions found?
- 408: Pass – no governing authority
- 410: Loop – iterate authorities
- 412: Compare values
- 414: Continue – values match
- 416: Calculate conflict score
- 418: Threshold check
- 420: Block verdict
- 422: Flag verdict
- 424: Pass verdict
- 426: End – output conflict list

**Description:**
FIG. 4 illustrates the conflict detection algorithm. A code claim triple is received (402) and the knowledge graph is queried (404) for matching authoritative assertions. If no authorities exist (406→408), the code passes. For each authority found (410), object values are compared (412). Mismatches trigger score calculation (416) using the formula Score = (W_auth - W_code) × Distance. The score is compared against configurable thresholds (418) to determine verdict: BLOCK for high-severity conflicts, FLAG for medium-severity, PASS for low-severity.

---

## FIG. 5: Trust Pack Verification Flowchart

**Purpose:** How external policies are safely loaded and merged into the knowledge graph.

**Elements:**

```
        ┌─────────────────────────────────────┐
        │           START (502)               │
        │   Receive Trust Pack File           │
        │   (.pack binary)                    │
        └───────────────┬─────────────────────┘
                        │
                        ▼
        ┌─────────────────────────────────────┐
        │   EXTRACT HEADER (504)              │
        │   • Pack Name                       │
        │   • Version                         │
        │   • Issuer ID (Public Key)          │
        │   • Signature                       │
        └───────────────┬─────────────────────┘
                        │
                        ▼
        ┌─────────────────────────────────────┐
        │   LOOKUP ISSUER (506)               │
        │   Query Trusted Registry for        │
        │   Issuer ID                         │
        └───────────────┬─────────────────────┘
                        │
            ┌───────────┴───────────┐
            │ NOT FOUND             │ FOUND
            ▼                       ▼
   ┌────────────────┐     ┌─────────────────────────────────────┐
   │  REJECT (508)  │     │   VERIFY SIGNATURE (510)            │
   │  Unknown       │     │   Ed25519.verify(                   │
   │  issuer        │     │     data=pack_content,              │
   └────────────────┘     │     sig=signature,                  │
                          │     key=issuer_pubkey)              │
                          └───────────────┬─────────────────────┘
                                          │
                              ┌───────────┴───────────┐
                              │ INVALID               │ VALID
                              ▼                       ▼
                     ┌────────────────┐     ┌─────────────────────────────────────┐
                     │  REJECT (512)  │     │   DESERIALIZE ASSERTIONS (514)      │
                     │  Bad signature │     │   Parse binary to assertion         │
                     └────────────────┘     │   structs                           │
                                            └───────────────┬─────────────────────┘
                                                            │
                                                            ▼
                                            ┌─────────────────────────────────────┐
                                            │   ASSIGN ISSUER WEIGHT (516)        │
                                            │   Map issuer tier from registry:    │
                                            │   • Security Team → Tier 3 (0.5)    │
                                            │   • Exec Sponsor → Tier 2 (0.7)     │
                                            └───────────────┬─────────────────────┘
                                                            │
                                                            ▼
                                            ┌─────────────────────────────────────┐
                                            │   MERGE INTO GRAPH (518)            │
                                            │   • Insert new assertions           │
                                            │   • Apply aliases                   │
                                            │   • Record provenance               │
                                            └───────────────┬─────────────────────┘
                                                            │
                                                            ▼
                                            ┌─────────────────────────────────────┐
                                            │            END (520)                │
                                            │   Graph Updated                     │
                                            │   Provenance logged                 │
                                            └─────────────────────────────────────┘
```

**Reference Numerals:**

- 502: Start – receive trust pack file
- 504: Extract header and signature
- 506: Lookup issuer in trusted registry
- 508: Reject – unknown issuer
- 510: Verify cryptographic signature
- 512: Reject – invalid signature
- 514: Deserialize assertions
- 516: Assign issuer authority weight
- 518: Merge into knowledge graph
- 520: End – graph updated

**Description:**
FIG. 5 illustrates the trust pack verification and merge process. A trust pack file is received (502) and its header extracted (504) including the issuer's public key. The issuer is validated against a trusted registry (506); unknown issuers are rejected (508). For known issuers, the Ed25519 signature is cryptographically verified (510); invalid signatures are rejected (512). Valid packs are deserialized (514), assertions are assigned authority weights based on the issuer's tier (516), and merged into the knowledge graph (518) with provenance records.

---

## FIG. 6: Example Knowledge Graph Fragment with Authority Weights

**Purpose:** Concrete visualization of "Epistemic Drift" showing conflicting assertions attached to a single concept.

**Elements:**

```
                           ┌──────────────────────────────────────────────────┐
                           │                                                  │
   ┌───────────────────┐   │   ┌─────────────────────────────────────────┐    │
   │   RFC 7519 (602)  │   │   │                                         │    │
   │   Tier 0          │   │   │      CONCEPT NODE (610)                 │    │
   │   W = 1.0         │───┼──►│   "jwt/audience_validation"             │    │
   │                   │   │   │                                         │    │
   │   Assertion:      │   │   │   ═══════════════════════════════════   │    │
   │   "MUST verify"   │   │   │                                         │    │
   └───────────────────┘   │   │   Assertion Summary:                    │    │
                           │   │   ┌────────────────────────────────┐    │    │
   ┌───────────────────┐   │   │   │ Source      │ Value  │ Weight  │    │    │
   │ Spring Docs (604) │   │   │   ├────────────────────────────────┤    │    │
   │   Tier 2          │───┼──►│   │ RFC 7519    │ true   │ 1.0     │    │    │
   │   W = 0.7         │   │   │   │ Spring Docs │ true   │ 0.7     │    │    │
   │                   │   │   │   │ User Code   │ false  │ 0.5     │◄───┼────┼── CONFLICT
   │   Assertion:      │   │   │   └────────────────────────────────┘    │    │   Score: 0.5
   │   "Should enable" │   │   │                                         │    │
   └───────────────────┘   │   └─────────────────────────────────────────┘    │
                           │                                                  │
   ┌───────────────────┐   │                  ▲                               │
   │  User Code (606)  │   │                  │                               │
   │   Tier 3          │───┼──────────────────┘                               │
   │   W = 0.5         │   │                                                  │
   │                   │   │   ┌─────────────────────────────────────────┐    │
   │   Assertion:      │   │   │         VISUAL: AUTHORITY GAP           │    │
   │   "enabled=false" │   │   │                                         │    │
   └───────────────────┘   │   │   W=1.0 ████████████████████ RFC 7519   │    │
                           │   │   W=0.7 ██████████████       Spring     │    │
                           │   │   W=0.5 ██████████           User Code  │    │
                           │   │         ▲                               │    │
                           │   │         └── Gap = 0.5 (BLOCK)           │    │
                           │   └─────────────────────────────────────────┘    │
                           │                                                  │
                           └──────────────────────────────────────────────────┘
```

**Reference Numerals:**

- 602: RFC source node (Tier 0, W=1.0)
- 604: Vendor documentation source node (Tier 2, W=0.7)
- 606: User code source node (Tier 3, W=0.5)
- 610: Concept node (jwt/audience_validation)

**Description:**
FIG. 6 visualizes a specific conflict scenario in the knowledge graph. The concept node (610) "jwt/audience_validation" receives three incoming assertions from sources of different authority tiers: RFC 7519 (602) at Tier 0 asserting the value "true" with weight 1.0, Spring documentation (604) at Tier 2 asserting "true" with weight 0.7, and user code (606) at Tier 3 asserting "false" with weight 0.5. The authority gap between the RFC assertion (1.0) and the user code assertion (0.5) produces a conflict score of 0.5, triggering a BLOCK verdict.

---

## FIG. 7: Example Conflict Detection Scenario (End-to-End)

**Purpose:** Demonstration of the complete user experience from source code to conflict report.

**Elements:**

```
┌─────────────────────────────────────────────────────────────────────────────────────────┐
│                                                                                         │
│   INPUT (702)                    PROCESSING (704)               OUTPUT (706)            │
│   ────────────                   ──────────────                 ────────────            │
│                                                                                         │
│   ┌─────────────────────┐       ┌─────────────────────┐       ┌─────────────────────┐   │
│   │ Source File:        │       │ Triple Extraction:  │       │ CONFLICT REPORT     │   │
│   │ jwt_handler.py      │       │                     │       │                     │   │
│   │                     │       │ Subject:            │       │ ┌─────────────────┐ │   │
│   │ ┌─────────────────┐ │       │   jwt/verify        │       │ │ SEVERITY: BLOCK │ │   │
│   │ │ Line 42:        │ │ ───►  │                     │ ───►  │ │ (Red indicator) │ │   │
│   │ │                 │ │       │ Predicate:          │       │ └─────────────────┘ │   │
│   │ │ jwt.decode(     │ │       │   enabled           │       │                     │   │
│   │ │   token,        │ │       │                     │       │ Location:           │   │
│   │ │   verify=False  │ │       │ Object:             │       │   jwt_handler.py:42 │   │
│   │ │ )               │ │       │   false             │       │                     │   │
│   │ │                 │ │       │                     │       │ Violation:          │   │
│   │ └─────────────────┘ │       │ Weight:             │       │   RFC 7519 §7.2     │   │
│   │                     │       │   0.5 (User Code)   │       │   "JWT signature    │   │
│   └─────────────────────┘       └─────────────────────┘       │    MUST be verified"│   │
│                                                               │                     │   │
│                                  ┌─────────────────────┐       │ Authority:         │   │
│                                  │ Graph Query:        │       │   Tier 0 (RFC)     │   │
│                                  │                     │       │                    │   │
│                                  │ Match Found:        │       │ Conflict Score:    │   │
│                                  │   RFC 7519 §7.2     │       │   0.50             │   │
│                                  │                     │       │                    │   │
│                                  │ Authority Value:    │       │ Recommendation:    │   │
│                                  │   verify=true       │       │   Set verify=True  │   │
│                                  │                     │       │   or acknowledge   │   │
│                                  │ Authority Weight:   │       │   with signature   │   │
│                                  │   1.0               │       │                    │   │
│                                  │                     │       └────────────────────┘   │
│                                  │ Score Calc:         │                                │
│                                  │   (1.0-0.5)×1.0     │                                │
│                                  │   = 0.50            │                                │
│                                  └─────────────────────┘                                │
│                                                                                         │
└─────────────────────────────────────────────────────────────────────────────────────────┘
```

**Reference Numerals:**

- 702: Input – source code file with configuration
- 704: Processing – triple extraction, graph query, score calculation
- 706: Output – conflict report with verdict and recommendations

**Description:**
FIG. 7 demonstrates the end-to-end user experience for conflict detection. A source file (702) containing the code `jwt.decode(token, verify=False)` is processed. The system extracts a semantic triple (704) representing the configuration claim. A graph query identifies RFC 7519 §7.2 as the governing authority requiring `verify=true`. The conflict score is calculated as (1.0 - 0.5) × 1.0 = 0.50. The output (706) is a structured conflict report identifying the file location, violated standard, authority tier, conflict score, and recommended remediation.

---

## Revision History

| Date       | Author  | Changes                                                                      |
| ---------- | ------- | ---------------------------------------------------------------------------- |
| 2026-02-04 | Initial | Complete figure descriptions with reference numerals per patent requirements |
