1cc453c97b
- Add PolicySourceStore for tracking where policies come from - Implement claim extraction skill and API endpoints - Add community UI text selection extractor component - Create Go SDK aphoria client for policy operations - Document patent specifications and legal disclosures - Add guides: golden path loop, policy audit trails, pre-flight checks - Expand Unreal Engine config extractor with source tracking - Add UAT reports for policy source tracking validation - Refactor tests.rs into modular test files Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
40 KiB
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 |