Operational Evidence Qualification and Suitability: A Formal Architecture for Source Authorization, Inspection, Review, Reliance, Use, Currentness, and Decision Support

1\. Metadata and Research-Status Front Matter#

Document ID: PAT-ARCH-001-2026 Version: 1.0.0 Status: Research architecture proposal Domain: System State Integrity, Evidentiary Qualification, Epistemic Decision Architecture

2\. Executive Decision Brief#

Project Patefacere necessitates a rigorously defined evidence and state-integrity layer that maps cryptographic, procedural, and temporal realities to structured state tracking without conflating data presence with real-world truth or legal effect. The core architectural challenge is bounding epistemological certainty: determining precisely when a specific body of evidence is suitable for one exact purpose at one exact time, and capturing the required proof without overstating what the evidence establishes. The analysis reveals that legacy systems frequently fail because they collapse distinct properties—such as authenticity (who signed it) and accuracy (whether it is true)—into a single boolean metric of "trust." This conflation leads to catastrophic downstream failures when a cryptographically authentic payload contains mathematically verifiable but semantically false data, or when a historically reliable source submits a compromised artifact. To resolve this, Patefacere must implement a compartmentalized semantic architecture. By synthesizing digital forensics standards like ISO/IEC 270371, assurance cases from ISO/IEC 15026-24, supply chain transparency mechanisms from IETF SCITT and in-toto7, clinical evidence grading principles10, and Subjective Logic frameworks for uncertainty13, this report establishes a formal structure for the Patefacere entity lifecycle. This architecture guarantees that Patefacere evaluates qualification and suitability as point-in-time, purpose-bound mathematical calculations over an append-only evidence graph, explicitly preventing the silent conversion of evidence into deployment, publication, or legal authority. \[PATEFACERE DESIGN RECOMMENDATION\]

3\. Formal Definitions#

The following definitions distinguish system properties from human interpretations, forming the epistemic baseline for Patefacere. The architecture operates strictly on these demarcations to prevent the overextension of cryptographic proofs into semantic domains. Source Authorization: The cryptographic or procedural permission granted to an entity to submit claims or records to the system within a defined scope. It is an administrative state. Authorization is not authenticity. \[ESTABLISHED EXTERNAL PRACTICE\] Source Authenticity: The cryptographic proof that a specific, identified entity generated a specific record (e.g., via a verifiable signature). It proves origin, not veracity. Authenticity is not accuracy. \[ESTABLISHED STANDARD\] Source Integrity: The mathematical proof (e.g., via SHA-256 or ML-DSA-87 signatures) that a record has not been altered since its creation16. It ensures the bit-for-bit consistency of the payload. Integrity is not truth. \[ESTABLISHED STANDARD\] Evidentiary Relevance: A logical mapping indicating that a specific record pertains to a specific decision purpose or assurance case claim4. A perfectly authentic, high-integrity record may possess zero relevance to a given query. Relevance is not suitability. \[RESEARCH FINDING\] Reliability: The consistency of a source or inspection process over time, often evaluated using probabilistic or subjective logic metrics where belief, disbelief, and uncertainty are quantified13. Reliability is a historical metric and does not guarantee the truth of a future individual claim. \[ESTABLISHED EXTERNAL PRACTICE\] Completeness: The presence of all required cryptographic, semantic, and contextual fields mandated by a specific schema or data quality framework like ISO 8000-6118. Currentness is not completeness. \[ESTABLISHED STANDARD\] Currentness (Freshness): A calculation of temporal validity, bounding the age of evidence relative to a trusted clock (e.g., NTP RFC 5905\) and predefined decay parameters20. It dictates whether historical evidence remains epistemically sound for present-time decisions. \[RESEARCH FINDING\] Reproducibility: The ability to trace and re-verify the derivation of a state or receipt using the same inputs, logic, and environment constraints, bounded by stochastic or non-deterministic variables inherent to the process (e.g., AI model inference)1. \[ESTABLISHED STANDARD\] Qualification: The evaluation of an evidence chain against a purpose-specific policy, ensuring all required components (e.g., source types, inspection depths, review consensus) are present and valid. Qualification is not certification; it is an internal system state, not an external guarantee. \[PATEFACERE DESIGN RECOMMENDATION\] Suitability: A point-in-time, deterministic conclusion that a qualified evidence chain satisfies all conditions required for reliance for a single, named purpose. Suitability is not authority; it dictates that action may be taken, not that action must be taken. \[PATEFACERE DESIGN RECOMMENDATION\] Admissibility: A strictly legal construct determining whether a court or tribunal will consider evidence (e.g., FRE 901, eIDAS Art 41\)22. Evidence storage does not create legal effect; admissibility is out of scope for Patefacere's internal execution logic. \[REJECTED ANALOGY\]

4\. Evidence-Property Taxonomy#

Properties must be correctly attributed to the specific entity in the evidence chain, rather than globally applied to a generalized concept of "trust." Misattribution of these properties is the primary cause of automated decision failures in legacy systems. \[RESEARCH FINDING\]

5\. Evidence-Chain Entity Model#

The internal Patefacere vocabulary encapsulates a rigorous assurance case structure derived from ISO 15026-24. The conceptual soundness of these entities maps directly to modern supply chain transparency architectures (IETF SCITT)8 and data provenance metadata models (in-toto)9.

• PAT-OEA (Source-Authorization Profile): Defines the root identity, public keys, and authorized scope of a source. This maps conceptually to a trust anchor or X.509 certificate profile, delineating who is permitted to speak within a specific domain.
• PAT-OED (Source-Authorization Decision): The point-in-time binding of an identity to an allowed claim space. It converts the static profile (PAT-OEA) into an active, revocable authorization state.
• PAT-OAI (Point-in-Time Source Integrity Inspection): Cryptographic verification (e.g., signature verification, schema validation) of submitted evidence. This maps to the concept of in-toto "inspections" or SCITT signed statements9.
• PAT-OAR (Review, Contest, Correction, Reinspection, and Closure Evidence): Human or algorithmic appraisal of the evidence. This entity leverages Subjective Logic opinion spaces (Belief, Disbelief, Uncertainty, Base Rate)13. It is crucial to note that contest is not automatic invalidation.
• PAT-ORP (Exact-Purpose Reliance Policy): The parameterized requirements (maximum age, required sources, necessary reviews) for a specific action. This acts as the policy engine configuration.
• PAT-ORD (Point-in-Time Reliance Decision): The deterministic output of evaluating an inspection graph against a PAT-ORP. It states that at time ![][image1], the graph met policy ![][image2].
• PAT-ORU (Use Receipt): Cryptographic proof that an analytical process consumed a specific PAT-ORD. It proves consumption without containing executable code or raw secrets, mapping to SCITT Receipts and in-toto Links24.
• PAT-ORI (Integrity Inspection over Use Receipt): Verification of the PAT-ORU and its dependency graph against the transparency ledger via Merkle inclusion proofs.
• PAT-ORV (Review and Currentness of Use): Temporal validation that a PAT-ORU has not decayed past its useful lifecycle based on clock boundaries.
• PAT-ORF (Fresh-Use Linkage): The cryptographic pointer connecting a stale reliance requirement to a distinct, newer, valid execution pair. Fresh linkage is not process execution; it is a state bridge.
• PAT-ORQ (Proposed Qualification Policy): A formal logic envelope dictating acceptable evidence profiles for a future decision, acting as the ISO 15026-2 "Argument"4.
• PAT-ORS (Proposed Point-in-Time Suitability Decision): A terminal leaf node declaring evidence suitable for a specified action. A positive suitability decision applies only to its named purpose, evidence set, policy, release, and evaluation time. \[PATEFACERE DESIGN RECOMMENDATION\]

6\. Record Invariants#

To guarantee mathematical coherence across the evidence graph, the following 50 formal invariants must hold at all times. A violation of any invariant renders the dependent subset of the graph invalid or transitions it to a CANNOT\_DETERMINE state. \[PATEFACERE DESIGN RECOMMENDATION\]

7\. State and Transition Model#

The system operates as a finite state machine over the directed acyclic graph (DAG) of evidence. Transitions represent the progression of evidentiary states as time passes, reviews are appended, or cryptanalytic conditions shift. \[PATEFACERE DESIGN RECOMMENDATION\]

8\. Currentness and Aging Model#

Evidence aging is not a uniform process. The rate at which evidence becomes obsolete depends entirely on the source class, claim class, purpose, risk level, and real-world change rates33. An authorization profile for a static hardware root of trust may remain current for years, while a threat intelligence feed payload may become stale in minutes. Currentness Calculation Model: Let ![][image5] be the time of evidence creation, ![][image6] be the time of evaluation. Let ![][image7] be the maximum allowed age defined in PAT-ORP. Let ![][image8] be the dynamic risk-decay coefficient (where ![][image9] under normal operating conditions, and ![][image10] accelerates aging under active threat postures or heightened risk levels). The evidence is deemed current if and only if: ![][image11] Clock Trust and Uncertainty: Relying solely on local hardware clocks is insufficient for a rigorous evidence architecture, as it enables trivial replay and rollback attacks20. Patefacere must utilize Network Time Protocol (RFC 5905\) to bound clock uncertainty, ideally anchored by eIDAS qualified electronic timestamps3. If the NTP offset ![][image12] or root dispersion ![][image13] exceeds a defined threshold, the clock state is marked UNCERTAIN. Crucially, clock rollback (where ![][image14]) triggers an immediate system-wide halt to PAT-ORS generation until monotonic time is re-established. For the long-term validity of aging evidence, Patefacere should adopt Hash-Tree Renewal concepts derived from Evidence Record Syntax (RFC 4998 / RFC 6283\)35. This allows cryptographic timestamps and Merkle roots to be sequentially re-signed using newer, post-quantum algorithms before the original hash algorithm becomes computationally weak33.

9\. Contradiction and Dispute Model#

What should happen when reviewers disagree on the veracity of evidence? In clinical grading models (GRADE), inconsistency actively downgrades the certainty of evidence10. In intelligence evaluation frameworks (eIDAS/STANAG 2022), competing hypotheses require structured mathematical resolution38. Patefacere models PAT-OAR (Reviews) using Subjective Logic (as established by Audun Jøsang)13. Rather than forcing a binary TRUE/FALSE outcome upon subjective review data, a review yields a binomial opinion ![][image15], representing Belief (![][image16]), Disbelief (![][image17]), Uncertainty (![][image18]), and a Base Rate (![][image19]), where ![][image20]. Contradiction-Resolution Matrix:

Contest is not automatic invalidation. A dispute flags the evidence as CONTESTED, safely halting downstream reliance without destroying the underlying cryptographic integrity of the record. If a contest proves valid (i.e., the original claim was semantically false despite being cryptographically authentic), the evidence is not "deleted"; a PAT-OAR (Closure) appends a correction, transitioning the original node to SUPERSEDED. \[PATEFACERE DESIGN RECOMMENDATION\]

10\. Purpose-Bound Qualification Model#

Qualification is the mechanism that binds generic, context-free evidence to a specific operational decision via the PAT-ORQ. A piece of evidence (e.g., a software bill of materials) may be perfectly suited for an internal audit but entirely unqualified for triggering an automated production deployment. Purpose-Binding Model: A positive suitability decision applies only to its named purpose. To prevent an "allow" decision for one purpose from being inadvertently reused for a different, riskier purpose, Patefacere implements strict cryptographic purpose-binding:

1. The PAT-ORQ policy requires a mandatory context\uri string (e.g., urn:patefacere:purpose:deploy\model\v2). 2. The resulting PAT-ORS suitability decision calculates a cryptographic hash over the evidence graph and the context\uri. 3. Any subsequent PAT-ORU (Use Receipt) attempting to rely on the decision must supply the identical context\_uri. If the purpose differs, the hashes will fail to align, resulting in an immediate REJECT. \[ESTABLISHED EXTERNAL PRACTICE\]

11\. Point-in-Time Suitability Decision Model#

The generation of a PAT-ORS (Suitability Decision) relies on a strictly deterministic logic gate array evaluated at a specific point in time. It behaves predictably when required evidence is missing, contradictory, malformed, inaccessible, or based on an incompatible schema. Deterministic Decision Table for Suitability Outcomes:

Note: Missing, contradictory, malformed, inaccessible, or schema-incompatible evidence inherently degrades the state to either REJECT or CANNOT\_DETERMINE based on the exact locus of the failure. An absence of data is never construed as an implicit approval. \[RESEARCH FINDING\]

12\. Use Receipt and Reproducibility Model#

How can the system prove that a local analytical process utilized a specific, allowed decision without storing raw confidential inputs or arbitrary executable content in the ledger? Patefacere adopts the software supply chain attestation concepts of in-toto link metadata9 and SCITT Receipts24. A PAT-ORU (Use Receipt) proves that a cryptographic digest of an allowed PAT-ORS was present in the memory space of a defined process ID at a specific timestamp.

• What a use receipt proves: The exact input hashes (materials), the exact output hashes (products), and the hash of the execution environment (command).
• What it does not prove: That the output is semantically true, or that external world state (e.g., a physical actuator, a deployed database) actually changed. A use receipt is not a command receipt. \[PATEFACERE DESIGN RECOMMENDATION\]

For processes that are stochastic, nondeterministic, or model-dependent (e.g., AI inference, randomized algorithmic audits), reproducibility claims must be strictly bounded. The PAT-ORU must include a determinism\_flag: false and capture the exact seed or random-state hash if available. Absolute reproducibility is impossible for stochastic processes; therefore, the PAT-ORU guarantees procedural compliance (proving that the correct model evaluated the correct evidence), not output consistency. \[RESEARCH FINDING\]

13\. Fresh Evidence and Fresh-Use Linkage#

When evidence becomes stale and the system transitions to REQUIRE\FRESH\EVIDENCE, it must link the stalled analytical process to a new evidence evaluation without forcing the entire external process to unnecessarily run from scratch (which could be computationally prohibitive). PAT-ORF (Fresh-Use Linkage) acts as a temporal and cryptographic bridge. It formally records the state transition: "Process X was paused at time T1 due to stale evidence E1. Evidence E2 was evaluated at time T2 and is fresh. Therefore, Process X may resume relying on E2." Fresh linkage is not process execution. The PAT-ORF merely satisfies the PAT-ORP requirement, allowing the local system's state machine to proceed to the next logical node. It connects the lineage of evidence without simulating the execution layer. \[PATEFACERE DESIGN RECOMMENDATION\]

14\. Privacy-Minimized Export Model#

To preserve verification value without leaking Personally Identifiable Information (PII), raw inputs, or confidential business logic, Patefacere utilizes Merkle inclusion proofs (RFC 9162\)7 and Zero-Knowledge (ZK) attestation architectures (such as Circom)30. Privacy and Disclosure Matrix:

By exporting only the Merkle proof and the requisite hashes, external auditors or regulatory bodies can verify that a specific PAT-ORS existed in the immutable log at time ![][image1], and that its cryptographic dependencies hold, without ever seeing the raw inputs of the PAT-OAI. \[OPTIONAL HIGH-ASSURANCE EXTENSION\]

15\. Threat Model#

Patefacere operates under the rigorous Dolev-Yao threat model16, assuming the network is fully controlled by an adversary capable of intercepting, modifying, and injecting messages, but assuming cryptographic primitives (e.g., hashes, signatures) remain unbreakable. This model is validated similarly to protocols evaluated by the Tamarin Prover42. Adversarial and Malformed-Input Test Cases (1-40):

1. Expired Authority: Submit PAT-OEA with an expired X.509 certificate. (Expect: REJECT). 2. Payload Alteration: Submit PAT-OAI with a valid signature but altered payload. (Expect: REJECT). 3. Replay Attack: Replay PAT-OAI from 1 year ago with a current timestamp. (Expect: REJECT via nonce/hash collision). 4. Node Deletion: Delete an intermediate PAT-OAR node from the database. (Expect: CANNOT\DETERMINE during graph walk). 5. Purpose Modification: Submit PAT-ORS with a modified purpose string to bypass policy. (Expect: REJECT on use due to hash mismatch). 6. Clock Rollback: Simulate NTP clock rollback of 5 minutes during PAT-ORV evaluation. (Expect: Halt/UNCERTAIN). 7. Unauthorized Dispute: Append PAT-OAR dispute from an unauthorized identity. (Expect: REJECT the review). 8. Authorized Dispute: Append PAT-OAR dispute from an authorized identity. (Expect: State \-\> CONTESTED). 9. Determinism Violation: Submit PAT-ORU where output hash doesn't match determinism requirements. (Expect: REJECT). 10. Temporal Paradox: Link PAT-ORF to a future timestamp. (Expect: MALFORMED). 11. Parser Crash: Submit JSON with infinitely nested arrays to crash the parser. (Expect: MALFORMED / Handled by schema limits). 12. Bypass Qualification: Attempt to bypass PAT-ORQ by submitting PAT-ORS directly. (Expect: REJECT due to missing PAT-ORQ parent hash). 13. Mid-Transaction Revocation: Revoke PAT-OEA mid-transaction. (Expect: Atomic Rollback / COMPROMISED). 14. Injection Attack: Submit PAT-OED containing SQL/NoSQL injection payload in context string. (Expect: Handled/Escaped, no execution). 15. Sybil Review Attack: Submit 10,000 conflicting PAT-OAR reviews simultaneously. (Expect: CANNOT\DETERMINE / Rate Limit enforced). 16. Missing Mandatory Schema: Submit a validly signed PAT-OAI lacking mandatory schema fields. (Expect: REJECT). 17. Empty Dependencies: Submit PAT-ORS with an empty dependency list. (Expect: MALFORMED). 18. Truncated Proof: Truncate a Merkle inclusion proof. (Expect: REJECT via verification failure). 19. Deprecated Algorithm: Submit PAT-OAI signed with a deprecated algorithm (e.g., SHA-1). (Expect: REJECT). 20. Downstream Reuse: Attempt to reuse a PAT-ORU for a different downstream process. (Expect: REJECT). 21. Policy Alteration: Alter the TTL in a historical PAT-ORP. (Expect: Hash mismatch, REJECT). 22. Network Partition: Simulate network partition blocking transparency log access during PAT-ORI. (Expect: CANNOT\DETERMINE). 23. Jurisdictional Overreach: Submit PAT-OEA claiming authority over an incompatible geographic domain. (Expect: REJECT). 24. Self-Certification: Attempt to self-certify a PAT-OAR closure without an independent identity. (Expect: REJECT). 25. Disconnected Clock: Submit PAT-ORV calculated with a disconnected local clock. (Expect: UNCERTAIN). 26. Cross-Release Mix: Mix Evidence E1 from Release A with Rule R1 from Release B. (Expect: REJECT via version mismatch). 27. Resource Exhaustion: Submit valid PAT-OAI but payload is a multi-gigabyte file. (Expect: REJECT via size limit). 28. Hash Overwrite: Attempt append-only correction that attempts to overwrite the original hash. (Expect: REJECT at ledger level). 29. Illogical Constraints: Submit PAT-ORQ with illogical constraints (e.g., min\age \> max\_age). (Expect: MALFORMED). 30. Duplicate Assertion: Submit duplicate PAT-OAI hash from a different source. (Expect: Accepted as distinct epistemic assertion). 31. Revoked Authority: Submit PAT-OED from a revoked authority. (Expect: REJECT). 32. Invalid ZK Proof: Provide a zero-knowledge proof with invalid constraints. (Expect: REJECT). 33. Zero Dependencies: Request a suitability decision with zero dependent evidence nodes. (Expect: REJECT). 34. Export Extraction: Attempt to extract raw payload from a privacy-minimized export. (Expect: Computationally infeasible). 35. Unrelated Process Linkage: Submit PAT-ORF linking two completely unrelated analytical processes. (Expect: REJECT). 36. Chronological Paradox: Provide PAT-ORU indicating execution before PAT-ORS generation. (Expect: REJECT). 37. Malformed Encoding: Send malformed UTF-8 characters in the purpose string. (Expect: MALFORMED). 38. Key Not Found: Submit PAT-OAI where the public key is not found in the PAT-OEA profile. (Expect: REJECT). 39. Circular Dependency: Attempt to create a circular dependency (Node A depends on B depends on A). (Expect: REJECT via DAG validation). 40. Hardware Failure: Simulate hardware failure mid-write of PAT-ORS. (Expect: Atomic rollback; partial state discarded).

Resistance guarantees: The append-only, cryptographically linked DAG structure natively resists replay, substitution, deletion, unauthorized resequencing, and cross-release mixing by binding temporal state (NTP), spatial state (Merkle inclusion proof), and relational state (parent/child hashes) into a single verifiable envelope.

16\. Cross-Domain Comparative Analysis#

Patefacere draws upon established methodologies across disparate fields, but it is a fundamental mandate to explicitly identify where an analogy stops working. Do not blindly transplant legal concepts into technical evidence systems. \[PATEFACERE DESIGN RECOMMENDATION\]

• Digital Forensics and Chain of Custody (ISO/IEC 27037): Provides excellent models for the Identification, Collection, Acquisition, and Preservation of evidence1. Analogy limits: ISO 27037 relies heavily on human "Digital Evidence First Responders (DEFR)". Patefacere operates algorithmically; human custody chains map poorly to high-velocity API ingestion and machine-to-machine validation.
• Scientific Reproducibility and Data Provenance (GRADE): GRADE evaluates certainty (Very Low to High) based on bias, imprecision, inconsistency, and indirectness10. Analogy limits: GRADE is inherently subjective and requires human panels to formulate narrative recommendations10. Patefacere must remain deterministic and calculable.
• Intelligence-Source Evaluation (Admiralty/STANAG 2022): Maps source reliability against information credibility in a highly structured matrix38. Highly useful for modeling PAT-OAR subjective logic39.
• Software Supply-Chain Attestations (SCITT / in-toto / SLSA): The SCITT transparent ledger24 and in-toto threshold link mechanisms9 are a nearly 1:1 structural fit for Patefacere’s cryptographic requirements. SLSA (NIST SP 800-218) provides robust frameworks for provenance44.
• Financial Auditing and Records Management (ISO 15489): Defines authenticity, reliability, integrity, and usability46. Analogy limits: ISO 15489 considers organizational formatting and business context heavily47; Patefacere operates below the business logic layer, treating payloads as opaque cryptographic objects.
• Safety Cases and Assurance Cases (ISO 15026-2): Structures Claims, Arguments, and Evidence into a formalized tree4. This is an excellent structural analogy for mapping the PAT-ORQ (Argument) to PAT-OAI (Evidence) to reach PAT-ORS (Claim).

17\. Recommended PAT-OEA through PAT-ORS Semantics#

The semantic mapping of the internal project identifiers to their core functions provides clarity on epistemic boundaries. Complete Evidence-Class Matrix:

18\. Recommended Field-Level Schemas#

Schemas must enforce the invariants defined in Section 6, ensuring no credentials or sensitive raw material are stored directly within the structural metadata. Field-by-field semantic definition for PAT-ORQ (Qualification Policy):

JSON { "$schema": "https://patefacere.internal/schema/pat-orq-v1", "id": "urn:uuid:f47ac10b-58cc-4372-a567-0e02b2c3d479", "type": "PAT-ORQ", "purpose\uri": "urn:patefacere:purpose:deploy\v1", "required\evidence": \[ { "schema\type": "PAT-OAI", "source\class": "urn:source:sensor:temperature", "min\belief\threshold": 0.95 } \], "max\age\seconds": 3600, "logic\operator": "AND", "issuer\id": "urn:uuid:123e4567-e89b-12d3-a456-426614174000", "signature": "crypto\signature\base64\encoded" }

Field-by-field semantic definition for PAT-ORS (Suitability Decision):

JSON { "$schema": "https://patefacere.internal/schema/pat-ors-v1", "id": "urn:uuid:550e8400-e29b-41d4-a716-446655440000", "type": "PAT-ORS", "qualification\ref": "urn:uuid:f47ac10b-58cc-4372-a567-0e02b2c3d479", "purpose\uri": "urn:patefacere:purpose:deploy\v1", "evaluation\timestamp": "2026-08-12T10:48:22Z", "clock\status": "SYNCHRONIZED", "decision\outcome": "ALLOW", "dependency\graph\hashes": \[ "sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855", "sha256:8f434346648f6b96df89dda901c5176b10a6d83961dd3c1ac88b59b2dc327aa4" \], "signature": "crypto\signature\base64\_encoded" }

19\. Validation and Test Strategy#

The system must be validated against complex, real-world edge cases. The following 25 scenario walkthroughs dictate expected system behavior under duress. 25 Scenario Walkthroughs:

1. Standard Flow: PAT-OAI executes cleanly ![][image21] PAT-ORQ policy met ![][image21] PAT-ORS evaluates ALLOW. 2. Stale Evidence: Evidence is older than max\age\seconds. PAT-ORS evaluates REQUIRE\FRESH\EVIDENCE. 3. Contested Evidence: PAT-OAR disputes an inspection. PAT-ORS evaluates CANNOT\DETERMINE. 4. Compromised Source: PAT-OEA is revoked. Future PAT-ORS evaluates REJECT. 5. Incomplete Record (Optional): Optional metadata missing. PAT-ORS evaluates ALLOW. 6. Incomplete Record (Mandatory): Mandatory schema field missing. PAT-ORS evaluates REJECT. 7. Superseded Evidence: PAT-OAR closure appends a correction. PAT-ORS relies on the new node, evaluates ALLOW. 8. Cross-Purpose Reuse: PAT-ORU submitted for Purpose A, but references a PAT-ORS generated for Purpose B. Evaluates REJECT. 9. Cross-Release Mixing: PAT-ORQ expects schema v1, receives evidence formatted in v2. Evaluates REJECT. 10. Contradictory Rules: PAT-ORP requires both condition A and condition NOT A. Evaluates MALFORMED. 11. Clock Rollback: System time drifts backwards. System halts processing to protect DAG integrity. 12. Fresh Linkage Pause: Process stalls waiting on REQUIRE\FRESH\EVIDENCE. 13. Fresh Linkage Resume: PAT-ORF bridges to new evidence. Process resumes operation. 14. Offline Evaluation: PAT-ORS calculated without network access using local ERS hash tree. Evaluates ALLOW. 15. Cryptographic Hash Collision: (Computationally infeasible with SHA-256, treated as REJECT if detected by the ledger). 16. Reviewer Disagreement (Subjective Logic): 3 reviewers approve, 1 disputes. Fusion yields ALLOW based on base rate and belief threshold. 17. Reviewer Disagreement (50/50): Fusion yields CANNOT\DETERMINE due to high resulting uncertainty. 18. Privacy Export Validation: External auditor verifies PAT-ORS via Merkle proof without ever seeing the PAT-OAI raw payload. 19. Unreachable Dependency: Graph walk fails due to a deleted node in storage. Evaluates CANNOT\DETERMINE. 20. Unauthorized Submission: PAT-OED lacks sufficient scope for the submitted claim. Evaluates REJECT. 21. Replay Attack: Identical payload and nonce submitted. Ledger layer evaluates REJECT. 22. Append-only Correction: Error discovered in payload. Original stays unmodified. New PAT-OAI appended. PAT-ORF points to the new record. 23. AI Inference Trace: PAT-ORU marks determinism\flag: false. System logs procedural compliance but flags non-deterministic output. 24. Maximum Depth Exceeded: Graph is too deep for evaluation constraints. Evaluates REJECT (resource bound). 25. Post-Quantum Transition: SHA-256 upgraded to ML-DSA via Hash-Tree Renewal without breaking the existing DAG35.

20\. Failure and Rollback Requirements#

Rollback and Atomicity Model: Evidence generation is not a distributed transaction spanning external state databases. Therefore, complex two-phase commit (2PC) protocols are unnecessary and introduce fragility. Instead, Patefacere uses a strict Append-Only Atomicity Model.

• Writes to the transparency log must be atomic (all-or-nothing). If a hardware failure occurs during the generation of a PAT-ORS, the transaction is dropped entirely.
• If an erroneous PAT-ORS is successfully logged, it cannot be deleted. A new PAT-OAR (Correction) must be appended, superseding the incorrect decision, and a new PAT-ORS is generated. Review is not repair. \[PATEFACERE DESIGN RECOMMENDATION\]

21\. Human-Readable and Machine-Readable Presentation#

Records must be verifiable by machines without exposing raw data, while retaining sufficient metadata for human auditing. Sample machine-readable PAT-ORU record containing no credentials or sensitive raw material:

JSON { "header": { "type": "PAT-ORU", "version": "1.0", "timestamp": "2026-08-12T10:48:22Z" }, "payload": { "process\id": "analysis-engine-x86\64", "consumed\decision\ref": "urn:uuid:8f3b2a1c-99da-4e78-b1e2-349f7b62dc1a", "purpose\uri": "urn:patefacere:purpose:deploy\v1", "determinism\flag": true, "input\hashes": \[ "sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855" \] }, "signature": "MEUCIQD... (truncated for brevity)" }

22\. Open Questions#

1. Quantum Cryptography Transitions: How should Patefacere gracefully deprecate ML-DSA if NIST Level 5 standards are eventually compromised by unforeseen cryptanalytic advances? \[UNRESOLVED\] 2. Subjective Logic Calibration: What is the most mathematically defensible base rate (![][image19]) for an entirely unknown entity submitting a PAT-OAR review for the first time? \[UNRESOLVED\] 3. Cross-jurisdictional Clock Trust: How should the system handle localized temporal disputes if eIDAS qualified timestamps conflict with DoD-managed NTP servers during a network partition? \[UNRESOLVED\]

23\. Bibliography#

• ISO/IEC 27037:2012 Digital Evidence Chain of Custody1.
• GRADE guidelines (Certainty of Evidence)10.
• ISO 15489-1:2016 Records Management46.
• ISO 8000-61 Data Quality Management18.
• Admiralty System / STANAG 202238.
• IETF SCITT Architecture (RFC 9162 / 9052\)7.
• ISO/IEC 15026-2 Assurance Case4.
• NIST SP 800-218 (SSDF)44.
• RFC 5905 Network Time Protocol20.
• Tamarin Prover Verification16.
• eIDAS / RFC 31613.
• Audun Jøsang Subjective Logic13.
• in-toto Supply Chain Security9.
• W3C Verifiable Credentials Data Model 2.069.
• RFC 4998 Evidence Record Syntax33.

24\. Claim-to-Source Traceability Appendix#

• Subjective Logic Integration: Mapped to PAT-OAR resolution using Jøsang's metrics of belief and uncertainty13.
• Receipt Linkage: Mapped to PAT-ORU and PAT-ORF using in-toto link/layout concepts9.
• Append-only Ledger: Mapped to SCITT / RFC 9162 transparency7.
• Time-bound decay: Mapped to RFC 4998 ERS Hash-Tree Renewal35.
• Assurance Graph: Mapped to ISO 15026-2 Claims, Arguments, Evidence4.

25\. Patefacere and .uai Integration Appendix#

Recommended Integrations#

1. Recommended /docs/ path: /docs/architecture/evidence\_epistemology.md 2. Stable Report ID: PAT-ARCH-001-2026

Proposed .uai Additions:

• architecture.uai: "All suitability decisions (PAT-ORS) must be strictly point-in-time and purpose-bound. Deterministic tables must govern state transitions. A use receipt is not a command receipt."
• test-plan.uai: "Automated CI pipelines must enforce the 50 formal invariants defined in PAT-ARCH-001-2026. Graph cycle detection and schema validations are mandatory."
• coding-standards.uai: "Do not use the boolean variable is\trusted. Trust is not a programmatic property of evidence. Use is\integrity\verified, is\authenticated, or is\_current."
• taboo.uai: "Do not use the terms 'certify', 'truth', or 'proven' in variable names or API responses. Replace with 'qualified', 'integrity\_checked', and 'inspected'."
• long-term-memory.uai: "Patefacere is an evidence layer, not an execution layer. Storing a receipt proves cryptographic consumption; it does not mean the system commanded an external physical action."

Durable Memory Statements (1-25):

1. Authorization is not authenticity. 2. Authenticity is not accuracy. 3. Integrity is not truth. 4. Review is not repair. 5. Contest is not automatic invalidation. 6. Currentness is not completeness. 7. Qualification is not certification. 8. Suitability is not authority. 9. Reliance is not execution. 10. A use receipt is not a command receipt. 11. Fresh linkage is not process execution. 12. Evidence storage does not create legal effect. 13. PAT-ORS applies only to its named purpose. 14. PAT-ORS applies only at its specific evaluation time. 15. Clock rollback immediately suspends PAT-ORS generation. 16. Unresolvable contradiction yields CANNOT\DETERMINE. 17. Missing mandatory fields immediately yield REJECT. 18. Stale currentness yields REQUIRE\FRESH\EVIDENCE. 19. Replayed nonces yield REJECT. 20. A revoked PAT-OEA makes all dependents COMPROMISED. 21. Privacy exports utilize Merkle inclusion proofs. 22. PAT-OAR disputes are fused using Subjective Logic algorithms. 23. The evidence graph must strictly be a Directed Acyclic Graph (DAG). 24. A positive suitability decision never triggers physical actuation. 25. Absence of evidence evaluates safely to CANNOT\DETERMINE.

Proposed Terminology Vocabulary:

• Public Terminology: Authorization, Authenticity, Integrity, Currentness, Reproducibility, Completeness, Suitability.
• Protected Operator Terminology: PAT-OEA, PAT-OED, PAT-OAI, PAT-OAR, PAT-ORP, PAT-ORD, PAT-ORU, PAT-ORI, PAT-ORV, PAT-ORF, PAT-ORQ, PAT-ORS.
• API Outcome Vocabulary: ALLOW, REJECT, REQUIRE\FRESH\EVIDENCE, CANNOT\_DETERMINE, MALFORMED, UNCERTAIN, STALE, COMPROMISED, CONTESTED, SUPERSEDED.

Acceptance Criteria for Future Implementation:

1. Codebase correctly evaluates 100% of the 40 Adversarial Test Cases without crashing or halting unexpectedly. 2. Subjective Logic fusion calculates uncertainty within a 0.001 margin of error against standard Python reference models. 3. NTP clock drift bounds trigger the UNCERTAIN state flawlessly during rollback testing. 4. Privacy export exposes zero raw payloads while verifying perfectly against the SCITT transparency log.

List of Claims Requiring Actual Runtime Proof:

• The actual processing latency of the PAT-ORS deterministic decision engine against a DAG of depth \> 1,000 nodes.
• The exact byte overhead of appending full ISO 15026-2 argument trees into the PAT-ORQ structure at scale.
• The synchronization resilience of the trusted clock under simulated extreme network partitioning and high jitter.

Works cited#

1. ISO/IEC 27037: Understanding its role in compliance and security (2026) \- Konfirmity, https://www.konfirmity.com/glossary/iso-iec-27037 2. Digital Chain of Custody: What It Is and How It Protects Evidence \- TrueScreen, https://truescreen.io/articles/digital-chain-of-custody-guide/ 3. ISO 27037 Web Evidence Acquisition: Complete 2026 Guide for Defensible Digital Forensics \- GetProofAnchor, https://getproofanchor.com/blog/iso-27037-web-evidence-acquisition 4. Recognized Consensus Standards: Medical Devices \- FDA, https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfstandards/detail.cfm?standard\_\_identification\_no=34889 5. IEEE Standard— Adoption of ISO/IEC 15026-2:2011 Systems and Software Engineering, https://wildart.github.io/MISG5020/standards/ISO-15026-2.pdf 6. INTERNATIONAL STANDARD ISO/IEC 15026-2, https://cdn.standards.iteh.ai/samples/52926/c9bb7c21cd424f8e82e43802efc4dd3e/ISO-IEC-15026-2-2011.pdf 7. rfc9162.xml \- » RFC Editor, https://www.rfc-editor.org/rfc/rfc9162.xml 8. draft-ietf-scitt-architecture-10 \- An Architecture for Trustworthy and Transparent Digital Supply Chains \- IETF Datatracker, https://datatracker.ietf.org/doc/draft-ietf-scitt-architecture/10/ 9. in-toto-verify — in-toto 3.0.0 documentation, https://in-toto.readthedocs.io/en/latest/command-line-tools/in-toto-verify.html 10. What is GRADE? \- BMJ Best Practice, https://bestpractice.bmj.com/info/us/evidence/learn-ebm/what-is-grade/ 11. Certainty of evidence, why? \- PMC \- NIH, https://pmc.ncbi.nlm.nih.gov/articles/PMC10578932/ 12. GRADE guidelines: 3\. Rating the quality of evidence \- PubMed, https://pubmed.ncbi.nlm.nih.gov/21208779/ 13. Audun Jøsang | alphaXiv, https://www.alphaxiv.org/@audun-josang 14. Subjective logic \- Wikipedia, https://en.wikipedia.org/wiki/Subjective\_logic 15. Fission of Opinions in Subjective Logic \- UiO, https://www.mn.uio.no/ifi/english/people/aca/josang/publications/jos2009-fusion.pdf 16. AITH: A Post-Quantum Continuous Delegation Protocol for Human-AI Trust Establishment, https://arxiv.org/html/2604.07695v1 17. ISO/IEC 15026-2:2011 argument and corresponding GSN notation. \- ResearchGate, https://www.researchgate.net/figure/SO-IEC-15026-22011-argument-and-corresponding-GSN-notation\_fig1\_335241054 18. ISO 8000-61 DATA QUALITY MANAGEMENT STANDARD, TDQM COMPLIANCE, IQ PRINCIPLES \- University of Arkansas at Little Rock, https://ualr.edu/informationquality/wp-content/uploads/sites/103/2023/02/P23-ICIQ2017-ISO8000-61-DQ-Standard.pdf 19. DAQUA-MASS: An ISO 8000-61 Based Data Quality Management Methodology for Sensor Data \- ResearchGate, https://www.researchgate.net/publication/327652090\_DAQUA-MASS\_An\_ISO\_8000-61\_Based\_Data\_Quality\_Management\_Methodology\_for\_Sensor\_Data 20. Securing NTP \- APNIC Blog, https://blog.apnic.net/2026/03/10/securing-ntp/ 21. RFC 5905 \- Network Time Protocol Version 4: Protocol and Algorithms Specification, https://datatracker.ietf.org/doc/html/rfc5905 22. What do y'all use to preserve webpages for litigation? : r/Lawyertalk \- Reddit, https://www.reddit.com/r/Lawyertalk/comments/1prihc4/what\_do\_yall\_use\_to\_preserve\_webpages\_for/ 23. GetProofAnchor \- Chrome Web Store, https://chromewebstore.google.com/detail/getproofanchor/pnbphfjdieoklgdadpnmipaijeaegcch 24. draft-ietf-scitt-architecture-11, https://datatracker.ietf.org/doc/html/draft-ietf-scitt-architecture-11 25. Introduction to in-toto \- Christian Rebischke, https://shibumi.dev/posts/introduction-to-in-toto/ 26. subjective logic encodings \- arXiv, https://www.arxiv.org/pdf/2502.12225v2 27. draft-ietf-scitt-scrapi-11 \- Supply Chain Integrity, Transparency, and Trust (SCITT) Reference APIs \- IETF Datatracker, https://datatracker.ietf.org/doc/draft-ietf-scitt-scrapi/ 28. Metadata Model — in-toto 3.0.0 documentation, https://in-toto.readthedocs.io/en/latest/model.html 29. Making the cloud prove it followed your privacy wishes \- Help Net Security, https://www.helpnetsecurity.com/2026/06/11/gdpr-compliant-cloud-storage-privacy/ 30. zk-agreements: A privacy-preserving way to establish deterministic trust in confidential agreements \- arXiv, https://arxiv.org/html/2510.20007v1 31. A Multi-Factor Quantum-Resistant and Privacy-Preserving Authentication Protocol for Decentralized Systems \- Journals, https://journals.mesopotamian.press/index.php/CyberSecurity/article/download/989/967 32. open-opticon/docs/ROADMAP.md at main · NubsCarson/open, https://ithub.global.ssl.fastly.net/NubsCarson/open-opticon/blob/main/docs/ROADMAP.md 33. Improving Secure Long-Term Archival of Digitally Signed Documents \- Carmela Troncoso, http://carmelatroncoso.com/papers/Troncoso-StorageSS08.pdf 34. E-governance \- Department of Cyber Law, https://www.cyber-law.uz/subject/e-governance 35. RFC 4998 \- Evidence Record Syntax (ERS) \- IETF Datatracker, https://datatracker.ietf.org/doc/html/rfc4998 36. RFC 6283: Extensible Markup Language Evidence Record Syntax (XMLERS), https://www.rfc-editor.org/info/rfc6283/ 37. Long-term preservation of digital signatures for multiple groups of related documents | IET Information Security, https://digital-library.theiet.org/doi/abs/10.1049/iet-ifs.2011.0344 38. Facts versus Interpretations in Intelligence: \- OSF, https://osf.io/download/6451004195393f0897676321/ 39. Analysis of Competing Hypotheses using Subjective Logic \- dodccrp.org, http://www.dodccrp.org/events/10th\_ICCRTS/CD/papers/126.pdf 40. Trustless Attestation Verification with Zero-Knowledge Proofs \- TikTok for Developers, https://developers.tiktok.com/blog/verifying-trusted-execution-environments 41. Formal Verification of a Blockchain-Based Security Model for Personal Data Sharing Using the Dolev-Yao Model and ProVerif \- The Science and Information (SAI) Organization, https://thesai.org/Downloads/Volume16No9/Paper\_42-Formal\_Verification\_of\_a\_Blockchain\_Based\_Security\_Model.pdf 42. The TAMARIN Prover for the Symbolic Analysis of Security Protocols \- ResearchGate, https://www.researchgate.net/publication/289823213\_The\_TAMARIN\_Prover\_for\_the\_Symbolic\_Analysis\_of\_Security\_Protocols 43. SCITT: Supply Chain Integrity, Transparency and Trust \- Conserver.io, https://www.conserver.io/deep-dives/scitt-supply-chain-integrity-transparency-and-trust 44. NIST SP 800-218 (SSDF) \- Pivot Point Security, https://www.pivotpointsecurity.com/services/nist-sp-800-218-ssdf-consulting-services/ 45. NIST SP 800-218 (SSDF) \- Secure-by-Design Handbook, https://www.securebydesignhandbook.com/docs/standards/us/nist-sp-800-218-ssdf-overview 46. ISO 15489 | DCC \- Digital Curation Centre, https://www.dcc.ac.uk/guidance/briefing-papers/standards-watch-papers/iso-15489 47. ISO 15489: Records Management Concepts and Principles for Research Institutions, https://casrai.org/guides/iso-15489-records-management-concepts-principles 48. ISO 15489: Its Importance & Requirements | SafetyCulture, https://safetyculture.com/topics/iso-15489 49. (PDF) ISO 27037 Digital Evidence for DEFR \- ResearchGate, https://www.researchgate.net/publication/398247248\_ISO\_27037\_Digital\_Evidence\_for\_DEFR 50. ISO/IEC 27037 | ISO27001security, https://www.iso27001security.com/html/27037 51. Assessing certainty of evidence \- NHMRC, https://www.nhmrc.gov.au/guidelinesforguidelines/develop/assessing-certainty-evidence 52. GRADE home, https://www.gradeworkinggroup.org/ 53. When applying GRADE, how do we decide the target of certainty of evidence rating?, https://mentalhealth.bmj.com/content/early/2021/06/13/ebmental-2020-300170 54. Does Athento complies with ISO 15489? Detailed functional assessment, https://www.athento.com/does-athento-complies-with-iso-15489-detailed-functional-assessment/ 55. iso-tc184-sc4-boilerplate/iso-8000/sections/00-introduction.adoc at main \- GitHub, https://github.com/metanorma/iso-tc184-sc4-boilerplate/blob/main/iso-8000/sections/00-introduction.adoc 56. Three Dimensions of AI Data Quality \- Edgematics, https://edgematics.ai/knowledge-hub/three-dimensions-ai-data-quality/ 57. DC-Data Quality Management Processes, https://nhqc3s.hq.nato.int/apps/DCRA\_Report/id-29d4122b072148f5aaf4882ecc5d963c/views/id-c1b8677e67ee486796bae7354852a7a1.html 58. How To Build a Data Quality Team Using the ISO 8000-61 Framework \- WinPure, https://winpure.com/how-to-build-data-quality-team-framework/ 59. Annexe 5: Argument-based assurance cases \- ICO, https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/artificial-intelligence/explaining-decisions-made-with-artificial-intelligence/annexe-5-argument-based-assurance-cases/ 60. Building An Assurance Case And What Is Needed To Complete These Models, https://ndia.dtic.mil/wp-content/uploads/2022/electronics/Martin.pdf 61. Stay Compliant with NIST SP 800-218 and CISA Attestation Requirements \- Sonatype, https://www.sonatype.com/resources/guides/stay-compliant-nist-sp-800-218-cisa-requirements 62. NIST SSDF: Secure Development and Attestations | Xygeni, https://xygeni.io/blog/nist-ssdf-secure-development-and-attestations/ 63. Secure Software Development Framework | CSRC, https://csrc.nist.gov/projects/ssdf 64. Decentralized Identity Authentication with Auditability and Privacy \- Deakin University research repository, https://dro.deakin.edu.au/articles/journal\_contribution/Decentralized\_Identity\_Authentication\_with\_Auditability\_and\_Privacy/30511259/1/files/59241650.pdf 65. GetProofAnchor Forensic Browser — Evidence Capture, https://getproofanchor.com/forensic-browser 66. Subjective Logic \- ResearchGate, https://www.researchgate.net/publication/310494191\_Subjective\_Logic 67. Audun Jøsang A Formalism for Reasoning Under Uncertainty \- eBooks, https://content.e-bookshelf.de/media/reading/L-7822872-8782e9d792.pdf 68. in-toto and SLSA, https://slsa.dev/blog/2023/05/in-toto-and-slsa 69. Measuring the Performance of Candidate Verifiable Credential Schemes for the EU Digital Identity Wallet \- TU Delft Research Portal, https://research.tudelft.nl/files/305964502/3748522.3779904.pdf 70. Verifiable Credentials Explained | FIDES Community, https://fides.community/topics/verifiable-credentials/ 71. W3C Verifiable Credentials Specification for Galileo \- Galileo Protocol, https://www.galileoprotocol.io/specifications/identity/verifiable-credentials 72. RFC 5544 \- Syntax for Binding Documents with Time-Stamps \- IETF Datatracker, https://datatracker.ietf.org/doc/html/rfc5544

[image1]: <data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAA8AAAAaCAYAAABozQZiAAAAvklEQVR4XmNgGLnACYjvAvEjIrELRBsDAyMQTwHilUCsAOWDwBwg/gfEHlA+MxDbA/EDIDaFijGIA/EqIBaDCQCBIBCfZoAolEYS5wHixUAsAxMAOaEQLg0B+kD8CYjXADELkjjI0ElAzAsTCAViNbg0BEQD8X8gLkcTFwbiNAaE17ACkH9/A7ENugQhgMu/RAFjIP7KgOlfogAu/xIEoICYzzAk/AuK43NA/I4B4lcY/gLE1xkgBo6CUUAeAAAc6iv7Yi1TmwAAAABJRU5ErkJggg==>

[image2]: <data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAaCAYAAAC+aNwHAAAA3UlEQVR4Xu3SvwsBYRzH8WcwGPzIJFFmZZJFMSizf8J/YPRXyCglg81qwaAsyt+gWCjCYpHC++I5d1931y22+9Srrvs8zz337U6pIDJV7PG0OOPwub6ijZje4JYe7iiL+wX1ftgEEdGZiWKBNZKiMzbN8UDNXn2TwwkjhESXwEo5v52ZunrP25QFKeGGJeKiM9NRzicYG2Y4oig6M3pG45Qhuh8D7NBHRi92ip5/iixSFmHLOtfo+Vuy8Btjfs9P5BX9/TdI2yt/yeOCsfI5r04FW/X7/zesi4IE+WteEE4wNyAyaW0AAAAASUVORK5CYII=>

[image3]: <data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAA4AAAAWCAYAAADwza0nAAAAsElEQVR4XmNgGAUEgSMQnwDiCCBmRZMjCDiBOAmILwBxMhBzo0oTBiAbQTafAeIaIOZDlSYMmIHYCYgPA3E3EAujShMGjEBsDsT7gXgKEEuiShMG7EBcB8RPgFgFTQ4rQA60fAYiAg2kAKTwHAOR0QQKRVBoguLVnwESSHgByNMgz4MCwYqBCA0g4APEG4FYjwESioMYgEJMnAHiT0JYjAHJ/wZAPItI3MtARuqhHAAAUy8ZXUJCyYEAAAAASUVORK5CYII=>

[image4]: <data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAA4AAAAWCAYAAADwza0nAAAAhUlEQVR4XmNgGAW0AxxQTDJQAuLdQNwJxMJocgQBIxDrAfF2IJ4LxIqo0sQBdSBeDcUgNskAZCvI9kNAbM4AcRVJQBKIpzKQaQAo0KYD8REgVkCVwg5Atk0B4v0MRNoG8t9sIN7CAAltvBpIjhKQBpAzQM4BOQvkPKKAJxC3M5CRaoYzAAD4gBEuwZfQggAAAABJRU5ErkJggg==>

[image5]: <data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABQAAAAaCAYAAAC3g3x9AAABHElEQVR4XmNgGAXUAk5AfBeIHxGJXSDasANGIJ4CxCuBWAHKB4E5QPwPiD2gfGYgtgfiB0BsChXDCsSBeBUQiyGJCQLxaQaIZmkkcR4gXgzEMkhiGADk/EI0MX0g/gTEa4CYBUkcZNEkIOZFEsMAoUCshiYWDcT/gbgcTVwYiNMYEMFCNACF328gtkGXIAfgCj+ygTEQf2XADD+yAa7wIwuAAns+A53DD5TAvYB4ARTjTZOEwo8ViKcCcSkDxDegHJOKooIBkgbPAfE7BkjYwfAXIL7OALEEBkCZ4BUQZwBxJgMkeeF1ISEAiqj1DBCXUgWkA/FCJD4/EGsg8UkGIAPmMkC8nA3EnUAshKKCDACKDFCe5kCXGAWDFAAAZYs2pbX+z2kAAAAASUVORK5CYII=>

[image6]: <data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABUAAAAZCAYAAADe1WXtAAABIklEQVR4XmNgGAW0Ak5AfBeIHxGJXSDacANGIJ4CxCuBWAHKB4E5QPwPiD2gfGYgtgfiB0BsChXDCcSBeBUQiyGJCQLxaQaIAdJI4jxAvBiIZZDEsAKQVwrRxPSB+BMQrwFiFiRxkGWTgJgXSQwrCAViNTSxaCD+D8TlaOLCQJzGgAgikgAoPH8DsQ26BLkAV3hSBIyB+CsDZnhSBHCFJ9mAkNc5gbgEiHuBmB+IdYF4BgMkqeEEhLweCMQGQLyFAaJWAYj3ALEkkhowACWnc0D8jgHibRj+AsTXGSCaYUAViC2AeDcDxFegpJXHQES6JQRAYd0KZYsAcTaSHNlgIRAHQdmuQKyHJEc2CGaAlBWgnBXHQGbuwgY4GAjE+CgYAgAA2LY0x37puXIAAAAASUVORK5CYII=>

[image7]: <data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAC0AAAAaCAYAAAAjZdWPAAACHklEQVR4Xu2VPUiWURTHj5R9WWQFWWRGkGI1lISCWFvpYg1OQja41NJSEVa4SDRE1GKhCBEi0TdOIuiiEQRN4uQiWAiNTS5G5P/HuY/P8z7klC/c4fnDj/e+59yHe865H8esUKH/1mHxQFTnHbGqQjwUy6I254tW58RKgHH02inGxA/xW5wvdcepLvFE3BN/xeVSd3w6KD6Jo6LPPOirJTMi1F3RE8ZUmKAJPlqdNj/Lu8P/JOhH6zMiU6V4Li5kbFxALuJoxhaVLok/5pXNMyF2pFPj0F7xRpzI2emI38WMpUcmGt0WN/JGS4NeFDXBtlVcF8Oi3rzNT4p20SreiRfiUJiP6KhPxaDoEEeCvUrcFx+CHT9dmD6xoWjVnNs5UZfzIXbgq3ngJICaRKd4LYbMF6Bj/jR/3xFvPIVAzJ81T4LgF8zXJHkKdcA82W/m3y+Jk3z4L3Hhfll6bln0VMb/TKxm/IxfmlepQXyxtL1fEe/NAwHG2Bhz7G6GeQRDEdg1kj0W7AT/SmwX+82Lueki2GmxL/znSUze8uPmCfHL7syL5uDLJpeIAAm47A2MBViIBbmgU+Jixkd1W8Q180tM8MzlSeXY9IqzYly0mVefxKj+HSvTSzUiusOYLf5s6eXC/lYMmJ9XLla/eBzsJHtLNIqPwU/SzIEzVibtElvCmApuy/jQHkv9iFeC5pWMkzNLRZOq5r8pVKhQjFoDa3heTo8EyAIAAAAASUVORK5CYII=>

[image8]: <data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABkAAAAaCAYAAABCfffNAAABS0lEQVR4Xu2UTysFURiHX6G4SEpR14ailJKEjbtQspSslJ2NlS8jKymxkIWNQhYW4hNYYIuUUlhRyJ/n7b2TmTfMwSws5qmnezu/ueeczu/OEcn574zgFb7FvMXr8vcn3MKu6Ad/YQmfcdiNt+Em3uGgy35EAx7iMTa7TGnBU9zFWpcF0403uIFVLotYEXtGn/0V42LnP+uDGLrIAw74IJR5+byPiDrcw3vsd1kQ9bgvX/ehFPFM7F/YkYzCCOljFF9xG2tcFkRaHxW4ILbIpMuCSeujT+wdWcRqlwWR9n604oFY6Y2x8XZcwymcwVX5pqsesV36PnTHE2Jlr0tyAT2+ORzDExzCI7EFE5TwXD7uqhe8xAuxO+tR7L7SCXTSOLqZTrEOl7ESm8qfmaIL6wLTPsgS7U+77PVBlujkO5LsKnP0/At+MCdH3gHICEKML7btBQAAAABJRU5ErkJggg==>

[image9]: <data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAE8AAAAaCAYAAAD2dwHCAAACiElEQVR4Xu2YS6hOURiGX6Fcc0kOUSKXlEKcY4JSUgYuoVwHMmGizJSRkokykVJSBwMZmCikKGKimBhgipRSmKCQy/v6zqr1f/6991rC2bKeevpPa+39r3+9e+9vr3WAQqFQ+H9ZRV/Sb5Fv6KuBvz/RK3RuOKGljKS76XjXXofO2UFP02N0Xmd3OmfoZ7rctU+nl+lb2uf6BpuJdCs9C/t9z+jU+IAaxtEb9AgdQxfRx3RzfFAKY+ld+ohOcn2ihz6h12FXqy0ovA10Kb2IvPAO0vt0QtS2EzZPzTeZ+fQ1vUSHub7AOdgxOraN6PelhqfAFJzOieml7+h6116LDlZ92+s7IjTQB9gAbSQnvHCz+PCW0Pf0qGuv5QS617vAaHoT9sUaoI3khBdCqgrPt1eiYnkb1fVOTKNPYW/lWZ1dyWynzzN8QGf/ODONnPDWwZ40H1J2eCn1bjX9Sq/SEa6vLeSEtxa/KbymejeEnoSFt8n1tYmc8KpCqmqvpKneLYatobSQHO76ctAdq4mlquVCzng54an0qAT5kEJ4h1x7V5rWd1PoHdjLQovKwEx6gW6je+h5NNfCGXRLhlq/aR2XSl14uggaP1yMUOd9GVJ50o5Kn40sgN1Vvt5pkI2wl4QWn3Fweoz30zWwFfky+hAW5GCi8F7AdkSe47DSdDhq2wV7MelGEJqXdhv30Dnfn1gBu0phL/sFNrC+THvaj7D9rILRl8Yo5DmwGtlPh8IWnfr820yGPTla2Pq57IuOOwC7o+Ktl26QU/QW7EZRcHoCtU37oyhQBaftzL+M5qF/eKhMrERejf1lVB91xRf6jkIzCu0aGmpDoTuqb6N8Y6FQKBQKhQG+A6/ImeFrql/5AAAAAElFTkSuQmCC>

[image10]: <data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAE8AAAAaCAYAAAD2dwHCAAAC1UlEQVR4Xu2YS8hNURiG3z+U+y25RIlCSiG3CYpQBi6hCAOZMBFloCQpmSgTKSXlMpCBiUKKIiZKCYUpUkphgkIu79t3Vq3zOft69omynnraf2vty9nv3uvba/1AIpFI/L8so2/pr8gP9F3r72/0Gp0eDvhHGUR30JGuPQ8ds5WeocfpjPbu8pyl3+li1z6JXqUf6ULX97cZTTfT87Df94pOiHfIYQS9RY/SoXQOfU43xjuVYRi9T5/RMa5PjKMv6E3Y06pDH+w62jaFwltH59PLqBbeAfqQjoratsHuU/dbmpn0Pb1C+7u+wAXYPtq3DjrvPnqHLqf92ru7Rr+vbHgKTMHpmJgF9BNd69pz0c6qb7t8R4Qu9AV2gW4YQvfSR3QLHdDeXZsq4YWXxYc3j36mx1x7LifRud4FdMO3YSfWBZpAw38nfdza1i0HgSrhhZCywvPtmahY3kV2vRMT6UvYV3lqe1fX6M3TG/iUHqLD27tLUyW8NbCR5kOqHF6ZereC/qTX6UDX1xSqgSr+qkWHUT3EKuGtRkPhFdW7PnoKFt4G19c0CnAlbBTsd31FVAkvK6Ss9kyK6t1c2BxKE8mmirsnvHUPUH/oVglPpUclyIcUwjvo2jtSNL8bT+/BPhaaVAam0EuwWqVifxH1amGodwpNX2B9mOqSF56uM7m1FaHO+zKk8qQVlbaFzIK9Vb7e6SLrYR8JTT7j4DSM99BVsBn5IvoEFkJZejFdUXhvYCsizwlYaToStW2nr2EvgtB9abWhBxnf7x8sgT2lsJb9AbuwTqY17VfYelbB6KQxCnkarEaegw05TTrLTHo1HDUs9QM1TMsck8dY2MjRxNbfy+5oP03O9UbFSy89sNOwSbteFAWnEahlWk9RoApOy5myqESovvZidVEX3Yf+4bGJLkUzI6AQ1Uc98dm+I1GMQruBgtqQ6IyG3WDfmEgkEolEosVvSd+awzNcWw8AAAAASUVORK5CYII=>

[image11]: <data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAMwAAAAaCAYAAAD7RbPAAAAG+UlEQVR4Xu2aeYgcRRSHf+KBJ963IpGIqPEA7wsRVBQP1IgKHlkUNYgieESjaFZF8MD7iHgQE4n3BZ6omBVFREH8w4ugEEUUBRUE/1E83mdNZWpqenqqe3pnpkl/8GN3q2Z6u6ree/VedUsNDQ0NDQ3DZH3T2nHjKsSapg3jxoaGLPYyLdKqbTA4zF2mk+OOhko53XRM3FgntjMtM+0WtG1hesf0XaLucF8bCeuYHlf3PfXSU6b1/v9mN5uaXjPtF3cMkc1M75r+Nv3b0p+m74O2z0yzTau1vlMXZpp+MF0dd9QFJpyoOhm1H2360nSYXOQFogKLdZ/aC7WNnGONcgJmmZabTlM7pdzT9LvpDTmHAnbPR01LlW9ojP1NuRR1lPj5vilqZzxXmf4yzVP+WKpga7k1f8W0UdRXhDVMj8iNaXHUVxswtq9aPz0sADvGkUEbsHAM9oSo/UqNNo250DQ3ajtD7l65t5Dj1d+5cawP5FKHUcJ9/mM6Iu6QWyOM+Dd1rl2VzJALMK+b9tDgjok9sTPi6M/JOVDtwKBeVWexT0qwUJ0RlhTmbdOPph2Ddphv2jdqGxbc9/2mbaN2IhkLc0jUjiOlODfBIXVRt1d7F86CuSPVKwLjYl2y5tuD8xMULog7BgCnwDlwEsa/c2d3abClp+Wc5lvTVKutVvhFiSPurqYTozYWjcWbUvdAz5OreUYBKeEcdUa/jU0fm1ao25EY1y5RWxakQyws9V0/zpRLa7OcZivTiypeE3HfK9QdzEK8w8TrVwbmb3+5WpadiyBQJWQAV8ild8wr68M61Qp/80x8P3rl0+OIr19Sd4gs9pYrslN2ToztItO96nSass4CpGGkY3nzfamy084irG461vSe6TYV3wlTwPmoG7k2wXZKzu6wv1qBUfyk7rQli171yzjSq34pQpFgArHTDOIswL33ql+A/7dIbpyMtyxEfU6tyt5nP7jPW9S2G+8weanm2ILDcMzKzzymY5CkGRhliohMqQWnN6Ss+qUI3mGKGKN3mmdML6u8EabUL9SZn5t+UVqKmccMVVvch5DmPaz2zsuOz87/h/rb3diR6jB59UtZSPEeStTNSj/OzKtfiuAdhrSnCKQfn5qWKLumSSGlfuHomx2Iw42yaWcMY6Z+oY7B0Ad1HI6/CRzsgrHyds+xJdVh2E7rUr8wFqLXIPULFE3JgAMCnvtgbBPqrmlS6Ve/ELR4TrTctEPUVwXs6NQz1DXUN9Q5ZeC52HXqdjzSTeypyNyOBewc5K/9XlPoV79QZBNRj5IzUiaJiR4FKfULznCN3IO4OepeUEidG493Fp+Gcc0JlXOavOcvXGvS9Ks6U77NTXebLpE7Nn/CdGDQXwaOw7neJ3LPpIqMg/kgNc06PfUOE+7epIXc8ymmg+WOoDl5ZLedL5cuzlZ7rXBi/n7BdJbpILUD5E5yO+/tpuNMz5pOavUNhM+D887x+9UvTAjHqtz8YrkBMcA8g50uUuqXfeReOyEy8/kbTVt2fMLB6dg3SqsPMA6cj2uHlHEa0hgcL55vrsVxP2na13Lv/oWwBoeavpALXBw4TIYfGADu6RzTS6ZNor4scDRqogVxR4tT1RnUGNvFcvfN2LyjY084Cg+ScQJ2PNYKx+DZG/Ui3yXA+IyCtfBBkP9Pinm98tPbZLyB3RO1c+HH5CKszzkR7zFx1HrZyk+6CeREiOv4AhljY/DD4gZ1vmflxf0zsT6l8MU0kY+IydsMGIKPWiGMZUppNdu16nYWD9cmamIkeZAGvSX3zpi//5/lUmbGRjtPyc9W+1WfEAwqfKUHI0t10qpgfnmnL1yDO4P+3eXSyLCf8eHo3D+BGztizhgD7/T5wMdP/qYdh/pI7UCH/frdigCOTXIv1E9kRXwnZR2TwHD454M8RGLbxPt9RMRAUiLzsCEVIwIfHndEEKmeVHURelgQsXvVPeOOD94+6GJL2JQ/uJlsCRjnUmU7lie2ycogsr0vF53KQqFNSrKB3ADO1WAF93RBCspYw0MO3tCOo89M04etn3XBR9TUmsszXcf7RSFgs8P6tWFnYDzcH31TcnUKqdsCtdO5WXJrxa5D8Kd2pn6hduGlYGySz/Tb4QvBzVEYZW31KbD9P6/2YKp+raJKKIgXyk0uRSEGFhoBv5Pzzovaxx3Sk2VyxXMRihzvs7ZxcKkKDo7YKbAlmFTbKWgjIFNv4hCkdtQsc00Pyr3jeKtcVjPRantAzgHPlzvg8detBAyDJ76orJHwPSJB2SPIYULU6hUtyadZjEoneAgwFortuoLdrBv8Tf0V2hJ/h+Ojj93D960V9NFOf/iZyuGfXm46IO5YhSDvpQaom7M0NDQ0NDQ0NDQ0NDQ0NKzkP16Ta/rimxvaAAAAAElFTkSuQmCC>

[image12]: <data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAoAAAAbCAYAAABFuB6DAAAA/ElEQVR4Xu3RMUuCQRzH8X+gkBQoOFTQUkMQtIWbrW5ODQm+hZx7Hy1BBE3R0hoELm5BtPQCGgxBHNzSoUH9/p6707tnCxoa/MEHz//zv3vunjP7V9nAERrYyj1bpoQb3KGDV+wnHaSIW9z78SaecRU3KRcY4cT/1xYePI2zVPGGRxR8bRs9T+MsLcz8b8ge+hatqBW00hCHqz6rYYrrUNjBJ37wFfnGHO3QeIqJRTPNveUJYxyHYtNyM8kBBpYe7neN2rQ2H6LTq3YW1axu7kNrr4qu8cXcVS5XU3Tqd3MT9L0u0UU5bgo5x4e5k+p+d9PHaXRNlXxxnb/NAniLLenUuJJVAAAAAElFTkSuQmCC>

[image13]: <data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABEAAAAZCAYAAADXPsWXAAAA4ElEQVR4Xu2SrQoCQRSFj1EQDIImg2DTt7CYTYJmMdhtgi/gk4gIIhg3ilmwGy12g3oO4+LOzK67m90PvrBzZ++c+QH+hhKd0J5byEOX3umZ1p1aJpRiRZ/0Rad2ORsduqMjmEYnWrNmpBCmGNMyPcCk0Xdm2nSD78p9mDRHWg0n/UIplrBXrdAAJs0wMp5Ii67h73+AHGkWiL8J/agGaqSGiSjFHslvQlvRlgKYLcYypzN3MEI0jQ7bo0m3tOEWHHTgSqNr1/VbKMGDXlO8wTTx0mj1y6eYR71oL01BQRJv9m86KBUoHx0AAAAASUVORK5CYII=>

[image14]: <data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAH8AAAAaCAYAAACehIP6AAAEHklEQVR4Xu2ZWahNURjHP3HLPGS4hAyF1DUlmSlTPFCmiPKg8GDKUF48GEuGSEhmyax4MBTKlRelPChRKHnxRoknhf+/tVd37XXOPnvtvddxzzl3/+rfvftb+969v/Wt9X1rrS2Sk5OTk5OT05KYAX2CvjhqlvqzmmG1FPoYpTfQCPVn1U8r6AR0ExoYXJNz0B9obnDdGpoOfYbGBbZaoB30EDoE1Qe2DtBT6DvUENjqoBXQB6hfYKt66PAtqJdh6wa9EhXovoa9I3RFqsd5BoyBLAWDe1HUINAMhr5CjaJ81vSBrkKdDFtVwxS+xbKNgn5Ad6A2hp2D4rhUvvOdoZ3QS2iS1WazBlpg2eZBf6H9lp2D4og0ZceqZyk01LKtFOX8DsveHVorles8ZyZL2DNRQWepKgUHNoNPv0wYdPpvDwr202LLVnOw3v+GptgNFcog6Dz0CBop2QanrvdM+5zpLYqoeu8KZ9tCCa8hisH7lkO97YYEDINuB+LvPoiq9664+u+DIdB8yTbYQ4yFfklhvXeF2ya+kAtMtwehLnZDCegoZzdnOWc7Z71PmOqL1XtXkvifBPrNXdYcy74MWmTZUhNV711gIFgyzJVzHHz5dbaxBJxRrOmXRNV430TVexfS+O8Ct5j3obdSGBdOHD4zc6bh6OK2J2293yBq8CSBafa6JEux5uy/LP5SPt+hUdLX+zT+J4G+2sEneyXdYA0RV+85oreL2u5wxPGk67SoTmOJuCDhAyDOhGvQEmiyqIOkYxJO81xg3YCGG7YkMPAsUT4We3H1vhz+JyEq+Nya8v9mIq7ecyEzWlQK4r0DRa2MmX6596ej+gCIQdgoqkZ9hCYGdjpg10SmraxHxuY2b7ykGwRx9b5c/rsSFXy+C5/d1m6Ig3vX19A3UY5r/YTeifrHGq4uJ0BPRGUJOrhJlOPsgMbgJ+Hg4f2s5ywlvJcz5LEUBjpLh9hwEcmj2heivlnE7fWnivquQX9N/9kfPCQyTzN9+89sdwo6E6FpwX2aUsG/J8WzlVf4cD0zekDrjd8fSHgRRofpuK6DDdBzUfea+Ay+huVks3hcCQeUw39Xmj34fAHdobNF1VnCB98VdTSs4ezgLNHZQ3fcTGka1cVqZSXj2/8kRAWfi/Ozkq7UJYLHm/wQxGPeVRJ+4GEJp3R2BL+Y6QXONuioqBlZF9jYQVwI1QfXlY5v/13gOoNnGlyMvocOQF2NdmaWrcZ1WeHColiK4effXcY1621745owHZsdxoUQD3rKPmo94tP/rDBznpSmT8/NBrdC3HL0txsiYCfsgcbYDVVKUv99wKDvk+K7s//OAFF1ySWtcZHH8/1aIon/WWE52Q31tBuaE6a2OOc567lF8pkCKwUX/33A8pN4b5+Tk9OS+QfWKtTMtmxVVwAAAABJRU5ErkJggg==>

[image15]: <data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAH8AAAAaCAYAAACehIP6AAAFOElEQVR4Xu2Za8hlUxjH/3LJNXeS62gimfJBY5LLKEYkd7lEviDCB4NmwqhXkgi5FblGSeID5ZJLOqWYIpPCyKWQiJIocsnl+c2zV3udNWufs9ec433PnHf/6985Z629115rPc/zf561j9ShQ4cOk45NjTsaN0k75iHm1V5sbrzFeEbSzuJ3Nu6QtI8KNnc347Zpx4SAdV9jXF59n2qw0LvUv9AbjX8a/5U7xjiwtfFZ+ZjwxP7uiQIB8aTxzLRjmnCw8V3jgrTDcJzxb+MpaceIuN74nXH/tGPCsMj4jnHvtGMaQKTfXzEnbys1fiNtZnzO2NPkyn4Ac33aOJO0TwX2NH4qj/AUWxpf0viNxDO/NN6btE8qzpcrIwVgMYio/eQ5JIdtjMdWn7MNjP6Fca+0Q7WRbjUeYDzNuEd8QQG2Nx5vPNS41PiHylIJe3e08RD1KxTfMQoFZCm45yD5vAbtPc/8yrg47WiDZcZX1Rw9N8iLn0vTjlkAst5Tfm44xj/yhd9svEyuEumJYBAw2ip55BBBjxi/Nf4o3/g2wHGeMl5r/Nh4UdR3jPEn4+FRWxvgzKvljn2hfA+Y19XRNQE4PHtQsu512Mr4jHFJ2hEBz/pB+QcHLDS+Z/y6gOetu3MwnpDnX3JbChyDYi+udrm+p7yzpCAqVxg/kysf4Nj4vtqPAQgKHAd1+kb9+ZdTCMq1e9Q2DPvKnfg61SrC+ARgTo2YZ0++H0XAI+9Rvbk8jAelD3lcc3PswZgwRVNRxrVEQRv5Z+3I+0zUVprvmQdHTp53rvE31VGOVL+hZufNgetQH5xoQdRO4DWpUTB+8XH3SvUXU3gonhoPxITu03gr6rZoMn7OSORW5LttpHHvX8Yjoza+l+Z7wB5RdSPVpAHAfnESKYlIjIuRY4dpcvSAYHycpggYlSIngO/kljhHIekPyavrJoQ3YkRAW+YWkqLJ+MzzV/XnubBxGGFYpIUN+8i4S9SOoZoibBCCM8ZBQ1DxEioOrmE4WevXVyEgm9Rog2UfOY+9/Bx59Oxa/aYgelAuaYOAxJ1kPKuAbTaYzUQ602oX41M3xI6LihG1R1W/g0PmnDZsWDx2iLC3jDsZbzfuU/Xx+njQK+TgjBgvgLkj39QCVxiPqNrZU+aVO10F48cpFjVCoXB0gpJXujGC4g2qybLAm5AmbnzY+Lu8gn5TPuE1xtfULkr/DxABaXQC8uEnqiWbImmtvIALRRJVNxuZUwKu4cVRT/XaKBwpIFEaxsfpcZwDjd9r/Twcg6L4F9VKFIq2ntzQd6tew53yec1Uv2MskitPCEhSCA6KY+FgnLxSJcG5UIa0fSgOkx9FmMzP8ujlPXp4t/228mfs2QILphpPVQLjXS4/YTwqNzyRH5+niSKcmY0hzaRgXUQ50f68/Fi1yvi58UX53oTrPpAHRRzZMYjiB+TzYD44XCjSCKSL60t1lXwsjJoGFetiHTyPcV43nm78UH4cx3FSxSAACBBSTzHwbvJKPCgSx7EnRNFcAc+niOIEkkNu7jHop65pKgBz/96x9tQo4BINP/FwL+MFJ2ScXLpABZhXms4CuC8eh/VxT+5l0Yzy6jYVuMD4svydRCmQ6Ts0+sZwP+M0yX4pyN2kqFFBgKIsoc6ZOhAFyPCytGMIiBIMVnpfDicYb9N4lJD1PCb/t3JUEBjUJk3KNxWggHqh+mwL8vypGt1gRP3Zqs/vo4L6ZWnauAFYaHxFZXuy0YJNu8m4RdoxD7Gd/Cg5l8V4hw4dOnTo0GEjwH/MQPjq470nkwAAAABJRU5ErkJggg==>

[image16]: <data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAkAAAAaCAYAAABl03YlAAAA00lEQVR4Xu3RvQtBURjH8SOUwUAGySAGZbaymSX+CcnMZJLsdoPJYrXb2UkpLCajgfLyfa5zcu6ZbBa/+nTvPc/TfZ7uVepnCSCBmFsw6eGGJwZOzZcK7qi6BTtdnJBzCyYRzLFA1F/6JI09hsijhpTdIJF9Hjigjya2qNtNso8s3bDOJsoaH8LMPtCRJnmzN9bsM7Ia4lhih6QcFHFR/vkFnDFV70le01FfTdq4omwOstigpJ8zWKOj3v/Ti9y0sMJYN8ibgqbBjnx1WTLsFv75Li9k8SOwWiXhbwAAAABJRU5ErkJggg==>

[image17]: <data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAsAAAAZCAYAAADnstS2AAAA3UlEQVR4Xu3SsQtBURTH8StMlEUsSkZlMymLshgo/gKTyWKSzDJZ7GaLf0AM/gTKZLYaDRj4Hvfduu+6s1J+9Yl3z33XOc9T6meSRAZRt2Cnhhue2CIRLn8mhzMmbsGXqtKnt9yCL0NcUHQLEhlCCk1kscJO6SFDkU17TNELvt8xtzdJ8jhhhEiw1lX6SYT6jWGp9NQFa93br1zIovQnN0rk09uvDCM/17DW5JE90EEFA1MoKX2y6S2l9D92RRlj1IPae6A+DlhggzaOWGOGuNls4r4wsiFtXf/zpbwAH9wkzOofuXsAAAAASUVORK5CYII=>

[image18]: <data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAwAAAAaCAYAAACD+r1hAAAA1klEQVR4Xu3RvwqBURjH8Ucog5IMkskkk0EGZbW4AsUus0HJYDEqF0BmJVcgidE1GJSSwWIw+z7O8TpvMjP41afe5zmn8+8V+eeXEkQBZfvtJoaw29BihC42GDpjWZxRc3pSQU/MSlvM5LVLHVfkbf1IyzZKuIl/tTF2iDs9L30ckbG1TtLJUwRsz0sUa8wRsr0cLmja2pcUDug4PT2/HrGIKhrOmCSxF/NSGn2ApZhF0mKOqzt60TO2xdxhgoWYxzhhhYGd8xa9i+72/FERJOTD5H++lztX5x6Sgu2l6AAAAABJRU5ErkJggg==>

[image19]: <data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAsAAAAaCAYAAABhJqYYAAAAyElEQVR4Xu3RPwtBURjH8UeYKIsYZVHKZlJGKQPFqqwWC5u8AJPFzDvwBsRwR6syKZtsRpOB73POPTq8ABa/+nQ7v/PcP6cr8s8vEkURdSQ+9t5SwA5T9BDggpE3Y5LDEWNEwq6LB1puSBPDAmfkvV6feBX7Wa/oQsuV2Bs1etV1gGTYmTTFvq7vdVmcMPc6Ezfc8Loq7uiggqHbKIn9DHeQFLa4oYwJauGeOf0AeyyxQRsHrDFD3A276EEyYn+MRgfS3vqfL+UJVZseVC2CkTYAAAAASUVORK5CYII=>

[image20]: <data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAHcAAAAaCAYAAACNU8MOAAADaElEQVR4Xu2YW6hNQRjHP6GIco1EOSSllAdJjktHvHgg95SSIsR5QCJJlOSJ8KKU5EEUr8ot7UfFAyWk5JLLE0pRjlz+f7On/e2x9tozs7TXbptf/TunNbP2Wvv7z3zfN1skkUgkEm1KP2gUNNwdKJmh0BiovzuQ8OMg1Af9go46Y2WxEPom5p1uQ0Pqh/87uLjXQl3OdS8WQz+gZe5AiUyA3kj7LLhWMxhaCp2C3kJfoJl1MzzZB72HJrsDAeyElrgXCzBPzO4NWXBjobPSGTud5jKePdAhiTR3EHQNqoipcbFwgXCl/Sv4eR+gae5ADuOgC1Lse7QjjEWUueOhl9AxaCq0XEyQQilqLusKjeRncAdelfAFV8TcgdACaIaYBtPC/0dIuU1dtLmstz+hV9ARaBv0DFqpJ3lQxFya+kDMAttS/Z9N3mk9yYNYc4dBF6E90GNokxrrgT5Bc9S1VhNtLm9kM7VKXWOAKhIWpFhzJ4pZTPultmM2iumUQ+otiTV3K7Reak3cYTXGhu65mGzSiJHQdeh1gHhK8SXK3AGSnf4YIO7krPTM9MUvyjEt7voNGdfzzql8/iUxAZ2krvvUW57J3WcxpV6BpmSMNTKc78BAc8466KvUdikbMx7FGCPOK4soc2291emP9eWeNF6t3WI6Ulf3oZsZ19nKd/HGDGgeTdTBa7TgNAz6Afn7WUytL6DzGWM61WZhF9pdMWma8PTAUwSDWyZR5nIyb9L11QacXzRktcakZc5n+mVatGQtOF+4+2LSMrHP1edq9iN91b95sJzwFz43W+Qp5NfAaHOZ//VNvWLOl/PVNR+KmKvPxzzffhez4Jged6mxZhQx1y50/R1oNEsGa/EOaK4a07BULYJWB2j2nzv9iDKXde6pmIASNjdPoL1SfxzwIcbc6WKyhG2cmA5Z4+wXYepttms0Rcxlvf4stSxmG72KmL7hJDS6OtZqGFv2ArPcgTxo4HYx9fKcGGO5cxs1QHnEmMvn83kPxTz/FrQCegTdgI6L2RW+FDGXzzkjJgZ8F5al3WIW3x1oc21qS2BfcRn6KCa7Wb2DTqh5TeGvVGyeQgLpEmOuhWborprvwV0SusiKmGthLdTvws8KqY8dSbfkH11aAY1YI2GNYCKRSCQSiUQikUgkOoPfLfa4lbMQVwUAAAAASUVORK5CYII=>

[image21]: <data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABUAAAAYCAYAAAAVibZIAAAAdklEQVR4XmNgGAWjYMABBxCnATEPugQlgBGIW4HYGF2CUgAysBeIWdAlKAEg1xYAcRyUjRUIALEkiVgOiOcD8WQg5mOgEjAB4tVALIMuQS4QBuLFQCyPLkEJyALiCHRBSgAonU4FYml0CUoAKLZ5ofQoGAX0AAA5bAi7Yfn2hgAAAABJRU5ErkJggg==>