From 1385ec8af185c1848bfb1124f8e60fe2a3dbdda8 Mon Sep 17 00:00:00 2001
From: Christian Nennemann <christian@nennemann.de>
Date: Wed, 25 Feb 2026 20:30:07 +0100
Subject: [PATCH] Slim down draft to core ECT mechanism for -00 submission

Remove all companion draft (ect-pol) references, regulatory
compliance mappings, pre-defined extension keys, witness concept,
pseudocode blocks, implementation guidance appendix, and redundant
examples. Keep only the core token format, DAG validation,
verification procedure, and one cross-organization use case.
Draft reduced from ~40 pages to 27 pages.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
---
 draft-nennemann-wimse-ect-00.html | 1142 ++------------------
 draft-nennemann-wimse-ect-00.md   |  806 +-------------
 draft-nennemann-wimse-ect-00.txt  | 1526 ++++++---------------------
 draft-nennemann-wimse-ect-00.xml  | 1641 +++++++----------------------
 4 files changed, 821 insertions(+), 4294 deletions(-)

diff --git a/draft-nennemann-wimse-ect-00.html b/draft-nennemann-wimse-ect-00.html
index 8fb5c09..3272aaf 100644
--- a/draft-nennemann-wimse-ect-00.html
+++ b/draft-nennemann-wimse-ect-00.html
@@ -9,31 +9,23 @@
 <meta content="
        This document defines Execution Context Tokens (ECTs), an extension
 to the Workload Identity in Multi System Environments (WIMSE)
-architecture for distributed agentic workflows in regulated
-environments.  ECTs provide signed, structured records of task
-execution order and compliance state across agent-to-agent
-communication.  By extending WIMSE Workload Identity
+architecture for distributed agentic workflows.  ECTs provide
+signed, structured records of task execution order across
+agent-to-agent communication.  By extending WIMSE Workload Identity
 Tokens with execution context claims in JSON Web Token (JWT)
-format, this specification enables regulated systems to maintain
-structured audit trails that support compliance verification.
-ECTs use a directed acyclic graph (DAG) structure to represent task
-dependencies and integrate with WIMSE Workload Identity Tokens (WIT)
-using the same signing model and cryptographic primitives.
-Policy evaluation and compensation extensions are defined in
- .  A new
-HTTP header field,
+format, this specification enables systems to maintain structured
+audit trails of agent execution.  ECTs use a directed acyclic
+graph (DAG) structure to represent task dependencies and integrate
+with WIMSE Workload Identity Tokens (WIT) using the same signing
+model and cryptographic primitives.  A new HTTP header field,
 Execution-Context, is defined for transporting ECTs alongside
-existing WIMSE headers.  ECTs are a technical building block that
-supports, but does not by itself constitute, compliance with
-regulatory frameworks. 
+existing WIMSE headers. 
     " name="description">
 <meta content="xml2rfc 3.31.0" name="generator">
 <meta content="execution context" name="keyword">
 <meta content="workload identity" name="keyword">
 <meta content="agentic workflows" name="keyword">
 <meta content="audit trail" name="keyword">
-<meta content="compliance" name="keyword">
-<meta content="regulated systems" name="keyword">
 <meta content="draft-nennemann-wimse-ect-00" name="ietf.draft">
 <!-- Generator version information:
   xml2rfc 3.31.0
@@ -1275,23 +1267,17 @@ li > p:last-of-type:only-child {
       <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
 <p id="section-abstract-1">This document defines Execution Context Tokens (ECTs), an extension
 to the Workload Identity in Multi System Environments (WIMSE)
-architecture for distributed agentic workflows in regulated
-environments.  ECTs provide signed, structured records of task
-execution order and compliance state across agent-to-agent
-communication.  By extending WIMSE Workload Identity
+architecture for distributed agentic workflows.  ECTs provide
+signed, structured records of task execution order across
+agent-to-agent communication.  By extending WIMSE Workload Identity
 Tokens with execution context claims in JSON Web Token (JWT)
-format, this specification enables regulated systems to maintain
-structured audit trails that support compliance verification.
-ECTs use a directed acyclic graph (DAG) structure to represent task
-dependencies and integrate with WIMSE Workload Identity Tokens (WIT)
-using the same signing model and cryptographic primitives.
-Policy evaluation and compensation extensions are defined in
-<span>[<a href="#I-D.nennemann-wimse-ect-pol" class="cite xref">I-D.nennemann-wimse-ect-pol</a>]</span>.  A new
-HTTP header field,
+format, this specification enables systems to maintain structured
+audit trails of agent execution.  ECTs use a directed acyclic
+graph (DAG) structure to represent task dependencies and integrate
+with WIMSE Workload Identity Tokens (WIT) using the same signing
+model and cryptographic primitives.  A new HTTP header field,
 Execution-Context, is defined for transporting ECTs alongside
-existing WIMSE headers.  ECTs are a technical building block that
-supports, but does not by itself constitute, compliance with
-regulatory frameworks.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
+existing WIMSE headers.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
 </section>
 <div id="status-of-memo">
 <section id="section-boilerplate.1">
@@ -1352,9 +1338,6 @@ regulatory frameworks.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
 </li>
               <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1.2.3">
                 <p id="section-toc.1-1.1.2.3.1" class="keepWithNext"><a href="#section-1.3" class="auto internal xref">1.3</a>.  <a href="#name-scope-and-applicability" class="internal xref">Scope and Applicability</a></p>
-</li>
-              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1.2.4">
-                <p id="section-toc.1-1.1.2.4.1"><a href="#section-1.4" class="auto internal xref">1.4</a>.  <a href="#name-relationship-to-regulatory-" class="internal xref">Relationship to Regulatory Compliance</a></p>
 </li>
             </ul>
 </li>
@@ -1394,10 +1377,7 @@ regulatory frameworks.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
                     <p id="section-toc.1-1.4.2.2.2.3.1"><a href="#section-4.2.3" class="auto internal xref">4.2.3</a>.  <a href="#name-data-integrity" class="internal xref">Data Integrity</a></p>
 </li>
                   <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.2.2.4">
-                    <p id="section-toc.1-1.4.2.2.2.4.1"><a href="#section-4.2.4" class="auto internal xref">4.2.4</a>.  <a href="#name-compensation-and-rollback" class="internal xref">Compensation and Rollback</a></p>
-</li>
-                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.2.2.5">
-                    <p id="section-toc.1-1.4.2.2.2.5.1"><a href="#section-4.2.5" class="auto internal xref">4.2.5</a>.  <a href="#name-extensions" class="internal xref">Extensions</a></p>
+                    <p id="section-toc.1-1.4.2.2.2.4.1"><a href="#section-4.2.4" class="auto internal xref">4.2.4</a>.  <a href="#name-extensions" class="internal xref">Extensions</a></p>
 </li>
                 </ul>
 </li>
@@ -1422,9 +1402,6 @@ regulatory frameworks.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
 </li>
               <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.2">
                 <p id="section-toc.1-1.6.2.2.1"><a href="#section-6.2" class="auto internal xref">6.2</a>.  <a href="#name-validation-rules" class="internal xref">Validation Rules</a></p>
-</li>
-              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.3">
-                <p id="section-toc.1-1.6.2.3.1"><a href="#section-6.3" class="auto internal xref">6.3</a>.  <a href="#name-dag-validation-algorithm" class="internal xref">DAG Validation Algorithm</a></p>
 </li>
             </ul>
 </li>
@@ -1433,9 +1410,6 @@ regulatory frameworks.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
 <ul class="compact toc ulBare ulEmpty">
 <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.1">
                 <p id="section-toc.1-1.7.2.1.1"><a href="#section-7.1" class="auto internal xref">7.1</a>.  <a href="#name-verification-procedure" class="internal xref">Verification Procedure</a></p>
-</li>
-              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.2">
-                <p id="section-toc.1-1.7.2.2.1"><a href="#section-7.2" class="auto internal xref">7.2</a>.  <a href="#name-verification-pseudocode" class="internal xref">Verification Pseudocode</a></p>
 </li>
             </ul>
 </li>
@@ -1491,9 +1465,6 @@ regulatory frameworks.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
 </li>
               <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10.2.3">
                 <p id="section-toc.1-1.10.2.3.1"><a href="#section-10.3" class="auto internal xref">10.3</a>.  <a href="#name-storage-and-access-control" class="internal xref">Storage and Access Control</a></p>
-</li>
-              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10.2.4">
-                <p id="section-toc.1-1.10.2.4.1"><a href="#section-10.4" class="auto internal xref">10.4</a>.  <a href="#name-regulatory-access" class="internal xref">Regulatory Access</a></p>
 </li>
             </ul>
 </li>
@@ -1526,21 +1497,7 @@ regulatory frameworks.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
             <p id="section-toc.1-1.13.1"><a href="#appendix-A" class="auto internal xref"></a><a href="#name-use-cases" class="internal xref">Use Cases</a></p>
 <ul class="compact toc ulBare ulEmpty">
 <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.13.2.1">
-                <p id="section-toc.1-1.13.2.1.1"><a href="#appendix-A.1" class="auto internal xref"></a><a href="#name-medical-device-sdlc-workflo" class="internal xref">Medical Device SDLC Workflow</a></p>
-<ul class="compact toc ulBare ulEmpty">
-<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.13.2.1.2.1">
-                    <p id="section-toc.1-1.13.2.1.2.1.1"><a href="#appendix-A.1.1" class="auto internal xref"></a><a href="#name-fda-audit-with-dag-reconstr" class="internal xref">FDA Audit with DAG Reconstruction</a></p>
-</li>
-                </ul>
-</li>
-              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.13.2.2">
-                <p id="section-toc.1-1.13.2.2.1"><a href="#appendix-A.2" class="auto internal xref"></a><a href="#name-cross-organization-financia" class="internal xref">Cross-Organization Financial Trading</a></p>
-</li>
-              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.13.2.3">
-                <p id="section-toc.1-1.13.2.3.1"><a href="#appendix-A.3" class="auto internal xref"></a><a href="#name-compensation-and-rollback-2" class="internal xref">Compensation and Rollback</a></p>
-</li>
-              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.13.2.4">
-                <p id="section-toc.1-1.13.2.4.1"><a href="#appendix-A.4" class="auto internal xref"></a><a href="#name-autonomous-logistics-coordi" class="internal xref">Autonomous Logistics Coordination</a></p>
+                <p id="section-toc.1-1.13.2.1.1"><a href="#appendix-A.1" class="auto internal xref"></a><a href="#name-cross-organization-financia" class="internal xref">Cross-Organization Financial Trading</a></p>
 </li>
             </ul>
 </li>
@@ -1560,55 +1517,15 @@ regulatory frameworks.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
                 <p id="section-toc.1-1.14.2.4.1"><a href="#appendix-B.4" class="auto internal xref"></a><a href="#name-distributed-tracing-opentel" class="internal xref">Distributed Tracing (OpenTelemetry)</a></p>
 </li>
               <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.14.2.5">
-                <p id="section-toc.1-1.14.2.5.1"><a href="#appendix-B.5" class="auto internal xref"></a><a href="#name-blockchain-and-distributed-" class="internal xref">Blockchain and Distributed Ledgers</a></p>
-</li>
-              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.14.2.6">
-                <p id="section-toc.1-1.14.2.6.1"><a href="#appendix-B.6" class="auto internal xref"></a><a href="#name-scitt-supply-chain-integrit" class="internal xref">SCITT (Supply Chain Integrity, Transparency, and Trust)</a></p>
-</li>
-              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.14.2.7">
-                <p id="section-toc.1-1.14.2.7.1"><a href="#appendix-B.7" class="auto internal xref"></a><a href="#name-w3c-verifiable-credentials" class="internal xref">W3C Verifiable Credentials</a></p>
+                <p id="section-toc.1-1.14.2.5.1"><a href="#appendix-B.5" class="auto internal xref"></a><a href="#name-scitt-supply-chain-integrit" class="internal xref">SCITT (Supply Chain Integrity, Transparency, and Trust)</a></p>
 </li>
             </ul>
 </li>
           <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.15">
-            <p id="section-toc.1-1.15.1"><a href="#appendix-C" class="auto internal xref"></a><a href="#name-implementation-guidance" class="internal xref">Implementation Guidance</a></p>
-<ul class="compact toc ulBare ulEmpty">
-<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.15.2.1">
-                <p id="section-toc.1-1.15.2.1.1"><a href="#appendix-C.1" class="auto internal xref"></a><a href="#name-minimal-implementation" class="internal xref">Minimal Implementation</a></p>
-</li>
-              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.15.2.2">
-                <p id="section-toc.1-1.15.2.2.1"><a href="#appendix-C.2" class="auto internal xref"></a><a href="#name-storage-recommendations" class="internal xref">Storage Recommendations</a></p>
-</li>
-              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.15.2.3">
-                <p id="section-toc.1-1.15.2.3.1"><a href="#appendix-C.3" class="auto internal xref"></a><a href="#name-performance-considerations" class="internal xref">Performance Considerations</a></p>
-</li>
-              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.15.2.4">
-                <p id="section-toc.1-1.15.2.4.1"><a href="#appendix-C.4" class="auto internal xref"></a><a href="#name-interoperability" class="internal xref">Interoperability</a></p>
-</li>
-            </ul>
+            <p id="section-toc.1-1.15.1"><a href="#appendix-C" class="auto internal xref"></a><a href="#name-acknowledgments" class="internal xref">Acknowledgments</a></p>
 </li>
           <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.16">
-            <p id="section-toc.1-1.16.1"><a href="#appendix-D" class="auto internal xref"></a><a href="#name-regulatory-compliance-mappi" class="internal xref">Regulatory Compliance Mapping</a></p>
-</li>
-          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.17">
-            <p id="section-toc.1-1.17.1"><a href="#appendix-E" class="auto internal xref"></a><a href="#name-examples" class="internal xref">Examples</a></p>
-<ul class="compact toc ulBare ulEmpty">
-<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.17.2.1">
-                <p id="section-toc.1-1.17.2.1.1"><a href="#appendix-E.1" class="auto internal xref"></a><a href="#name-example-1-simple-two-agent-" class="internal xref">Example 1: Simple Two-Agent Workflow</a></p>
-</li>
-              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.17.2.2">
-                <p id="section-toc.1-1.17.2.2.1"><a href="#appendix-E.2" class="auto internal xref"></a><a href="#name-example-2-medical-device-sd" class="internal xref">Example 2: Medical Device SDLC with Release Approval</a></p>
-</li>
-              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.17.2.3">
-                <p id="section-toc.1-1.17.2.3.1"><a href="#appendix-E.3" class="auto internal xref"></a><a href="#name-example-3-parallel-executio" class="internal xref">Example 3: Parallel Execution with Join</a></p>
-</li>
-            </ul>
-</li>
-          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.18">
-            <p id="section-toc.1-1.18.1"><a href="#appendix-F" class="auto internal xref"></a><a href="#name-acknowledgments" class="internal xref">Acknowledgments</a></p>
-</li>
-          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.19">
-            <p id="section-toc.1-1.19.1"><a href="#appendix-G" class="auto internal xref"></a><a href="#name-authors-address" class="internal xref">Author's Address</a></p>
+            <p id="section-toc.1-1.16.1"><a href="#appendix-D" class="auto internal xref"></a><a href="#name-authors-address" class="internal xref">Author's Address</a></p>
 </li>
         </ul>
 </nav>
@@ -1637,9 +1554,7 @@ what was done or in what order.<a href="#section-1.1-2" class="pilcrow">¶</a></
 <p id="section-1.1-3">Regulated environments increasingly deploy autonomous agents that
 coordinate across organizational boundaries.  Domains such as
 healthcare, finance, and logistics require structured, auditable
-records of automated decision-making and execution.
-<a href="#_table-regulatory" class="auto internal xref">Table 2</a> in the appendix illustrates how ECTs relate
-to specific regulatory frameworks.<a href="#section-1.1-3" class="pilcrow">¶</a></p>
+records of automated decision-making and execution.<a href="#section-1.1-3" class="pilcrow">¶</a></p>
 <p id="section-1.1-4">This document defines an extension to the WIMSE architecture that
 addresses the gap between workload identity and execution
 accountability.  WIMSE authenticates agents; this extension records
@@ -1701,10 +1616,6 @@ regulatory audit scenarios.<a href="#section-1.2-3" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="section-1.3-2.5">
             <p id="section-1.3-2.5.1">Audit ledger interface requirements (<a href="#ledger-interface" class="auto internal xref">Section 8</a>)<a href="#section-1.3-2.5.1" class="pilcrow">¶</a></p>
-</li>
-          <li class="normal" id="section-1.3-2.6">
-            <p id="section-1.3-2.6.1">Policy evaluation and compensation extensions are defined
-separately in <span>[<a href="#I-D.nennemann-wimse-ect-pol" class="cite xref">I-D.nennemann-wimse-ect-pol</a>]</span><a href="#section-1.3-2.6.1" class="pilcrow">¶</a></p>
 </li>
         </ul>
 <p id="section-1.3-3">The following are out of scope and are handled by WIMSE:<a href="#section-1.3-3" class="pilcrow">¶</a></p>
@@ -1724,28 +1635,6 @@ separately in <span>[<a href="#I-D.nennemann-wimse-ect-pol" class="cite xref">I-
         </ul>
 </section>
 </div>
-<div id="relationship-to-regulatory-compliance">
-<section id="section-1.4">
-        <h3 id="name-relationship-to-regulatory-">
-<a href="#section-1.4" class="section-number selfRef">1.4. </a><a href="#name-relationship-to-regulatory-" class="section-name selfRef">Relationship to Regulatory Compliance</a>
-        </h3>
-<p id="section-1.4-1">ECTs are a technical mechanism that can support compliance programs
-by providing structured, cryptographically signed execution
-records.  ECTs do not by themselves constitute compliance with any
-regulatory framework referenced in this document.<a href="#section-1.4-1" class="pilcrow">¶</a></p>
-<p id="section-1.4-2">Compliance with each referenced regulation requires organizational
-controls, policies, procedures, validation, and governance measures
-beyond the scope of this specification.  The regulatory references
-in this document are intended to motivate the design requirements,
-not to claim that implementing ECTs satisfies these regulations.<a href="#section-1.4-2" class="pilcrow">¶</a></p>
-<p id="section-1.4-3">ECTs provide evidence of claimed execution ordering.  They do not
-independently verify that the claimed execution actually occurred
-as described or that the agent faithfully performed the stated
-action.  The trustworthiness of ECT claims depends on the
-trustworthiness of the signing agent and the integrity of the
-broader deployment environment.<a href="#section-1.4-3" class="pilcrow">¶</a></p>
-</section>
-</div>
 </section>
 </div>
 <div id="conventions-and-definitions">
@@ -1786,8 +1675,7 @@ records task execution details.<a href="#section-2-3.8.1" class="pilcrow">¶</a>
 <dt id="section-2-3.9">Audit Ledger:</dt>
         <dd style="margin-left: 1.5em" id="section-2-3.10">
           <p id="section-2-3.10.1">An append-only, immutable log of all ECTs within a workflow or
-set of workflows, used for regulatory audit and compliance
-verification.<a href="#section-2-3.10.1" class="pilcrow">¶</a></p>
+set of workflows, used for audit and verification.<a href="#section-2-3.10.1" class="pilcrow">¶</a></p>
 </dd>
         <dd class="break"></dd>
 <dt id="section-2-3.11">Workload Identity Token (WIT):</dt>
@@ -1807,12 +1695,6 @@ authentication.<a href="#section-2-3.14.1" class="pilcrow">¶</a></p>
           <p id="section-2-3.16.1">A WIMSE concept representing an organizational boundary with a
 shared identity issuer, corresponding to a SPIFFE <span>[<a href="#SPIFFE" class="cite xref">SPIFFE</a>]</span>
 trust domain.<a href="#section-2-3.16.1" class="pilcrow">¶</a></p>
-</dd>
-        <dd class="break"></dd>
-<dt id="section-2-3.17">Witness:</dt>
-        <dd style="margin-left: 1.5em" id="section-2-3.18">
-          <p id="section-2-3.18.1">A third-party entity that observes and attests to the execution
-of a task, providing additional accountability.<a href="#section-2-3.18.1" class="pilcrow">¶</a></p>
 </dd>
       <dd class="break"></dd>
 </dl>
@@ -1971,8 +1853,10 @@ ledger.<a href="#section-3.3-7.3.1" class="pilcrow">¶</a></p>
 <a href="#section-4" class="section-number selfRef">4. </a><a href="#name-execution-context-token-for" class="section-name selfRef">Execution Context Token Format</a>
       </h2>
 <p id="section-4-1">An Execution Context Token is a JSON Web Token (JWT) <span>[<a href="#RFC7519" class="cite xref">RFC7519</a>]</span>
-signed as a JSON Web Signature (JWS) <span>[<a href="#RFC7515" class="cite xref">RFC7515</a>]</span> using the Compact
-Serialization.  JWS JSON Serialization <span class="bcp14">MUST NOT</span> be used for ECTs.<a href="#section-4-1" class="pilcrow">¶</a></p>
+signed as a JSON Web Signature (JWS) <span>[<a href="#RFC7515" class="cite xref">RFC7515</a>]</span>.  ECTs <span class="bcp14">MUST</span> use
+JWS Compact Serialization (the base64url-encoded
+<code>header.payload.signature</code> format) so that they can be carried in
+a single HTTP header value.<a href="#section-4-1" class="pilcrow">¶</a></p>
 <div id="jose-header">
 <section id="section-4.1">
         <h3 id="name-jose-header">
@@ -2149,7 +2033,10 @@ collision with the "act" (Actor) claim registered by
 representing DAG dependencies.  Each element <span class="bcp14">MUST</span> be the "jti"
 value of a previously verified ECT.  An empty array indicates
 a root task with no dependencies.  A workflow <span class="bcp14">MAY</span> contain
-multiple root tasks.<a href="#section-4.2.2-2.6.1" class="pilcrow">¶</a></p>
+multiple root tasks.  Parent ECTs may have passed their own
+"exp" time; ECT expiration applies to the verification window
+of the ECT itself, not to its validity as a parent reference
+in the ECT store.<a href="#section-4.2.2-2.6.1" class="pilcrow">¶</a></p>
 </dd>
           <dd class="break"></dd>
 </dl>
@@ -2186,33 +2073,21 @@ using the same format and algorithm requirements as "inp_hash".<a href="#section
 </dl>
 </section>
 </div>
-<div id="compensation-claims">
-<section id="section-4.2.4">
-          <h4 id="name-compensation-and-rollback">
-<a href="#section-4.2.4" class="section-number selfRef">4.2.4. </a><a href="#name-compensation-and-rollback" class="section-name selfRef">Compensation and Rollback</a>
-          </h4>
-<p id="section-4.2.4-1">Compensation and rollback extensions are defined in
-<span>[<a href="#I-D.nennemann-wimse-ect-pol" class="cite xref">I-D.nennemann-wimse-ect-pol</a>]</span>.  The referenced
-parent ECTs may have passed their own "exp" time; ECT expiration
-applies to the verification window of the ECT itself, not to its
-validity as a parent reference in the ECT store.<a href="#section-4.2.4-1" class="pilcrow">¶</a></p>
-</section>
-</div>
 <div id="extension-claims">
-<section id="section-4.2.5">
+<section id="section-4.2.4">
           <h4 id="name-extensions">
-<a href="#section-4.2.5" class="section-number selfRef">4.2.5. </a><a href="#name-extensions" class="section-name selfRef">Extensions</a>
+<a href="#section-4.2.4" class="section-number selfRef">4.2.4. </a><a href="#name-extensions" class="section-name selfRef">Extensions</a>
           </h4>
-<span class="break"></span><dl class="dlParallel" id="section-4.2.5-1">
-            <dt id="section-4.2.5-1.1">ext:</dt>
-            <dd style="margin-left: 1.5em" id="section-4.2.5-1.2">
-              <p id="section-4.2.5-1.2.1"><span class="bcp14">OPTIONAL</span>.  Object.  An extension object for domain-specific
+<span class="break"></span><dl class="dlParallel" id="section-4.2.4-1">
+            <dt id="section-4.2.4-1.1">ext:</dt>
+            <dd style="margin-left: 1.5em" id="section-4.2.4-1.2">
+              <p id="section-4.2.4-1.2.1"><span class="bcp14">OPTIONAL</span>.  Object.  An extension object for domain-specific
 claims not defined by this specification.  Implementations
-that do not understand extension claims <span class="bcp14">MUST</span> ignore them.<a href="#section-4.2.5-1.2.1" class="pilcrow">¶</a></p>
+that do not understand extension claims <span class="bcp14">MUST</span> ignore them.<a href="#section-4.2.4-1.2.1" class="pilcrow">¶</a></p>
 </dd>
           <dd class="break"></dd>
 </dl>
-<p id="section-4.2.5-2">To avoid key collisions between different domains, extension
+<p id="section-4.2.4-2">To avoid key collisions between different domains, extension
 key names <span class="bcp14">SHOULD</span> use reverse domain notation (e.g.,
 "com.example.custom_field") to avoid collisions between
 independently developed extensions.  To prevent abuse and
@@ -2220,34 +2095,9 @@ excessive token size, the serialized JSON representation of
 the "ext" object <span class="bcp14">SHOULD NOT</span> exceed 4096 bytes, and the JSON
 nesting depth within the "ext" object <span class="bcp14">SHOULD NOT</span> exceed 5
 levels.  Implementations <span class="bcp14">SHOULD</span> reject ECTs whose "ext" claim
-exceeds these limits.<a href="#section-4.2.5-2" class="pilcrow">¶</a></p>
-<p id="section-4.2.5-3">The following extension keys are defined by this specification
-for common use cases.  Because these keys are documented here,
-they use short names without reverse domain prefixes:<a href="#section-4.2.5-3" class="pilcrow">¶</a></p>
-<ul class="normal">
-<li class="normal" id="section-4.2.5-4.1">
-              <p id="section-4.2.5-4.1.1">"exec_time_ms": Integer.  Execution duration in milliseconds.<a href="#section-4.2.5-4.1.1" class="pilcrow">¶</a></p>
-</li>
-            <li class="normal" id="section-4.2.5-4.2">
-              <p id="section-4.2.5-4.2.1">"regulated_domain": String.  Regulatory domain (e.g.,
-"medtech", "finance", "military").<a href="#section-4.2.5-4.2.1" class="pilcrow">¶</a></p>
-</li>
-            <li class="normal" id="section-4.2.5-4.3">
-              <p id="section-4.2.5-4.3.1">"model_version": String.  AI/ML model version.<a href="#section-4.2.5-4.3.1" class="pilcrow">¶</a></p>
-</li>
-            <li class="normal" id="section-4.2.5-4.4">
-              <p id="section-4.2.5-4.4.1">"witnessed_by": Array of StringOrURI.  Identifiers of
-third-party entities that the issuer claims observed the
-task.  Note: this is self-asserted; for verifiable witness
-attestation, witnesses should submit independent signed ECTs.<a href="#section-4.2.5-4.4.1" class="pilcrow">¶</a></p>
-</li>
-            <li class="normal" id="section-4.2.5-4.5">
-              <p id="section-4.2.5-4.5.1">"inp_classification": String.  Data sensitivity classification
-(e.g., "public", "confidential", "restricted").<a href="#section-4.2.5-4.5.1" class="pilcrow">¶</a></p>
-</li>
-          </ul>
-<p id="section-4.2.5-5">Additional extension keys for policy evaluation and compensation
-are defined in <span>[<a href="#I-D.nennemann-wimse-ect-pol" class="cite xref">I-D.nennemann-wimse-ect-pol</a>]</span>.<a href="#section-4.2.5-5" class="pilcrow">¶</a></p>
+exceeds these limits.<a href="#section-4.2.4-2" class="pilcrow">¶</a></p>
+<p id="section-4.2.4-3">Extension keys for domain-specific use cases <span class="bcp14">MAY</span> be defined in
+future documents.<a href="#section-4.2.4-3" class="pilcrow">¶</a></p>
 </section>
 </div>
 </section>
@@ -2274,13 +2124,7 @@ are defined in <span>[<a href="#I-D.nennemann-wimse-ect-pol" class="cite xref">I
   "par": [],
 
   "inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
-  "out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564",
-
-  "ext": {
-    "exec_time_ms": 245,
-    "regulated_domain": "medtech",
-    "model_version": "clinical-reasoning-v4.2"
-  }
+  "out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564"
 }
 </pre>
 </div>
@@ -2401,73 +2245,10 @@ same trust domain or to a trust domain with which a federation
 relationship has been established.<a href="#section-6.2-2.5.1" class="pilcrow">¶</a></p>
 </li>
         </ol>
-</section>
-</div>
-<div id="dag-validation-algorithm">
-<section id="section-6.3">
-        <h3 id="name-dag-validation-algorithm">
-<a href="#section-6.3" class="section-number selfRef">6.3. </a><a href="#name-dag-validation-algorithm" class="section-name selfRef">DAG Validation Algorithm</a>
-        </h3>
-<p id="section-6.3-1">The following pseudocode describes the DAG validation procedure:<a href="#section-6.3-1" class="pilcrow">¶</a></p>
-<span id="name-dag-validation-pseudocode"></span><div id="fig-dag-validation">
-<figure id="figure-6">
-          <div class="lang-pseudocode sourcecode" id="section-6.3-2.1">
-<pre>
-function validate_dag(ect, ect_store, clock_skew_tolerance):
-  // Step 1: Uniqueness check
-  if ect_store.contains(ect.jti, ect.wid):
-    return error("ECT ID already exists")
-
-  // Step 2: Parent existence and temporal ordering
-  for parent_id in ect.par:
-    parent = ect_store.get(parent_id)
-    if parent is null:
-      return error("Parent task not found: " + parent_id)
-    if parent.iat &gt;= ect.iat + clock_skew_tolerance:
-      return error("Parent task not earlier than current")
-
-  // Step 3: Cycle detection (with traversal limit)
-  visited = set()
-  result = has_cycle(ect.jti, ect.par, ect_store, visited,
-                      max_ancestor_limit)
-  if result is error or result is true:
-    return error("Circular dependency or depth limit exceeded")
-
-  return success
-
-function has_cycle(target_jti, parent_ids, ect_store,
-                   visited, max_depth):
-  if visited.size() &gt;= max_depth:
-    return error("Maximum ancestor traversal limit exceeded")
-  for parent_id in parent_ids:
-    if parent_id == target_jti:
-      return true
-    if parent_id in visited:
-      continue
-    visited.add(parent_id)
-    parent = ect_store.get(parent_id)
-    if parent is not null:
-      result = has_cycle(target_jti, parent.par, ect_store,
-                          visited, max_depth)
-      if result is error or result is true:
-        return result
-  return false
-</pre>
-</div>
-<figcaption><a href="#figure-6" class="selfRef">Figure 6</a>:
-<a href="#name-dag-validation-pseudocode" class="selfRef">DAG Validation Pseudocode</a>
-          </figcaption></figure>
-</div>
-<p id="section-6.3-3">The cycle detection traverses the ancestor graph rooted at the
-current task's parents.  The complexity is O(V) where V is the
-number of ancestor nodes reachable from the current task's parent
-references.  For typical workflows with shallow DAGs, this is
-efficient.  To prevent denial-of-service via extremely deep or
-wide DAGs, implementations <span class="bcp14">SHOULD</span> enforce a maximum ancestor
-traversal limit (<span class="bcp14">RECOMMENDED</span>: 10000 nodes).  If the limit is
-reached before cycle detection completes, the ECT <span class="bcp14">SHOULD</span> be
-rejected.  Implementations <span class="bcp14">SHOULD</span> cache cycle detection results
-for previously verified tasks to avoid redundant traversals.<a href="#section-6.3-3" class="pilcrow">¶</a></p>
+<p id="section-6.2-3">To prevent denial-of-service via extremely deep or wide DAGs,
+implementations <span class="bcp14">SHOULD</span> enforce a maximum ancestor traversal limit
+(<span class="bcp14">RECOMMENDED</span>: 10000 nodes).  If the limit is reached before cycle
+detection completes, the ECT <span class="bcp14">SHOULD</span> be rejected.<a href="#section-6.2-3" class="pilcrow">¶</a></p>
 </section>
 </div>
 </section>
@@ -2563,87 +2344,6 @@ agent <span class="bcp14">MUST NOT</span> process the requested action when ECT
 fails.<a href="#section-7.1-4" class="pilcrow">¶</a></p>
 </section>
 </div>
-<div id="verification-pseudocode">
-<section id="section-7.2">
-        <h3 id="name-verification-pseudocode">
-<a href="#section-7.2" class="section-number selfRef">7.2. </a><a href="#name-verification-pseudocode" class="section-name selfRef">Verification Pseudocode</a>
-        </h3>
-<span id="name-ect-verification-pseudocode"></span><div id="fig-verification">
-<figure id="figure-7">
-          <div class="breakable lang-pseudocode sourcecode" id="section-7.2-1.1">
-<pre>
-function verify_ect(ect_jws, verifier_id,
-                     trust_domain_keys, ect_store):
-  // Parse JWS
-  (header, payload, signature) = parse_jws(ect_jws)
-
-  // Verify header
-  if header.typ != "wimse-exec+jwt":
-    return reject("Invalid typ parameter")
-
-  if header.alg == "none" or is_symmetric(header.alg):
-    return reject("Prohibited algorithm")
-
-  // Look up public key
-  public_key = trust_domain_keys.get(header.kid)
-  if public_key is null:
-    return reject("Unknown key identifier")
-
-  // Verify signature
-  if not verify_jws_signature(header, payload,
-                               signature, public_key):
-    return reject("Invalid signature")
-
-  // Verify key not revoked
-  if is_key_revoked(header.kid, trust_domain_keys):
-    return reject("Signing key has been revoked")
-
-  // Verify algorithm alignment
-  wit = get_wit_for_key(header.kid)
-  if header.alg != wit.alg:
-    return reject("Algorithm mismatch with WIT")
-
-  // Verify issuer matches WIT subject
-  if payload.iss != wit.sub:
-    return reject("Issuer does not match WIT subject")
-
-  // Verify audience
-  if verifier_id not in payload.aud:
-    return reject("ECT not intended for this recipient")
-
-  // Verify not expired
-  if payload.exp &lt; current_time():
-    return reject("ECT has expired")
-
-  // Verify iat freshness (not too old, not in the future)
-  if payload.iat &lt; current_time() - max_age_threshold:
-    return reject("ECT issued too long ago")
-  if payload.iat &gt; current_time() + clock_skew_tolerance:
-    return reject("ECT issued in the future")
-
-  // Verify required claims
-  for claim in ["jti", "exec_act", "par"]:
-    if claim not in payload:
-      return reject("Missing required claim: " + claim)
-
-  // Validate DAG (against ECT store or inline parent ECTs)
-  result = validate_dag(payload, ect_store,
-                         clock_skew_tolerance)
-  if result is error:
-    return reject("DAG validation failed")
-
-  // All checks passed; record if store is available
-  if ect_store is not null:
-    ect_store.append(payload)
-  return accept
-</pre>
-</div>
-<figcaption><a href="#figure-7" class="selfRef">Figure 7</a>:
-<a href="#name-ect-verification-pseudocode" class="selfRef">ECT Verification Pseudocode</a>
-          </figcaption></figure>
-</div>
-</section>
-</div>
 </section>
 </div>
 <div id="ledger-interface">
@@ -2737,20 +2437,8 @@ compromised or malicious agent could create ECTs with false claims
 </li>
         </ul>
 <p id="section-9.2-4">The trustworthiness of ECT claims depends on the trustworthiness
-of the signing agent.  To mitigate single-agent false claims,
-regulated environments <span class="bcp14">SHOULD</span> use the "witnessed_by"
-extension key (carried in "ext") to include independent
-third-party observers at critical decision points.  However,
-this value is self-asserted by the ECT issuer: the listed
-witnesses do not co-sign the ECT and there is no cryptographic
-evidence within a single ECT that the witnesses actually
-observed the task.  An issuing agent could list witnesses that
-did not participate.<a href="#section-9.2-4" class="pilcrow">¶</a></p>
-<p id="section-9.2-5">To strengthen witness attestation beyond self-assertion, witnesses
-<span class="bcp14">SHOULD</span> submit their own independent signed ECTs referencing the
-observed task's "jti" in the "par" array.  Auditors can then
-cross-check the "witnessed_by" extension against independent
-witness ECTs in the ECT store.<a href="#section-9.2-5" class="pilcrow">¶</a></p>
+of the signing agent and the integrity of the broader deployment
+environment.<a href="#section-9.2-4" class="pilcrow">¶</a></p>
 </section>
 </div>
 <div id="organizational-prerequisites">
@@ -2886,16 +2574,12 @@ create a false execution history if they control the ledger.<a href="#section-9.
 by an entity independent of the workflow agents.<a href="#section-9.8-3.1.1" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="section-9.8-3.2">
-            <p id="section-9.8-3.2.1">Witness attestation: Using the "witnessed_by" extension
-key in "ext" to include independent third-party observers.<a href="#section-9.8-3.2.1" class="pilcrow">¶</a></p>
+            <p id="section-9.8-3.2.1">Cross-verification: Multiple independent ledger replicas can be
+compared for consistency.<a href="#section-9.8-3.2.1" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="section-9.8-3.3">
-            <p id="section-9.8-3.3.1">Cross-verification: Multiple independent ledger replicas can be
-compared for consistency.<a href="#section-9.8-3.3.1" class="pilcrow">¶</a></p>
-</li>
-          <li class="normal" id="section-9.8-3.4">
-            <p id="section-9.8-3.4.1">Out-of-band audit: External auditors periodically verify ledger
-contents against expected workflow patterns.<a href="#section-9.8-3.4.1" class="pilcrow">¶</a></p>
+            <p id="section-9.8-3.3.1">Out-of-band audit: External auditors periodically verify ledger
+contents against expected workflow patterns.<a href="#section-9.8-3.3.1" class="pilcrow">¶</a></p>
 </li>
         </ul>
 </section>
@@ -2947,7 +2631,7 @@ array to a maximum of 256 entries.  Workflows requiring more
 parent references <span class="bcp14">SHOULD</span> introduce intermediate aggregation
 tasks.  The "ext" object <span class="bcp14">SHOULD NOT</span> exceed 4096 bytes when
 serialized as JSON and <span class="bcp14">SHOULD NOT</span> exceed a nesting depth of
-5 levels (see also <a href="#extension-claims" class="auto internal xref">Section 4.2.5</a>).<a href="#section-9.11-1" class="pilcrow">¶</a></p>
+5 levels (see also <a href="#extension-claims" class="auto internal xref">Section 4.2.4</a>).<a href="#section-9.11-1" class="pilcrow">¶</a></p>
 </section>
 </div>
 </section>
@@ -3000,9 +2684,9 @@ hashes via "inp_hash" and "out_hash")<a href="#section-10.1-4.1.1" class="pilcro
 <p id="section-10.2-1">Implementations <span class="bcp14">SHOULD</span> minimize the information included in ECTs.
 The "exec_act" claim <span class="bcp14">SHOULD</span> use structured identifiers (e.g.,
 "process_payment") rather than natural language descriptions.
-Extension keys in "ext" (<a href="#extension-claims" class="auto internal xref">Section 4.2.5</a>) deserve particular
+Extension keys in "ext" (<a href="#extension-claims" class="auto internal xref">Section 4.2.4</a>) deserve particular
 attention: human-readable values risk exposing sensitive operational
-details.  See <a href="#extension-claims" class="auto internal xref">Section 4.2.5</a> for guidance on using
+details.  See <a href="#extension-claims" class="auto internal xref">Section 4.2.4</a> for guidance on using
 structured identifiers.<a href="#section-10.2-1" class="pilcrow">¶</a></p>
 </section>
 </div>
@@ -3012,25 +2696,16 @@ structured identifiers.<a href="#section-10.2-1" class="pilcrow">¶</a></p>
 <a href="#section-10.3" class="section-number selfRef">10.3. </a><a href="#name-storage-and-access-control" class="section-name selfRef">Storage and Access Control</a>
         </h3>
 <p id="section-10.3-1">ECTs stored in audit ledgers <span class="bcp14">SHOULD</span> be access-controlled so that
-only authorized auditors and regulators can read them.
-Implementations <span class="bcp14">SHOULD</span> consider encryption at rest for ledger
-storage containing sensitive regulatory data.<a href="#section-10.3-1" class="pilcrow">¶</a></p>
+only authorized auditors can read them.  Implementations <span class="bcp14">SHOULD</span>
+consider encryption at rest for ledger storage.  ECTs provide
+structural records of execution ordering; they are not intended
+for public disclosure.<a href="#section-10.3-1" class="pilcrow">¶</a></p>
 <p id="section-10.3-2">Full input and output data (corresponding to the hashes in ECTs)
 <span class="bcp14">SHOULD</span> be stored separately from the ledger with additional access
 controls, since auditors may need to verify hash correctness but
 general access to the data values is not needed.<a href="#section-10.3-2" class="pilcrow">¶</a></p>
 </section>
 </div>
-<div id="regulatory-access">
-<section id="section-10.4">
-        <h3 id="name-regulatory-access">
-<a href="#section-10.4" class="section-number selfRef">10.4. </a><a href="#name-regulatory-access" class="section-name selfRef">Regulatory Access</a>
-        </h3>
-<p id="section-10.4-1">ECTs are designed for interpretation by qualified human auditors
-and regulators.  ECTs provide structural records of execution
-ordering; they are not intended for public disclosure.<a href="#section-10.4-1" class="pilcrow">¶</a></p>
-</section>
-</div>
 </section>
 </div>
 <div id="iana-considerations">
@@ -3090,8 +2765,8 @@ separated by period characters.<a href="#section-11.1-2.10.1" class="pilcrow">¶
           <dd class="break"></dd>
 <dt id="section-11.1-2.17">Applications that use this media type:</dt>
           <dd style="margin-left: 1.5em" id="section-11.1-2.18">
-            <p id="section-11.1-2.18.1">Applications that implement regulated agentic workflows requiring
-execution context tracing and audit trails.<a href="#section-11.1-2.18.1" class="pilcrow">¶</a></p>
+            <p id="section-11.1-2.18.1">Applications that implement agentic workflows requiring execution
+context tracing and audit trails.<a href="#section-11.1-2.18.1" class="pilcrow">¶</a></p>
 </dd>
           <dd class="break"></dd>
 <dt id="section-11.1-2.19">Additional information:</dt>
@@ -3223,15 +2898,12 @@ the "JSON Web Token Claims" registry maintained by IANA:<a href="#section-11.3-1
               <td class="text-left" rowspan="1" colspan="1">Extension Object</td>
               <td class="text-center" rowspan="1" colspan="1">IETF</td>
               <td class="text-center" rowspan="1" colspan="1">
-                <a href="#extension-claims" class="auto internal xref">Section 4.2.5</a>
+                <a href="#extension-claims" class="auto internal xref">Section 4.2.4</a>
 </td>
             </tr>
           </tbody>
         </table>
 </div>
-<p id="section-11.3-3">Policy evaluation claims and the ECT Policy Decision Values
-registry are defined in
-<span>[<a href="#I-D.nennemann-wimse-ect-pol" class="cite xref">I-D.nennemann-wimse-ect-pol</a>]</span>.<a href="#section-11.3-3" class="pilcrow">¶</a></p>
 </section>
 </div>
 </section>
@@ -3296,22 +2968,6 @@ registry are defined in
 <a href="#section-12.2" class="section-number selfRef">12.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
         </h3>
 <dl class="references">
-<dt id="DORA">[DORA]</dt>
-        <dd>
-<span class="refAuthor">European Parliament and Council of the European Union</span>, <span class="refTitle">"Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA)"</span>, <time datetime="2022-12-14" class="refDate">14 December 2022</time>, <span>&lt;<a href="https://eur-lex.europa.eu/eli/reg/2022/2554">https://eur-lex.europa.eu/eli/reg/2022/2554</a>&gt;</span>. </dd>
-<dd class="break"></dd>
-<dt id="EU-AI-ACT">[EU-AI-ACT]</dt>
-        <dd>
-<span class="refAuthor">European Parliament and Council of the European Union</span>, <span class="refTitle">"Regulation (EU) 2024/1689 of the European Parliament and of the Council laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)"</span>, <time datetime="2024-06-13" class="refDate">13 June 2024</time>, <span>&lt;<a href="https://eur-lex.europa.eu/eli/reg/2024/1689">https://eur-lex.europa.eu/eli/reg/2024/1689</a>&gt;</span>. </dd>
-<dd class="break"></dd>
-<dt id="EU-MDR">[EU-MDR]</dt>
-        <dd>
-<span class="refAuthor">European Parliament and Council of the European Union</span>, <span class="refTitle">"Regulation (EU) 2017/745 on medical devices (MDR)"</span>, <time datetime="2017-04-05" class="refDate">5 April 2017</time>, <span>&lt;<a href="https://eur-lex.europa.eu/eli/reg/2017/745">https://eur-lex.europa.eu/eli/reg/2017/745</a>&gt;</span>. </dd>
-<dd class="break"></dd>
-<dt id="FDA-21CFR11">[FDA-21CFR11]</dt>
-        <dd>
-<span class="refAuthor">U.S. Food and Drug Administration</span>, <span class="refTitle">"Title 21, Code of Federal Regulations, Part 11: Electronic Records; Electronic Signatures"</span>, <span>&lt;<a href="https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11">https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11</a>&gt;</span>. </dd>
-<dd class="break"></dd>
 <dt id="I-D.ietf-oauth-transaction-tokens">[I-D.ietf-oauth-transaction-tokens]</dt>
         <dd>
 <span class="refAuthor">Tulshibagwale, A.</span>, <span class="refAuthor">Fletcher, G.</span>, and <span class="refAuthor">P. Kasselman</span>, <span class="refTitle">"Transaction Tokens"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-oauth-transaction-tokens-07</span>, <time datetime="2026-01-24" class="refDate">24 January 2026</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-07">https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-07</a>&gt;</span>. </dd>
@@ -3320,10 +2976,6 @@ registry are defined in
         <dd>
 <span class="refAuthor">Birkholz, H.</span>, <span class="refAuthor">Delignat-Lavaud, A.</span>, <span class="refAuthor">Fournet, C.</span>, <span class="refAuthor">Deshpande, Y.</span>, and <span class="refAuthor">S. Lasker</span>, <span class="refTitle">"An Architecture for Trustworthy and Transparent Digital Supply Chains"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-scitt-architecture-22</span>, <time datetime="2025-10-10" class="refDate">10 October 2025</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-ietf-scitt-architecture-22">https://datatracker.ietf.org/doc/html/draft-ietf-scitt-architecture-22</a>&gt;</span>. </dd>
 <dd class="break"></dd>
-<dt id="I-D.nennemann-wimse-ect-pol">[I-D.nennemann-wimse-ect-pol]</dt>
-        <dd>
-<span class="refAuthor">Nennemann, C.</span>, <span class="refTitle">"Policy Evaluation and Compensation Extensions for Execution Context Tokens"</span>, <span>&lt;<a href="https://datatracker.ietf.org/doc/draft-nennemann-wimse-ect-pol/">https://datatracker.ietf.org/doc/draft-nennemann-wimse-ect-pol/</a>&gt;</span>. </dd>
-<dd class="break"></dd>
 <dt id="I-D.ni-wimse-ai-agent-identity">[I-D.ni-wimse-ai-agent-identity]</dt>
         <dd>
 <span class="refAuthor">Yuan, N.</span> and <span class="refAuthor">P. C. Liu</span>, <span class="refTitle">"WIMSE Applicability for AI Agents"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ni-wimse-ai-agent-identity-01</span>, <time datetime="2025-10-20" class="refDate">20 October 2025</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-ni-wimse-ai-agent-identity-01">https://datatracker.ietf.org/doc/html/draft-ni-wimse-ai-agent-identity-01</a>&gt;</span>. </dd>
@@ -3332,10 +2984,6 @@ registry are defined in
         <dd>
 <span class="refAuthor">Raut, A.</span>, <span class="refTitle">"Transaction Tokens For Agents"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-oauth-transaction-tokens-for-agents-04</span>, <time datetime="2026-02-10" class="refDate">10 February 2026</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-oauth-transaction-tokens-for-agents-04">https://datatracker.ietf.org/doc/html/draft-oauth-transaction-tokens-for-agents-04</a>&gt;</span>. </dd>
 <dd class="break"></dd>
-<dt id="MIFID-II">[MIFID-II]</dt>
-        <dd>
-<span class="refAuthor">European Parliament and Council of the European Union</span>, <span class="refTitle">"Directive 2014/65/EU of the European Parliament and of the Council on markets in financial instruments (MiFID II)"</span>, <time datetime="2014-05-15" class="refDate">15 May 2014</time>, <span>&lt;<a href="https://eur-lex.europa.eu/eli/dir/2014/65">https://eur-lex.europa.eu/eli/dir/2014/65</a>&gt;</span>. </dd>
-<dd class="break"></dd>
 <dt id="OPENTELEMETRY">[OPENTELEMETRY]</dt>
         <dd>
 <span class="refAuthor">Cloud Native Computing Foundation</span>, <span class="refTitle">"OpenTelemetry Specification"</span>, <span>&lt;<a href="https://opentelemetry.io/docs/specs/otel/">https://opentelemetry.io/docs/specs/otel/</a>&gt;</span>. </dd>
@@ -3366,145 +3014,24 @@ registry are defined in
       <h2 id="name-use-cases">
 <a href="#name-use-cases" class="section-name selfRef">Use Cases</a>
       </h2>
-<p id="appendix-A-1">This section describes representative use cases demonstrating how
-ECTs provide execution records in regulated environments.  These
-examples demonstrate ECT mechanics; production deployments would
-include additional domain-specific requirements beyond the scope
-of this specification.<a href="#appendix-A-1" class="pilcrow">¶</a></p>
+<p id="appendix-A-1">This section describes a representative use case demonstrating how
+ECTs provide structured execution records.<a href="#appendix-A-1" class="pilcrow">¶</a></p>
 <p id="appendix-A-2">Note: task identifiers in this section are abbreviated for
 readability.  In production, all "jti" values are required to be
 UUIDs per <a href="#exec-claims" class="auto internal xref">Section 4.2.2</a>.<a href="#appendix-A-2" class="pilcrow">¶</a></p>
-<div id="medical-device-sdlc-workflow">
-<section id="appendix-A.1">
-        <h3 id="name-medical-device-sdlc-workflo">
-<a href="#name-medical-device-sdlc-workflo" class="section-name selfRef">Medical Device SDLC Workflow</a>
-        </h3>
-<p id="appendix-A.1-1">In a medical device software development lifecycle (SDLC),
-AI agents assist across multiple phases from requirements
-analysis through release approval.  Regulatory frameworks
-including <span>[<a href="#FDA-21CFR11" class="cite xref">FDA-21CFR11</a>]</span> Section 11.10(e) and <span>[<a href="#EU-MDR" class="cite xref">EU-MDR</a>]</span> require
-audit trails documenting the complete development process for
-software used in medical devices.<a href="#appendix-A.1-1" class="pilcrow">¶</a></p>
-<span id="name-medical-device-sdlc-workflow"></span><div id="fig-medtech-sdlc">
-<figure id="figure-8">
-          <div class="alignLeft art-text artwork" id="appendix-A.1-2.1">
-<pre>
-Agent A (Spec Reviewer):
-  jti: task-001    par: []
-  exec_act: review_requirements_spec
-
-Agent B (Code Generator):
-  jti: task-002    par: [task-001]
-  exec_act: implement_module
-
-Agent C (Test Agent):
-  jti: task-003    par: [task-002]
-  exec_act: execute_test_suite
-
-Agent D (Build Agent):
-  jti: task-004    par: [task-003]
-  exec_act: build_release_artifact
-
-Human Release Manager:
-  jti: task-005    par: [task-004]
-  exec_act: approve_release
-  ext: {witnessed_by: [...]}  (extension metadata)
-</pre>
-</div>
-<figcaption><a href="#figure-8" class="selfRef">Figure 8</a>:
-<a href="#name-medical-device-sdlc-workflow" class="selfRef">Medical Device SDLC Workflow</a>
-          </figcaption></figure>
-</div>
-<p id="appendix-A.1-3">ECTs record that requirements were reviewed before implementation
-began, that tests were executed against the implemented code, that
-the build artifact was validated, and that a human release manager
-explicitly approved the release.  The DAG structure ensures no
-phase was skipped or reordered.<a href="#appendix-A.1-3" class="pilcrow">¶</a></p>
-<div id="fda-audit-with-dag-reconstruction">
-<section id="appendix-A.1.1">
-          <h4 id="name-fda-audit-with-dag-reconstr">
-<a href="#name-fda-audit-with-dag-reconstr" class="section-name selfRef">FDA Audit with DAG Reconstruction</a>
-          </h4>
-<p id="appendix-A.1.1-1">During a regulatory audit, an FDA reviewer requests evidence of
-the development process for a specific software release.  The
-auditing authority retrieves all ECTs sharing the same workflow
-identifier ("wid") from the audit ledger and reconstructs the
-complete DAG:<a href="#appendix-A.1.1-1" class="pilcrow">¶</a></p>
-<span id="name-reconstructed-dag-for-fda-a"></span><div id="fig-fda-audit">
-<figure id="figure-9">
-            <div class="alignLeft art-text artwork" id="appendix-A.1.1-2.1">
-<pre>
-task-001 (review_requirements_spec)
-  |
-  v
-task-002 (implement_module)
-  |
-  v
-task-003 (execute_test_suite)
-  |
-  v
-task-004 (build_release_artifact)
-  |
-  v
-task-005 (approve_release) [human, witnessed]
-</pre>
-</div>
-<figcaption><a href="#figure-9" class="selfRef">Figure 9</a>:
-<a href="#name-reconstructed-dag-for-fda-a" class="selfRef">Reconstructed DAG for FDA Audit</a>
-            </figcaption></figure>
-</div>
-<p id="appendix-A.1.1-3">The reconstructed DAG provides cryptographic evidence that:<a href="#appendix-A.1.1-3" class="pilcrow">¶</a></p>
-<ul class="normal">
-<li class="normal" id="appendix-A.1.1-4.1">
-              <p id="appendix-A.1.1-4.1.1">Each phase was executed by an identified and authenticated agent.<a href="#appendix-A.1.1-4.1.1" class="pilcrow">¶</a></p>
-</li>
-            <li class="normal" id="appendix-A.1.1-4.2">
-              <p id="appendix-A.1.1-4.2.1">The execution sequence was maintained (no step was bypassed).<a href="#appendix-A.1.1-4.2.1" class="pilcrow">¶</a></p>
-</li>
-            <li class="normal" id="appendix-A.1.1-4.3">
-              <p id="appendix-A.1.1-4.3.1">A human-in-the-loop approved the final release, with independent
-witness attestation.<a href="#appendix-A.1.1-4.3.1" class="pilcrow">¶</a></p>
-</li>
-            <li class="normal" id="appendix-A.1.1-4.4">
-              <p id="appendix-A.1.1-4.4.1">Timestamps and execution durations are recorded for each step.<a href="#appendix-A.1.1-4.4.1" class="pilcrow">¶</a></p>
-</li>
-          </ul>
-<p id="appendix-A.1.1-5">This can contribute to compliance with:<a href="#appendix-A.1.1-5" class="pilcrow">¶</a></p>
-<ul class="normal">
-<li class="normal" id="appendix-A.1.1-6.1">
-              <p id="appendix-A.1.1-6.1.1"><span>[<a href="#FDA-21CFR11" class="cite xref">FDA-21CFR11</a>]</span> Section 11.10(e): Computer-generated audit trails
-that record the date, time, and identity of the operator.<a href="#appendix-A.1.1-6.1.1" class="pilcrow">¶</a></p>
-</li>
-            <li class="normal" id="appendix-A.1.1-6.2">
-              <p id="appendix-A.1.1-6.2.1"><span>[<a href="#EU-MDR" class="cite xref">EU-MDR</a>]</span> Annex II: Technical documentation traceability for the
-software development lifecycle.<a href="#appendix-A.1.1-6.2.1" class="pilcrow">¶</a></p>
-</li>
-            <li class="normal" id="appendix-A.1.1-6.3">
-              <p id="appendix-A.1.1-6.3.1"><span>[<a href="#EU-AI-ACT" class="cite xref">EU-AI-ACT</a>]</span> Article 12: Automatic logging capabilities for
-high-risk AI systems involved in the development process.<a href="#appendix-A.1.1-6.3.1" class="pilcrow">¶</a></p>
-</li>
-            <li class="normal" id="appendix-A.1.1-6.4">
-              <p id="appendix-A.1.1-6.4.1"><span>[<a href="#EU-AI-ACT" class="cite xref">EU-AI-ACT</a>]</span> Article 14: ECTs can record evidence that human
-oversight events occurred during the release process.<a href="#appendix-A.1.1-6.4.1" class="pilcrow">¶</a></p>
-</li>
-          </ul>
-</section>
-</div>
-</section>
-</div>
 <div id="cross-organization-financial-trading">
-<section id="appendix-A.2">
+<section id="appendix-A.1">
         <h3 id="name-cross-organization-financia">
 <a href="#name-cross-organization-financia" class="section-name selfRef">Cross-Organization Financial Trading</a>
         </h3>
-<p id="appendix-A.2-1">In a cross-organization trading workflow, an investment bank's
+<p id="appendix-A.1-1">In a cross-organization trading workflow, an investment bank's
 agents coordinate with an external credit rating agency.  The
 agents operate in separate trust domains with a federation
 relationship.  The DAG records that independent assessments from
-both organizations were completed before trade execution.<a href="#appendix-A.2-1" class="pilcrow">¶</a></p>
+both organizations were completed before trade execution.<a href="#appendix-A.1-1" class="pilcrow">¶</a></p>
 <span id="name-cross-organization-trading-"></span><div id="fig-finance">
-<figure id="figure-10">
-          <div class="alignLeft art-text artwork" id="appendix-A.2-2.1">
+<figure id="figure-6">
+          <div class="alignLeft art-text artwork" id="appendix-A.1-2.1">
 <pre>
 Trust Domain: bank.example
   Agent A1 (Portfolio Risk):
@@ -3530,14 +3057,14 @@ Trust Domain: bank.example
     exec_act: execute_trade
 </pre>
 </div>
-<figcaption><a href="#figure-10" class="selfRef">Figure 10</a>:
+<figcaption><a href="#figure-6" class="selfRef">Figure 6</a>:
 <a href="#name-cross-organization-trading-" class="selfRef">Cross-Organization Trading Workflow</a>
           </figcaption></figure>
 </div>
-<p id="appendix-A.2-3">The resulting DAG:<a href="#appendix-A.2-3" class="pilcrow">¶</a></p>
+<p id="appendix-A.1-3">The resulting DAG:<a href="#appendix-A.1-3" class="pilcrow">¶</a></p>
 <span id="name-cross-organization-dag"></span><div id="fig-finance-dag">
-<figure id="figure-11">
-          <div class="alignLeft art-text artwork" id="appendix-A.2-4.1">
+<figure id="figure-7">
+          <div class="alignLeft art-text artwork" id="appendix-A.1-4.1">
 <pre>
 task-001 (analyze_portfolio_risk)   task-002 (assess_credit_rating)
   [bank.example]                      [ratings.example]
@@ -3551,81 +3078,14 @@ task-001 (analyze_portfolio_risk)   task-002 (assess_credit_rating)
            [bank.example]
 </pre>
 </div>
-<figcaption><a href="#figure-11" class="selfRef">Figure 11</a>:
+<figcaption><a href="#figure-7" class="selfRef">Figure 7</a>:
 <a href="#name-cross-organization-dag" class="selfRef">Cross-Organization DAG</a>
           </figcaption></figure>
 </div>
-<p id="appendix-A.2-5">Task 003 has two parents from different trust domains,
+<p id="appendix-A.1-5">Task 003 has two parents from different trust domains,
 demonstrating cross-organizational fan-in.  The compliance agent
 verifies both parent ECTs — one signed by a local key and one by
-a federated key from the rating agency's trust domain.<a href="#appendix-A.2-5" class="pilcrow">¶</a></p>
-<p id="appendix-A.2-6">This can contribute to compliance with:<a href="#appendix-A.2-6" class="pilcrow">¶</a></p>
-<ul class="normal">
-<li class="normal" id="appendix-A.2-7.1">
-            <p id="appendix-A.2-7.1.1"><span>[<a href="#MIFID-II" class="cite xref">MIFID-II</a>]</span>: ECTs provide cryptographic records of the execution
-sequence that can support transaction audit requirements.<a href="#appendix-A.2-7.1.1" class="pilcrow">¶</a></p>
-</li>
-          <li class="normal" id="appendix-A.2-7.2">
-            <p id="appendix-A.2-7.2.1"><span>[<a href="#DORA" class="cite xref">DORA</a>]</span> Article 12: ECTs contribute to ICT activity logging.<a href="#appendix-A.2-7.2.1" class="pilcrow">¶</a></p>
-</li>
-          <li class="normal" id="appendix-A.2-7.3">
-            <p id="appendix-A.2-7.3.1"><span>[<a href="#EU-AI-ACT" class="cite xref">EU-AI-ACT</a>]</span> Article 12: Logging of decisions made by AI-driven
-systems.<a href="#appendix-A.2-7.3.1" class="pilcrow">¶</a></p>
-</li>
-        </ul>
-</section>
-</div>
-<div id="compensation-and-rollback">
-<section id="appendix-A.3">
-        <h3 id="name-compensation-and-rollback-2">
-<a href="#name-compensation-and-rollback-2" class="section-name selfRef">Compensation and Rollback</a>
-        </h3>
-<p id="appendix-A.3-1">Compensation and rollback use cases are described in
-<span>[<a href="#I-D.nennemann-wimse-ect-pol" class="cite xref">I-D.nennemann-wimse-ect-pol</a>]</span>.  The core
-ECT mechanism supports compensation through the "par" claim,
-which links a remediation ECT to the original task.<a href="#appendix-A.3-1" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="autonomous-logistics-coordination">
-<section id="appendix-A.4">
-        <h3 id="name-autonomous-logistics-coordi">
-<a href="#name-autonomous-logistics-coordi" class="section-name selfRef">Autonomous Logistics Coordination</a>
-        </h3>
-<p id="appendix-A.4-1">In a logistics workflow, multiple compliance checks complete
-before shipment commitment.  The DAG structure records that all
-required checks were completed:<a href="#appendix-A.4-1" class="pilcrow">¶</a></p>
-<span id="name-logistics-workflow-with-par"></span><div id="fig-logistics">
-<figure id="figure-12">
-          <div class="alignLeft art-text artwork" id="appendix-A.4-2.1">
-<pre>
-Agent A (Route Planning):
-  jti: task-001    par: []
-  exec_act: plan_route
-
-Agent B (Customs):
-  jti: task-002    par: [task-001]
-  exec_act: validate_customs
-
-Agent C (Safety):
-  jti: task-003    par: [task-001]
-  exec_act: verify_cargo_safety
-
-Agent D (Payment):
-  jti: task-004    par: [task-002, task-003]
-  exec_act: authorize_payment
-
-System (Commitment):
-  jti: task-005    par: [task-004]
-  exec_act: commit_shipment
-</pre>
-</div>
-<figcaption><a href="#figure-12" class="selfRef">Figure 12</a>:
-<a href="#name-logistics-workflow-with-par" class="selfRef">Logistics Workflow with Parallel Tasks</a>
-          </figcaption></figure>
-</div>
-<p id="appendix-A.4-3">Note that tasks 002 and 003 both depend only on task-001 and can
-execute in parallel.  Task 004 depends on both, demonstrating the
-DAG's ability to represent parallel execution with a join point.<a href="#appendix-A.4-3" class="pilcrow">¶</a></p>
+a federated key from the rating agency's trust domain.<a href="#appendix-A.1-5" class="pilcrow">¶</a></p>
 </section>
 </div>
 </section>
@@ -3661,7 +3121,8 @@ delegation chain: "who is acting on behalf of whom."  While
 the nesting superficially resembles a chain, it is strictly
 linear (each "act" object contains at most one nested "act"),
 represents authorization delegation rather than task execution,
-and carries no task identifiers or input/output integrity data.  The "act" chain cannot represent
+and carries no task identifiers or input/output integrity
+data.  The "act" chain cannot represent
 branching (fan-out) or convergence (fan-in) and therefore
 cannot form a DAG.<a href="#appendix-B.2-1" class="pilcrow">¶</a></p>
 <p id="appendix-B.2-2">ECTs intentionally use the distinct claim name "exec_act" for the
@@ -3733,455 +3194,34 @@ ECTs may reference OpenTelemetry trace identifiers in the "ext"
 claim for correlation.<a href="#appendix-B.4-1" class="pilcrow">¶</a></p>
 </section>
 </div>
-<div id="blockchain-and-distributed-ledgers">
-<section id="appendix-B.5">
-        <h3 id="name-blockchain-and-distributed-">
-<a href="#name-blockchain-and-distributed-" class="section-name selfRef">Blockchain and Distributed Ledgers</a>
-        </h3>
-<p id="appendix-B.5-1">Both ECTs and blockchain systems provide immutable records.  This
-specification intentionally defines only the ECT token format and
-is agnostic to the storage mechanism.  ECTs can be stored in
-append-only logs, databases with cryptographic commitments,
-blockchain networks, or any storage providing the required
-properties defined in <a href="#ledger-interface" class="auto internal xref">Section 8</a>.<a href="#appendix-B.5-1" class="pilcrow">¶</a></p>
-</section>
-</div>
 <div id="scitt-supply-chain-integrity-transparency-and-trust">
-<section id="appendix-B.6">
+<section id="appendix-B.5">
         <h3 id="name-scitt-supply-chain-integrit">
 <a href="#name-scitt-supply-chain-integrit" class="section-name selfRef">SCITT (Supply Chain Integrity, Transparency, and Trust)</a>
         </h3>
-<p id="appendix-B.6-1">The SCITT architecture <span>[<a href="#I-D.ietf-scitt-architecture" class="cite xref">I-D.ietf-scitt-architecture</a>]</span> defines a
-framework for creating transparent and auditable supply chain
-records through Transparency Services, Signed Statements, and
-Receipts.  ECTs and SCITT are naturally complementary: the ECT
-"wid" (Workflow Identifier) claim can serve as a correlation
-identifier referenced in SCITT Signed Statements, linking a
-complete ECT audit trail to a supply chain transparency record.
-For example, in a regulated manufacturing workflow, each agent
-step produces an ECT (recording what was done, by whom, under
-under what constraints), while the overall workflow identified by "wid" is
-registered as a SCITT Signed Statement on a Transparency Service.
-This enables auditors to verify both the individual execution
-steps (via ECT DAG validation) and the end-to-end supply chain
-integrity (via SCITT Receipts) using the "wid" as the shared
-correlation point.  The "ext" claim in ECTs (<a href="#exec-claims" class="auto internal xref">Section 4.2.2</a>)
-can carry SCITT-specific metadata such as Transparency Service
-identifiers or Receipt references for tighter integration.<a href="#appendix-B.6-1" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="w3c-verifiable-credentials">
-<section id="appendix-B.7">
-        <h3 id="name-w3c-verifiable-credentials">
-<a href="#name-w3c-verifiable-credentials" class="section-name selfRef">W3C Verifiable Credentials</a>
-        </h3>
-<p id="appendix-B.7-1">W3C Verifiable Credentials represent claims about subjects (e.g.,
-identity, qualifications).  ECTs represent execution records of
-actions (what happened, in what order).  While
-both use JWT/JWS as a serialization format, their semantics and
-use cases are distinct.<a href="#appendix-B.7-1" class="pilcrow">¶</a></p>
-</section>
-</div>
-</section>
-</div>
-<div id="implementation-guidance">
-<section id="appendix-C">
-      <h2 id="name-implementation-guidance">
-<a href="#name-implementation-guidance" class="section-name selfRef">Implementation Guidance</a>
-      </h2>
-<div id="minimal-implementation">
-<section id="appendix-C.1">
-        <h3 id="name-minimal-implementation">
-<a href="#name-minimal-implementation" class="section-name selfRef">Minimal Implementation</a>
-        </h3>
-<p id="appendix-C.1-1">A minimal conforming implementation needs to:<a href="#appendix-C.1-1" class="pilcrow">¶</a></p>
-<ol start="1" type="1" class="normal type-1" id="appendix-C.1-2">
-<li id="appendix-C.1-2.1">
-            <p id="appendix-C.1-2.1.1">Create JWTs with all required claims ("iss", "aud", "iat",
-"exp", "jti", "exec_act", "par").<a href="#appendix-C.1-2.1.1" class="pilcrow">¶</a></p>
-</li>
-          <li id="appendix-C.1-2.2">
-            <p id="appendix-C.1-2.2.1">Sign ECTs with the agent's private key using an algorithm
-matching the WIT (ES256 recommended).<a href="#appendix-C.1-2.2.1" class="pilcrow">¶</a></p>
-</li>
-          <li id="appendix-C.1-2.3">
-            <p id="appendix-C.1-2.3.1">Verify ECT signatures against WIT public keys.<a href="#appendix-C.1-2.3.1" class="pilcrow">¶</a></p>
-</li>
-          <li id="appendix-C.1-2.4">
-            <p id="appendix-C.1-2.4.1">Perform DAG validation (parent existence, temporal ordering,
-cycle detection).<a href="#appendix-C.1-2.4.1" class="pilcrow">¶</a></p>
-</li>
-          <li id="appendix-C.1-2.5">
-            <p id="appendix-C.1-2.5.1">If an audit ledger is deployed, append verified ECTs to it.<a href="#appendix-C.1-2.5.1" class="pilcrow">¶</a></p>
-</li>
-        </ol>
-</section>
-</div>
-<div id="storage-recommendations">
-<section id="appendix-C.2">
-        <h3 id="name-storage-recommendations">
-<a href="#name-storage-recommendations" class="section-name selfRef">Storage Recommendations</a>
-        </h3>
-<ul class="normal">
-<li class="normal" id="appendix-C.2-1.1">
-            <p id="appendix-C.2-1.1.1">Append-only log: Simplest approach; immutability by design.<a href="#appendix-C.2-1.1.1" class="pilcrow">¶</a></p>
-</li>
-          <li class="normal" id="appendix-C.2-1.2">
-            <p id="appendix-C.2-1.2.1">Database with hash chains: Periodic cryptographic commitments
-over batches of entries.<a href="#appendix-C.2-1.2.1" class="pilcrow">¶</a></p>
-</li>
-          <li class="normal" id="appendix-C.2-1.3">
-            <p id="appendix-C.2-1.3.1">Distributed ledger: Maximum immutability guarantees for
-cross-organizational audit.<a href="#appendix-C.2-1.3.1" class="pilcrow">¶</a></p>
-</li>
-          <li class="normal" id="appendix-C.2-1.4">
-            <p id="appendix-C.2-1.4.1">Hybrid: Hot storage in a database, cold archive in immutable
-storage.<a href="#appendix-C.2-1.4.1" class="pilcrow">¶</a></p>
-</li>
-        </ul>
-</section>
-</div>
-<div id="performance-considerations">
-<section id="appendix-C.3">
-        <h3 id="name-performance-considerations">
-<a href="#name-performance-considerations" class="section-name selfRef">Performance Considerations</a>
-        </h3>
-<ul class="normal">
-<li class="normal" id="appendix-C.3-1.1">
-            <p id="appendix-C.3-1.1.1">ES256 signature verification: approximately 1ms per ECT on
-modern hardware.<a href="#appendix-C.3-1.1.1" class="pilcrow">¶</a></p>
-</li>
-          <li class="normal" id="appendix-C.3-1.2">
-            <p id="appendix-C.3-1.2.1">DAG validation: O(V) where V is the number of reachable ancestor
-nodes (typically small for shallow workflows).<a href="#appendix-C.3-1.2.1" class="pilcrow">¶</a></p>
-</li>
-          <li class="normal" id="appendix-C.3-1.3">
-            <p id="appendix-C.3-1.3.1">JSON serialization: sub-millisecond per ECT.<a href="#appendix-C.3-1.3.1" class="pilcrow">¶</a></p>
-</li>
-          <li class="normal" id="appendix-C.3-1.4">
-            <p id="appendix-C.3-1.4.1">Total per-request overhead: approximately 5-10ms, acceptable
-for regulated workflows where correctness is prioritized over
-latency.<a href="#appendix-C.3-1.4.1" class="pilcrow">¶</a></p>
-</li>
-        </ul>
-</section>
-</div>
-<div id="interoperability">
-<section id="appendix-C.4">
-        <h3 id="name-interoperability">
-<a href="#name-interoperability" class="section-name selfRef">Interoperability</a>
-        </h3>
-<p id="appendix-C.4-1">Implementations are expected to use established JWT/JWS libraries
-(JOSE) for token creation and verification.  Custom cryptographic
-implementations are strongly discouraged.  Implementations are
-expected to be tested against multiple JWT libraries to ensure
-interoperability.<a href="#appendix-C.4-1" class="pilcrow">¶</a></p>
-</section>
-</div>
-</section>
-</div>
-<div id="regulatory-compliance-mapping">
-<section id="appendix-D">
-      <h2 id="name-regulatory-compliance-mappi">
-<a href="#name-regulatory-compliance-mappi" class="section-name selfRef">Regulatory Compliance Mapping</a>
-      </h2>
-<p id="appendix-D-1">The following table summarizes how ECTs can contribute to
-compliance with various regulatory frameworks.  ECTs are a
-technical building block; achieving compliance requires
-additional organizational measures beyond this specification.<a href="#appendix-D-1" class="pilcrow">¶</a></p>
-<span id="name-regulatory-compliance-mappin"></span><div id="_table-regulatory">
-<table class="center" id="table-2">
-        <caption>
-<a href="#table-2" class="selfRef">Table 2</a>:
-<a href="#name-regulatory-compliance-mappin" class="selfRef">Regulatory Compliance Mapping</a>
-        </caption>
-<thead>
-          <tr>
-            <th class="text-left" rowspan="1" colspan="1">Regulation</th>
-            <th class="text-left" rowspan="1" colspan="1">Requirement</th>
-            <th class="text-left" rowspan="1" colspan="1">ECT Contribution</th>
-          </tr>
-        </thead>
-        <tbody>
-          <tr>
-            <td class="text-left" rowspan="1" colspan="1">FDA 21 CFR Part 11</td>
-            <td class="text-left" rowspan="1" colspan="1">Audit trails recording date, time, operator, actions (11.10(e))</td>
-            <td class="text-left" rowspan="1" colspan="1">Cryptographic signatures and append-only ledger contribute to audit trail requirements</td>
-          </tr>
-          <tr>
-            <td class="text-left" rowspan="1" colspan="1">EU MDR</td>
-            <td class="text-left" rowspan="1" colspan="1">Technical documentation traceability (Annex II)</td>
-            <td class="text-left" rowspan="1" colspan="1">ECTs provide signed records of AI-assisted decision sequences</td>
-          </tr>
-          <tr>
-            <td class="text-left" rowspan="1" colspan="1">EU AI Act Art. 12</td>
-            <td class="text-left" rowspan="1" colspan="1">Automatic logging capabilities for high-risk AI</td>
-            <td class="text-left" rowspan="1" colspan="1">ECTs contribute cryptographic activity logging</td>
-          </tr>
-          <tr>
-            <td class="text-left" rowspan="1" colspan="1">EU AI Act Art. 14</td>
-            <td class="text-left" rowspan="1" colspan="1">Human oversight capability</td>
-            <td class="text-left" rowspan="1" colspan="1">ECTs can record evidence that human oversight events occurred</td>
-          </tr>
-          <tr>
-            <td class="text-left" rowspan="1" colspan="1">MiFID II</td>
-            <td class="text-left" rowspan="1" colspan="1">Transaction records for supervisory authorities</td>
-            <td class="text-left" rowspan="1" colspan="1">ECTs provide cryptographic execution sequence records</td>
-          </tr>
-          <tr>
-            <td class="text-left" rowspan="1" colspan="1">DORA Art. 12</td>
-            <td class="text-left" rowspan="1" colspan="1">ICT activity logging policies</td>
-            <td class="text-left" rowspan="1" colspan="1">ECT ledger contributes to ICT activity audit trail</td>
-          </tr>
-        </tbody>
-      </table>
-</div>
-</section>
-</div>
-<div id="examples">
-<section id="appendix-E">
-      <h2 id="name-examples">
-<a href="#name-examples" class="section-name selfRef">Examples</a>
-      </h2>
-<div id="example-1-simple-two-agent-workflow">
-<section id="appendix-E.1">
-        <h3 id="name-example-1-simple-two-agent-">
-<a href="#name-example-1-simple-two-agent-" class="section-name selfRef">Example 1: Simple Two-Agent Workflow</a>
-        </h3>
-<p id="appendix-E.1-1">Agent A executes a data retrieval task and sends the ECT to
-Agent B:<a href="#appendix-E.1-1" class="pilcrow">¶</a></p>
-<p id="appendix-E.1-2">ECT JOSE Header:<a href="#appendix-E.1-2" class="pilcrow">¶</a></p>
-<div class="lang-json sourcecode" id="appendix-E.1-3">
-<pre>
-{
-  "alg": "ES256",
-  "typ": "wimse-exec+jwt",
-  "kid": "agent-a-key-2026-02"
-}
-</pre><a href="#appendix-E.1-3" class="pilcrow">¶</a>
-</div>
-<p id="appendix-E.1-4">ECT Payload:<a href="#appendix-E.1-4" class="pilcrow">¶</a></p>
-<div class="lang-json sourcecode" id="appendix-E.1-5">
-<pre>
-{
-  "iss": "spiffe://example.com/agent/data-retrieval",
-  "aud": "spiffe://example.com/agent/validator",
-  "iat": 1772064150,
-  "exp": 1772064750,
-  "jti": "550e8400-e29b-41d4-a716-446655440001",
-  "wid": "b1c2d3e4-f5a6-7890-bcde-f01234567890",
-  "exec_act": "fetch_patient_data",
-  "par": [],
-  "inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
-  "out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564"
-}
-</pre><a href="#appendix-E.1-5" class="pilcrow">¶</a>
-</div>
-<p id="appendix-E.1-6">Agent B receives the ECT, verifies it, executes a validation
-task, and creates its own ECT:<a href="#appendix-E.1-6" class="pilcrow">¶</a></p>
-<div class="lang-json sourcecode" id="appendix-E.1-7">
-<pre>
-{
-  "iss": "spiffe://example.com/agent/validator",
-  "aud": "spiffe://example.com/system/ledger",
-  "iat": 1772064160,
-  "exp": 1772064760,
-  "jti": "550e8400-e29b-41d4-a716-446655440002",
-  "wid": "b1c2d3e4-f5a6-7890-bcde-f01234567890",
-  "exec_act": "validate_safety",
-  "par": ["550e8400-e29b-41d4-a716-446655440001"]
-}
-</pre><a href="#appendix-E.1-7" class="pilcrow">¶</a>
-</div>
-<p id="appendix-E.1-8">The resulting DAG:<a href="#appendix-E.1-8" class="pilcrow">¶</a></p>
-<div class="alignLeft art-text artwork" id="appendix-E.1-9">
-<pre>
-task-...-0001 (fetch_patient_data)
-  |
-  v
-task-...-0002 (validate_safety)
-</pre><a href="#appendix-E.1-9" class="pilcrow">¶</a>
-</div>
-</section>
-</div>
-<div id="example-2-medical-device-sdlc-with-release-approval">
-<section id="appendix-E.2">
-        <h3 id="name-example-2-medical-device-sd">
-<a href="#name-example-2-medical-device-sd" class="section-name selfRef">Example 2: Medical Device SDLC with Release Approval</a>
-        </h3>
-<p id="appendix-E.2-1">A multi-step medical device software lifecycle workflow with
-autonomous agents and human release approval:<a href="#appendix-E.2-1" class="pilcrow">¶</a></p>
-<p id="appendix-E.2-2">Task 1 (Spec Review Agent):<a href="#appendix-E.2-2" class="pilcrow">¶</a></p>
-<div class="lang-json sourcecode" id="appendix-E.2-3">
-<pre>
-{
-  "iss": "spiffe://meddev.example/agent/spec-reviewer",
-  "aud": "spiffe://meddev.example/agent/code-gen",
-  "iat": 1772064150,
-  "exp": 1772064750,
-  "jti": "a1b2c3d4-0001-0000-0000-000000000001",
-  "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
-  "exec_act": "review_requirements_spec",
-  "par": [],
-  "inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
-  "out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564"
-}
-</pre><a href="#appendix-E.2-3" class="pilcrow">¶</a>
-</div>
-<p id="appendix-E.2-4">Task 2 (Code Generation Agent):<a href="#appendix-E.2-4" class="pilcrow">¶</a></p>
-<div class="lang-json sourcecode" id="appendix-E.2-5">
-<pre>
-{
-  "iss": "spiffe://meddev.example/agent/code-gen",
-  "aud": "spiffe://meddev.example/agent/test-runner",
-  "iat": 1772064200,
-  "exp": 1772064800,
-  "jti": "a1b2c3d4-0001-0000-0000-000000000002",
-  "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
-  "exec_act": "implement_module",
-  "par": ["a1b2c3d4-0001-0000-0000-000000000001"]
-}
-</pre><a href="#appendix-E.2-5" class="pilcrow">¶</a>
-</div>
-<p id="appendix-E.2-6">Task 3 (Autonomous Test Agent):<a href="#appendix-E.2-6" class="pilcrow">¶</a></p>
-<div class="lang-json sourcecode" id="appendix-E.2-7">
-<pre>
-{
-  "iss": "spiffe://meddev.example/agent/test-runner",
-  "aud": "spiffe://meddev.example/agent/build",
-  "iat": 1772064260,
-  "exp": 1772064860,
-  "jti": "a1b2c3d4-0001-0000-0000-000000000003",
-  "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
-  "exec_act": "execute_test_suite",
-  "par": ["a1b2c3d4-0001-0000-0000-000000000002"]
-}
-</pre><a href="#appendix-E.2-7" class="pilcrow">¶</a>
-</div>
-<p id="appendix-E.2-8">Task 4 (Build Agent):<a href="#appendix-E.2-8" class="pilcrow">¶</a></p>
-<div class="lang-json sourcecode" id="appendix-E.2-9">
-<pre>
-{
-  "iss": "spiffe://meddev.example/agent/build",
-  "aud": "spiffe://meddev.example/human/release-mgr-42",
-  "iat": 1772064310,
-  "exp": 1772064910,
-  "jti": "a1b2c3d4-0001-0000-0000-000000000004",
-  "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
-  "exec_act": "build_release_artifact",
-  "par": ["a1b2c3d4-0001-0000-0000-000000000003"],
-  "out_hash": "sha-256:Ry1YfOoW2XpC5Mq8HkGzNx3dL9vBa4sUjE7iKt0wPZc"
-}
-</pre><a href="#appendix-E.2-9" class="pilcrow">¶</a>
-</div>
-<p id="appendix-E.2-10">Task 5 (Human Release Manager Approval):<a href="#appendix-E.2-10" class="pilcrow">¶</a></p>
-<div class="lang-json sourcecode" id="appendix-E.2-11">
-<pre>
-{
-  "iss": "spiffe://meddev.example/human/release-mgr-42",
-  "aud": "spiffe://meddev.example/system/ledger",
-  "iat": 1772064510,
-  "exp": 1772065110,
-  "jti": "a1b2c3d4-0001-0000-0000-000000000005",
-  "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
-  "exec_act": "approve_release",
-  "par": ["a1b2c3d4-0001-0000-0000-000000000004"],
-  "ext": {
-    "witnessed_by": [
-      "spiffe://meddev.example/audit/qa-observer-1"
-    ]
-  }
-}
-</pre><a href="#appendix-E.2-11" class="pilcrow">¶</a>
-</div>
-<p id="appendix-E.2-12">The resulting DAG records the complete SDLC: spec review preceded
-implementation, implementation preceded testing, testing preceded
-build, and a human release manager approved the final release.
-The "ext" object in task 5 carries witness metadata via
-the "witnessed_by" extension key.<a href="#appendix-E.2-12" class="pilcrow">¶</a></p>
-<div class="alignLeft art-text artwork" id="appendix-E.2-13">
-<pre>
-task-...-0001 (review_requirements_spec)
-  |
-  v
-task-...-0002 (implement_module)
-  |
-  v
-task-...-0003 (execute_test_suite)
-  |
-  v
-task-...-0004 (build_release_artifact)
-  |
-  v
-task-...-0005 (approve_release) [human]
-</pre><a href="#appendix-E.2-13" class="pilcrow">¶</a>
-</div>
-<p id="appendix-E.2-14">An FDA auditor reconstructs this DAG by querying the audit ledger
-for all ECTs with wid "c2d3e4f5-a6b7-8901-cdef-012345678901" and
-verifying each signature.  The DAG provides cryptographic evidence
-that the SDLC followed the prescribed process with human oversight
-at the release gate.<a href="#appendix-E.2-14" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="example-3-parallel-execution-with-join">
-<section id="appendix-E.3">
-        <h3 id="name-example-3-parallel-executio">
-<a href="#name-example-3-parallel-executio" class="section-name selfRef">Example 3: Parallel Execution with Join</a>
-        </h3>
-<p id="appendix-E.3-1">A workflow where two tasks execute in parallel and a third task
-depends on both:<a href="#appendix-E.3-1" class="pilcrow">¶</a></p>
-<div class="alignLeft art-text artwork" id="appendix-E.3-2">
-<pre>
-task-...-0001 (assess_risk)
-  |            \
-  v             v
-task-...-0002  task-...-0003
-(check         (verify
-compliance)    liquidity)
-  |            /
-  v           v
-task-...-0004 (execute_trade)
-</pre><a href="#appendix-E.3-2" class="pilcrow">¶</a>
-</div>
-<p id="appendix-E.3-3">Task 004 ECT payload:<a href="#appendix-E.3-3" class="pilcrow">¶</a></p>
-<div class="lang-json sourcecode" id="appendix-E.3-4">
-<pre>
-{
-  "iss": "spiffe://bank.example/agent/execution",
-  "aud": "spiffe://bank.example/system/ledger",
-  "iat": 1772064250,
-  "exp": 1772064850,
-  "jti": "f1e2d3c4-0004-0000-0000-000000000004",
-  "wid": "d3e4f5a6-b7c8-9012-def0-123456789012",
-  "exec_act": "execute_trade",
-  "par": [
-    "f1e2d3c4-0002-0000-0000-000000000002",
-    "f1e2d3c4-0003-0000-0000-000000000003"
-  ]
-}
-</pre><a href="#appendix-E.3-4" class="pilcrow">¶</a>
-</div>
-<p id="appendix-E.3-5">The "par" array with two entries records that both compliance
-checking and liquidity verification were completed before trade
-execution.<a href="#appendix-E.3-5" class="pilcrow">¶</a></p>
+<p id="appendix-B.5-1">The SCITT architecture <span>[<a href="#I-D.ietf-scitt-architecture" class="cite xref">I-D.ietf-scitt-architecture</a>]</span> defines a
+framework for transparent and auditable supply chain records.
+ECTs and SCITT are complementary: the ECT "wid" claim can serve
+as a correlation identifier in SCITT Signed Statements, linking
+an ECT audit trail to a supply chain transparency record.<a href="#appendix-B.5-1" class="pilcrow">¶</a></p>
 </section>
 </div>
 </section>
 </div>
 <div id="acknowledgments">
-<section id="appendix-F">
+<section id="appendix-C">
       <h2 id="name-acknowledgments">
 <a href="#name-acknowledgments" class="section-name selfRef">Acknowledgments</a>
       </h2>
-<p id="appendix-F-1">The author thanks the WIMSE working group for their foundational
+<p id="appendix-C-1">The author thanks the WIMSE working group for their foundational
 work on workload identity in multi-system environments.  The
 concepts of Workload Identity Tokens and Workload Proof Tokens
 provide the identity foundation upon which execution context
-tracing is built.<a href="#appendix-F-1" class="pilcrow">¶</a></p>
+tracing is built.<a href="#appendix-C-1" class="pilcrow">¶</a></p>
 </section>
 </div>
 <div id="authors-addresses">
-<section id="appendix-G">
+<section id="appendix-D">
       <h2 id="name-authors-address">
 <a href="#name-authors-address" class="section-name selfRef">Author's Address</a>
       </h2>
diff --git a/draft-nennemann-wimse-ect-00.md b/draft-nennemann-wimse-ect-00.md
index b2a1ab4..f6f6901 100644
--- a/draft-nennemann-wimse-ect-00.md
+++ b/draft-nennemann-wimse-ect-00.md
@@ -14,8 +14,6 @@ keyword:
   - workload identity
   - agentic workflows
   - audit trail
-  - compliance
-  - regulated systems
 
 author:
   -
@@ -38,46 +36,10 @@ informative:
   RFC8693:
   RFC9421:
   I-D.ni-wimse-ai-agent-identity:
-  I-D.nennemann-wimse-ect-pol:
-    title: "Policy Evaluation and Compensation Extensions for Execution Context Tokens"
-    target: https://datatracker.ietf.org/doc/draft-nennemann-wimse-ect-pol/
-    date: false
-    author:
-      - fullname: Christian Nennemann
   SPIFFE:
     title: "Secure Production Identity Framework for Everyone (SPIFFE)"
     target: https://spiffe.io/docs/latest/spiffe-about/overview/
     date: false
-  EU-AI-ACT:
-    title: "Regulation (EU) 2024/1689 of the European Parliament and of the Council laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)"
-    target: https://eur-lex.europa.eu/eli/reg/2024/1689
-    date: 2024-06-13
-    author:
-      - org: European Parliament and Council of the European Union
-  FDA-21CFR11:
-    title: "Title 21, Code of Federal Regulations, Part 11: Electronic Records; Electronic Signatures"
-    target: https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11
-    date: false
-    author:
-      - org: U.S. Food and Drug Administration
-  MIFID-II:
-    title: "Directive 2014/65/EU of the European Parliament and of the Council on markets in financial instruments (MiFID II)"
-    target: https://eur-lex.europa.eu/eli/dir/2014/65
-    date: 2014-05-15
-    author:
-      - org: European Parliament and Council of the European Union
-  DORA:
-    title: "Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA)"
-    target: https://eur-lex.europa.eu/eli/reg/2022/2554
-    date: 2022-12-14
-    author:
-      - org: European Parliament and Council of the European Union
-  EU-MDR:
-    title: "Regulation (EU) 2017/745 on medical devices (MDR)"
-    target: https://eur-lex.europa.eu/eli/reg/2017/745
-    date: 2017-04-05
-    author:
-      - org: European Parliament and Council of the European Union
   OPENTELEMETRY:
     title: "OpenTelemetry Specification"
     target: https://opentelemetry.io/docs/specs/otel/
@@ -92,23 +54,17 @@ informative:
 
 This document defines Execution Context Tokens (ECTs), an extension
 to the Workload Identity in Multi System Environments (WIMSE)
-architecture for distributed agentic workflows in regulated
-environments.  ECTs provide signed, structured records of task
-execution order and compliance state across agent-to-agent
-communication.  By extending WIMSE Workload Identity
+architecture for distributed agentic workflows.  ECTs provide
+signed, structured records of task execution order across
+agent-to-agent communication.  By extending WIMSE Workload Identity
 Tokens with execution context claims in JSON Web Token (JWT)
-format, this specification enables regulated systems to maintain
-structured audit trails that support compliance verification.
-ECTs use a directed acyclic graph (DAG) structure to represent task
-dependencies and integrate with WIMSE Workload Identity Tokens (WIT)
-using the same signing model and cryptographic primitives.
-Policy evaluation and compensation extensions are defined in
-{{I-D.nennemann-wimse-ect-pol}}.  A new
-HTTP header field,
+format, this specification enables systems to maintain structured
+audit trails of agent execution.  ECTs use a directed acyclic
+graph (DAG) structure to represent task dependencies and integrate
+with WIMSE Workload Identity Tokens (WIT) using the same signing
+model and cryptographic primitives.  A new HTTP header field,
 Execution-Context, is defined for transporting ECTs alongside
-existing WIMSE headers.  ECTs are a technical building block that
-supports, but does not by itself constitute, compliance with
-regulatory frameworks.
+existing WIMSE headers.
 
 --- middle
 
@@ -132,8 +88,6 @@ Regulated environments increasingly deploy autonomous agents that
 coordinate across organizational boundaries.  Domains such as
 healthcare, finance, and logistics require structured, auditable
 records of automated decision-making and execution.
-{{table-regulatory}} in the appendix illustrates how ECTs relate
-to specific regulatory frameworks.
 
 This document defines an extension to the WIMSE architecture that
 addresses the gap between workload identity and execution
@@ -176,8 +130,6 @@ This document defines:
   ({{wimse-integration}})
 - An HTTP header for ECT transport ({{http-header}})
 - Audit ledger interface requirements ({{ledger-interface}})
-- Policy evaluation and compensation extensions are defined
-  separately in {{I-D.nennemann-wimse-ect-pol}}
 
 The following are out of scope and are handled by WIMSE:
 
@@ -186,26 +138,6 @@ The following are out of scope and are handled by WIMSE:
 - Trust domain establishment and management
 - Credential lifecycle management
 
-## Relationship to Regulatory Compliance
-
-ECTs are a technical mechanism that can support compliance programs
-by providing structured, cryptographically signed execution
-records.  ECTs do not by themselves constitute compliance with any
-regulatory framework referenced in this document.
-
-Compliance with each referenced regulation requires organizational
-controls, policies, procedures, validation, and governance measures
-beyond the scope of this specification.  The regulatory references
-in this document are intended to motivate the design requirements,
-not to claim that implementing ECTs satisfies these regulations.
-
-ECTs provide evidence of claimed execution ordering.  They do not
-independently verify that the claimed execution actually occurred
-as described or that the agent faithfully performed the stated
-action.  The trustworthiness of ECT claims depends on the
-trustworthiness of the signing agent and the integrity of the
-broader deployment environment.
-
 # Conventions and Definitions
 
 {::boilerplate bcp14-tagged}
@@ -230,8 +162,7 @@ Execution Context Token (ECT):
 
 Audit Ledger:
 : An append-only, immutable log of all ECTs within a workflow or
-  set of workflows, used for regulatory audit and compliance
-  verification.
+  set of workflows, used for audit and verification.
 
 Workload Identity Token (WIT):
 : A WIMSE credential proving a workload's identity within a trust
@@ -246,10 +177,6 @@ Trust Domain:
   shared identity issuer, corresponding to a SPIFFE {{SPIFFE}}
   trust domain.
 
-Witness:
-: A third-party entity that observes and attests to the execution
-  of a task, providing additional accountability.
-
 # WIMSE Architecture Integration {#wimse-integration}
 
 ## WIMSE Foundation
@@ -351,8 +278,10 @@ The receiving agent (Agent B) verifies in order:
 # Execution Context Token Format {#ect-format}
 
 An Execution Context Token is a JSON Web Token (JWT) {{RFC7519}}
-signed as a JSON Web Signature (JWS) {{RFC7515}} using the Compact
-Serialization.  JWS JSON Serialization MUST NOT be used for ECTs.
+signed as a JSON Web Signature (JWS) {{RFC7515}}.  ECTs MUST use
+JWS Compact Serialization (the base64url-encoded
+`header.payload.signature` format) so that they can be carried in
+a single HTTP header value.
 
 ## JOSE Header {#jose-header}
 
@@ -481,7 +410,10 @@ par:
   representing DAG dependencies.  Each element MUST be the "jti"
   value of a previously verified ECT.  An empty array indicates
   a root task with no dependencies.  A workflow MAY contain
-  multiple root tasks.
+  multiple root tasks.  Parent ECTs may have passed their own
+  "exp" time; ECT expiration applies to the verification window
+  of the ECT itself, not to its validity as a parent reference
+  in the ECT store.
 
 ### Data Integrity {#data-integrity-claims}
 
@@ -504,14 +436,6 @@ out_hash:
 : OPTIONAL.  String.  A cryptographic hash of the output data,
   using the same format and algorithm requirements as "inp_hash".
 
-### Compensation and Rollback {#compensation-claims}
-
-Compensation and rollback extensions are defined in
-{{I-D.nennemann-wimse-ect-pol}}.  The referenced
-parent ECTs may have passed their own "exp" time; ECT expiration
-applies to the verification window of the ECT itself, not to its
-validity as a parent reference in the ECT store.
-
 ### Extensions {#extension-claims}
 
 ext:
@@ -529,23 +453,8 @@ nesting depth within the "ext" object SHOULD NOT exceed 5
 levels.  Implementations SHOULD reject ECTs whose "ext" claim
 exceeds these limits.
 
-The following extension keys are defined by this specification
-for common use cases.  Because these keys are documented here,
-they use short names without reverse domain prefixes:
-
-- "exec\_time\_ms": Integer.  Execution duration in milliseconds.
-- "regulated\_domain": String.  Regulatory domain (e.g.,
-  "medtech", "finance", "military").
-- "model\_version": String.  AI/ML model version.
-- "witnessed\_by": Array of StringOrURI.  Identifiers of
-  third-party entities that the issuer claims observed the
-  task.  Note: this is self-asserted; for verifiable witness
-  attestation, witnesses should submit independent signed ECTs.
-- "inp\_classification": String.  Data sensitivity classification
-  (e.g., "public", "confidential", "restricted").
-
-Additional extension keys for policy evaluation and compensation
-are defined in {{I-D.nennemann-wimse-ect-pol}}.
+Extension keys for domain-specific use cases MAY be defined in
+future documents.
 
 ## Complete ECT Example
 
@@ -564,13 +473,7 @@ The following is a complete ECT payload example:
   "par": [],
 
   "inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
-  "out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564",
-
-  "ext": {
-    "exec_time_ms": 245,
-    "regulated_domain": "medtech",
-    "model_version": "clinical-reasoning-v4.2"
-  }
+  "out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564"
 }
 ~~~
 {: #fig-full-ect title="Complete ECT Payload Example"}
@@ -659,63 +562,10 @@ the following DAG validation steps:
     same trust domain or to a trust domain with which a federation
     relationship has been established.
 
-## DAG Validation Algorithm
-
-The following pseudocode describes the DAG validation procedure:
-
-~~~ pseudocode
-function validate_dag(ect, ect_store, clock_skew_tolerance):
-  // Step 1: Uniqueness check
-  if ect_store.contains(ect.jti, ect.wid):
-    return error("ECT ID already exists")
-
-  // Step 2: Parent existence and temporal ordering
-  for parent_id in ect.par:
-    parent = ect_store.get(parent_id)
-    if parent is null:
-      return error("Parent task not found: " + parent_id)
-    if parent.iat >= ect.iat + clock_skew_tolerance:
-      return error("Parent task not earlier than current")
-
-  // Step 3: Cycle detection (with traversal limit)
-  visited = set()
-  result = has_cycle(ect.jti, ect.par, ect_store, visited,
-                      max_ancestor_limit)
-  if result is error or result is true:
-    return error("Circular dependency or depth limit exceeded")
-
-  return success
-
-function has_cycle(target_jti, parent_ids, ect_store,
-                   visited, max_depth):
-  if visited.size() >= max_depth:
-    return error("Maximum ancestor traversal limit exceeded")
-  for parent_id in parent_ids:
-    if parent_id == target_jti:
-      return true
-    if parent_id in visited:
-      continue
-    visited.add(parent_id)
-    parent = ect_store.get(parent_id)
-    if parent is not null:
-      result = has_cycle(target_jti, parent.par, ect_store,
-                          visited, max_depth)
-      if result is error or result is true:
-        return result
-  return false
-~~~
-{: #fig-dag-validation title="DAG Validation Pseudocode"}
-
-The cycle detection traverses the ancestor graph rooted at the
-current task's parents.  The complexity is O(V) where V is the
-number of ancestor nodes reachable from the current task's parent
-references.  For typical workflows with shallow DAGs, this is
-efficient.  To prevent denial-of-service via extremely deep or
-wide DAGs, implementations SHOULD enforce a maximum ancestor
-traversal limit (RECOMMENDED: 10000 nodes).  If the limit is
-reached before cycle detection completes, the ECT SHOULD be
-rejected.  Implementations SHOULD cache cycle detection results
-for previously verified tasks to avoid redundant traversals.
+To prevent denial-of-service via extremely deep or wide DAGs,
+implementations SHOULD enforce a maximum ancestor traversal limit
+(RECOMMENDED: 10000 nodes).  If the limit is reached before cycle
+detection completes, the ECT SHOULD be rejected.
 
 # Signature and Token Verification {#verification}
 
@@ -787,76 +637,6 @@ revealing which specific verification step failed.  The receiving
 agent MUST NOT process the requested action when ECT verification
 fails.
 
-## Verification Pseudocode
-
-~~~ pseudocode
-function verify_ect(ect_jws, verifier_id,
-                     trust_domain_keys, ect_store):
-  // Parse JWS
-  (header, payload, signature) = parse_jws(ect_jws)
-
-  // Verify header
-  if header.typ != "wimse-exec+jwt":
-    return reject("Invalid typ parameter")
-
-  if header.alg == "none" or is_symmetric(header.alg):
-    return reject("Prohibited algorithm")
-
-  // Look up public key
-  public_key = trust_domain_keys.get(header.kid)
-  if public_key is null:
-    return reject("Unknown key identifier")
-
-  // Verify signature
-  if not verify_jws_signature(header, payload,
-                               signature, public_key):
-    return reject("Invalid signature")
-
-  // Verify key not revoked
-  if is_key_revoked(header.kid, trust_domain_keys):
-    return reject("Signing key has been revoked")
-
-  // Verify algorithm alignment
-  wit = get_wit_for_key(header.kid)
-  if header.alg != wit.alg:
-    return reject("Algorithm mismatch with WIT")
-
-  // Verify issuer matches WIT subject
-  if payload.iss != wit.sub:
-    return reject("Issuer does not match WIT subject")
-
-  // Verify audience
-  if verifier_id not in payload.aud:
-    return reject("ECT not intended for this recipient")
-
-  // Verify not expired
-  if payload.exp < current_time():
-    return reject("ECT has expired")
-
-  // Verify iat freshness (not too old, not in the future)
-  if payload.iat < current_time() - max_age_threshold:
-    return reject("ECT issued too long ago")
-  if payload.iat > current_time() + clock_skew_tolerance:
-    return reject("ECT issued in the future")
-
-  // Verify required claims
-  for claim in ["jti", "exec_act", "par"]:
-    if claim not in payload:
-      return reject("Missing required claim: " + claim)
-
-  // Validate DAG (against ECT store or inline parent ECTs)
-  result = validate_dag(payload, ect_store,
-                         clock_skew_tolerance)
-  if result is error:
-    return reject("DAG validation failed")
-
-  // All checks passed; record if store is available
-  if ect_store is not null:
-    ect_store.append(payload)
-  return accept
-~~~
-{: #fig-verification title="ECT Verification Pseudocode"}
-
 # Audit Ledger Interface {#ledger-interface}
 
 ECTs MAY be recorded in an immutable audit ledger for compliance
@@ -917,21 +697,8 @@ ECTs do not independently verify that:
 - The agent faithfully performed the stated action
 
 The trustworthiness of ECT claims depends on the trustworthiness
-of the signing agent.  To mitigate single-agent false claims,
-regulated environments SHOULD use the "witnessed_by"
-extension key (carried in "ext") to include independent
-third-party observers at critical decision points.  However,
-this value is self-asserted by the ECT issuer: the listed
-witnesses do not co-sign the ECT and there is no cryptographic
-evidence within a single ECT that the witnesses actually
-observed the task.  An issuing agent could list witnesses that
-did not participate.
-
-To strengthen witness attestation beyond self-assertion, witnesses
-SHOULD submit their own independent signed ECTs referencing the
-observed task's "jti" in the "par" array.  Auditors can then
-cross-check the "witnessed_by" extension against independent
-witness ECTs in the ECT store.
+of the signing agent and the integrity of the broader deployment
+environment.
 
 ## Organizational Prerequisites
 
@@ -1024,8 +791,6 @@ Mitigations include:
 
 - Independent ledger maintenance: The ledger SHOULD be maintained
   by an entity independent of the workflow agents.
-- Witness attestation: Using the "witnessed_by" extension
-  key in "ext" to include independent third-party observers.
 - Cross-verification: Multiple independent ledger replicas can be
   compared for consistency.
 - Out-of-band audit: External auditors periodically verify ledger
@@ -1103,21 +868,16 @@ structured identifiers.
 ## Storage and Access Control
 
 ECTs stored in audit ledgers SHOULD be access-controlled so that
-only authorized auditors and regulators can read them.
-Implementations SHOULD consider encryption at rest for ledger
-storage containing sensitive regulatory data.
+only authorized auditors can read them.  Implementations SHOULD
+consider encryption at rest for ledger storage.  ECTs provide
+structural records of execution ordering; they are not intended
+for public disclosure.
 
 Full input and output data (corresponding to the hashes in ECTs)
 SHOULD be stored separately from the ledger with additional access
 controls, since auditors may need to verify hash correctness but
 general access to the data values is not needed.
 
-## Regulatory Access
-
-ECTs are designed for interpretation by qualified human auditors
-and regulators.  ECTs provide structural records of execution
-ordering; they are not intended for public disclosure.
-
 # IANA Considerations
 
 ## Media Type Registration
@@ -1152,8 +912,8 @@ Published specification:
 : This document
 
 Applications that use this media type:
-: Applications that implement regulated agentic workflows requiring
-  execution context tracing and audit trails.
+: Applications that implement agentic workflows requiring execution
+  context tracing and audit trails.
 
 Additional information:
 : Magic number(s): none
@@ -1205,110 +965,18 @@ the "JSON Web Token Claims" registry maintained by IANA:
 | ext | Extension Object | IETF | {{extension-claims}} |
 {: #table-claims title="JWT Claims Registrations"}
 
-Policy evaluation claims and the ECT Policy Decision Values
-registry are defined in
-{{I-D.nennemann-wimse-ect-pol}}.
-
 --- back
 
 # Use Cases {#use-cases}
 {:numbered="false"}
 
-This section describes representative use cases demonstrating how
-ECTs provide execution records in regulated environments.  These
-examples demonstrate ECT mechanics; production deployments would
-include additional domain-specific requirements beyond the scope
-of this specification.
+This section describes a representative use case demonstrating how
+ECTs provide structured execution records.
 
 Note: task identifiers in this section are abbreviated for
 readability.  In production, all "jti" values are required to be
 UUIDs per {{exec-claims}}.
 
-## Medical Device SDLC Workflow
-{:numbered="false"}
-
-In a medical device software development lifecycle (SDLC),
-AI agents assist across multiple phases from requirements
-analysis through release approval.  Regulatory frameworks
-including {{FDA-21CFR11}} Section 11.10(e) and {{EU-MDR}} require
-audit trails documenting the complete development process for
-software used in medical devices.
-
-~~~
-Agent A (Spec Reviewer):
-  jti: task-001    par: []
-  exec_act: review_requirements_spec
-
-Agent B (Code Generator):
-  jti: task-002    par: [task-001]
-  exec_act: implement_module
-
-Agent C (Test Agent):
-  jti: task-003    par: [task-002]
-  exec_act: execute_test_suite
-
-Agent D (Build Agent):
-  jti: task-004    par: [task-003]
-  exec_act: build_release_artifact
-
-Human Release Manager:
-  jti: task-005    par: [task-004]
-  exec_act: approve_release
-  ext: {witnessed_by: [...]}  (extension metadata)
-~~~
-{: #fig-medtech-sdlc title="Medical Device SDLC Workflow"}
-
-ECTs record that requirements were reviewed before implementation
-began, that tests were executed against the implemented code, that
-the build artifact was validated, and that a human release manager
-explicitly approved the release.  The DAG structure ensures no
-phase was skipped or reordered.
-
-### FDA Audit with DAG Reconstruction
-{:numbered="false"}
-
-During a regulatory audit, an FDA reviewer requests evidence of
-the development process for a specific software release.  The
-auditing authority retrieves all ECTs sharing the same workflow
-identifier ("wid") from the audit ledger and reconstructs the
-complete DAG:
-
-~~~
-task-001 (review_requirements_spec)
-  |
-  v
-task-002 (implement_module)
-  |
-  v
-task-003 (execute_test_suite)
-  |
-  v
-task-004 (build_release_artifact)
-  |
-  v
-task-005 (approve_release) [human, witnessed]
-~~~
-{: #fig-fda-audit title="Reconstructed DAG for FDA Audit"}
-
-The reconstructed DAG provides cryptographic evidence that:
-
-- Each phase was executed by an identified and authenticated agent.
-- The execution sequence was maintained (no step was bypassed).
-- A human-in-the-loop approved the final release, with independent
-  witness attestation.
-- Timestamps and execution durations are recorded for each step.
-
-This can contribute to compliance with:
-
-- {{FDA-21CFR11}} Section 11.10(e): Computer-generated audit trails
-  that record the date, time, and identity of the operator.
-- {{EU-MDR}} Annex II: Technical documentation traceability for the
-  software development lifecycle.
-- {{EU-AI-ACT}} Article 12: Automatic logging capabilities for
-  high-risk AI systems involved in the development process.
-- {{EU-AI-ACT}} Article 14: ECTs can record evidence that human
-  oversight events occurred during the release process.
-
 ## Cross-Organization Financial Trading
 {:numbered="false"}
 
@@ -1365,56 +1033,6 @@ demonstrating cross-organizational fan-in.  The compliance agent
 verifies both parent ECTs — one signed by a local key and one by
 a federated key from the rating agency's trust domain.
 
-This can contribute to compliance with:
-
-- {{MIFID-II}}: ECTs provide cryptographic records of the execution
-  sequence that can support transaction audit requirements.
-- {{DORA}} Article 12: ECTs contribute to ICT activity logging.
-- {{EU-AI-ACT}} Article 12: Logging of decisions made by AI-driven
-  systems.
-
-## Compensation and Rollback
-{:numbered="false"}
-
-Compensation and rollback use cases are described in
-{{I-D.nennemann-wimse-ect-pol}}.  The core
-ECT mechanism supports compensation through the "par" claim,
-which links a remediation ECT to the original task.
-
-## Autonomous Logistics Coordination
-{:numbered="false"}
-
-In a logistics workflow, multiple compliance checks complete
-before shipment commitment.  The DAG structure records that all
-required checks were completed:
-
-~~~
-Agent A (Route Planning):
-  jti: task-001    par: []
-  exec_act: plan_route
-
-Agent B (Customs):
-  jti: task-002    par: [task-001]
-  exec_act: validate_customs
-
-Agent C (Safety):
-  jti: task-003    par: [task-001]
-  exec_act: verify_cargo_safety
-
-Agent D (Payment):
-  jti: task-004    par: [task-002, task-003]
-  exec_act: authorize_payment
-
-System (Commitment):
-  jti: task-005    par: [task-004]
-  exec_act: commit_shipment
-~~~
-{: #fig-logistics title="Logistics Workflow with Parallel Tasks"}
-
-Note that tasks 002 and 003 both depend only on task-001 and can
-execute in parallel.  Task 004 depends on both, demonstrating the
-DAG's ability to represent parallel execution with a join point.
-
 # Related Work
 {:numbered="false"}
 
@@ -1439,7 +1057,8 @@ delegation chain: "who is acting on behalf of whom."  While
 the nesting superficially resembles a chain, it is strictly
 linear (each "act" object contains at most one nested "act"),
 represents authorization delegation rather than task execution,
-and carries no task identifiers or input/output integrity data.  The "act" chain cannot represent
+and carries no task identifiers or input/output integrity
+data.  The "act" chain cannot represent
 branching (fan-out) or convergence (fan-in) and therefore
 cannot form a DAG.
 
@@ -1501,357 +1120,14 @@ provide observability while ECTs provide signed execution records.
 ECTs may reference OpenTelemetry trace identifiers in the "ext"
 claim for correlation.
 
-## Blockchain and Distributed Ledgers
-{:numbered="false"}
-
-Both ECTs and blockchain systems provide immutable records.  This
-specification intentionally defines only the ECT token format and
-is agnostic to the storage mechanism.  ECTs can be stored in
-append-only logs, databases with cryptographic commitments,
-blockchain networks, or any storage providing the required
-properties defined in {{ledger-interface}}.
-
 ## SCITT (Supply Chain Integrity, Transparency, and Trust)
 {:numbered="false"}
 
 The SCITT architecture {{I-D.ietf-scitt-architecture}} defines a
-framework for creating transparent and auditable supply chain
-records through Transparency Services, Signed Statements, and
-Receipts.  ECTs and SCITT are naturally complementary: the ECT
-"wid" (Workflow Identifier) claim can serve as a correlation
-identifier referenced in SCITT Signed Statements, linking a
-complete ECT audit trail to a supply chain transparency record.
-For example, in a regulated manufacturing workflow, each agent
-step produces an ECT (recording what was done, by whom, under
-under what constraints), while the overall workflow identified by "wid" is
-registered as a SCITT Signed Statement on a Transparency Service.
-This enables auditors to verify both the individual execution
-steps (via ECT DAG validation) and the end-to-end supply chain
-integrity (via SCITT Receipts) using the "wid" as the shared
-correlation point.  The "ext" claim in ECTs ({{exec-claims}})
-can carry SCITT-specific metadata such as Transparency Service
-identifiers or Receipt references for tighter integration.
-
-## W3C Verifiable Credentials
-{:numbered="false"}
-
-W3C Verifiable Credentials represent claims about subjects (e.g.,
-identity, qualifications).  ECTs represent execution records of
-actions (what happened, in what order).  While
-both use JWT/JWS as a serialization format, their semantics and
-use cases are distinct.
-
-# Implementation Guidance
-{:numbered="false"}
-
-## Minimal Implementation
-{:numbered="false"}
-
-A minimal conforming implementation needs to:
-
-1.  Create JWTs with all required claims ("iss", "aud", "iat",
-    "exp", "jti", "exec_act", "par").
-2.  Sign ECTs with the agent's private key using an algorithm
-    matching the WIT (ES256 recommended).
-3.  Verify ECT signatures against WIT public keys.
-4.  Perform DAG validation (parent existence, temporal ordering,
-    cycle detection).
-5.  If an audit ledger is deployed, append verified ECTs to it.
-
-## Storage Recommendations
-{:numbered="false"}
-
-- Append-only log: Simplest approach; immutability by design.
-- Database with hash chains: Periodic cryptographic commitments
-  over batches of entries.
-- Distributed ledger: Maximum immutability guarantees for
-  cross-organizational audit.
-- Hybrid: Hot storage in a database, cold archive in immutable
-  storage.
-
-## Performance Considerations
-{:numbered="false"}
-
-- ES256 signature verification: approximately 1ms per ECT on
-  modern hardware.
-- DAG validation: O(V) where V is the number of reachable ancestor
-  nodes (typically small for shallow workflows).
-- JSON serialization: sub-millisecond per ECT.
-- Total per-request overhead: approximately 5-10ms, acceptable
-  for regulated workflows where correctness is prioritized over
-  latency.
-
-## Interoperability
-{:numbered="false"}
-
-Implementations are expected to use established JWT/JWS libraries
-(JOSE) for token creation and verification.  Custom cryptographic
-implementations are strongly discouraged.  Implementations are
-expected to be tested against multiple JWT libraries to ensure
-interoperability.
-
-# Regulatory Compliance Mapping
-{:numbered="false"}
-
-The following table summarizes how ECTs can contribute to
-compliance with various regulatory frameworks.  ECTs are a
-technical building block; achieving compliance requires
-additional organizational measures beyond this specification.
-
-| Regulation | Requirement | ECT Contribution |
-|:---|:---|:---|
-| FDA 21 CFR Part 11 | Audit trails recording date, time, operator, actions (11.10(e)) | Cryptographic signatures and append-only ledger contribute to audit trail requirements |
-| EU MDR | Technical documentation traceability (Annex II) | ECTs provide signed records of AI-assisted decision sequences |
-| EU AI Act Art. 12 | Automatic logging capabilities for high-risk AI | ECTs contribute cryptographic activity logging |
-| EU AI Act Art. 14 | Human oversight capability | ECTs can record evidence that human oversight events occurred |
-| MiFID II | Transaction records for supervisory authorities | ECTs provide cryptographic execution sequence records |
-| DORA Art. 12 | ICT activity logging policies | ECT ledger contributes to ICT activity audit trail |
-{: #table-regulatory title="Regulatory Compliance Mapping"}
-
-# Examples
-{:numbered="false"}
-
-## Example 1: Simple Two-Agent Workflow
-{:numbered="false"}
-
-Agent A executes a data retrieval task and sends the ECT to
-Agent B:
-
-ECT JOSE Header:
-
-~~~json
-{
-  "alg": "ES256",
-  "typ": "wimse-exec+jwt",
-  "kid": "agent-a-key-2026-02"
-}
-~~~
-
-ECT Payload:
-
-~~~json
-{
-  "iss": "spiffe://example.com/agent/data-retrieval",
-  "aud": "spiffe://example.com/agent/validator",
-  "iat": 1772064150,
-  "exp": 1772064750,
-  "jti": "550e8400-e29b-41d4-a716-446655440001",
-  "wid": "b1c2d3e4-f5a6-7890-bcde-f01234567890",
-  "exec_act": "fetch_patient_data",
-  "par": [],
-  "inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
-  "out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564"
-}
-~~~
-
-Agent B receives the ECT, verifies it, executes a validation
-task, and creates its own ECT:
-
-~~~json
-{
-  "iss": "spiffe://example.com/agent/validator",
-  "aud": "spiffe://example.com/system/ledger",
-  "iat": 1772064160,
-  "exp": 1772064760,
-  "jti": "550e8400-e29b-41d4-a716-446655440002",
-  "wid": "b1c2d3e4-f5a6-7890-bcde-f01234567890",
-  "exec_act": "validate_safety",
-  "par": ["550e8400-e29b-41d4-a716-446655440001"]
-}
-~~~
-
-The resulting DAG:
-
-~~~
-task-...-0001 (fetch_patient_data)
-  |
-  v
-task-...-0002 (validate_safety)
-~~~
-
-## Example 2: Medical Device SDLC with Release Approval
-{:numbered="false"}
-
-A multi-step medical device software lifecycle workflow with
-autonomous agents and human release approval:
-
-Task 1 (Spec Review Agent):
-
-~~~json
-{
-  "iss": "spiffe://meddev.example/agent/spec-reviewer",
-  "aud": "spiffe://meddev.example/agent/code-gen",
-  "iat": 1772064150,
-  "exp": 1772064750,
-  "jti": "a1b2c3d4-0001-0000-0000-000000000001",
-  "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
-  "exec_act": "review_requirements_spec",
-  "par": [],
-  "inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
-  "out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564"
-}
-~~~
-
-Task 2 (Code Generation Agent):
-
-~~~json
-{
-  "iss": "spiffe://meddev.example/agent/code-gen",
-  "aud": "spiffe://meddev.example/agent/test-runner",
-  "iat": 1772064200,
-  "exp": 1772064800,
-  "jti": "a1b2c3d4-0001-0000-0000-000000000002",
-  "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
-  "exec_act": "implement_module",
-  "par": ["a1b2c3d4-0001-0000-0000-000000000001"]
-}
-~~~
-
-Task 3 (Autonomous Test Agent):
-
-~~~json
-{
-  "iss": "spiffe://meddev.example/agent/test-runner",
-  "aud": "spiffe://meddev.example/agent/build",
-  "iat": 1772064260,
-  "exp": 1772064860,
-  "jti": "a1b2c3d4-0001-0000-0000-000000000003",
-  "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
-  "exec_act": "execute_test_suite",
-  "par": ["a1b2c3d4-0001-0000-0000-000000000002"]
-}
-~~~
-
-Task 4 (Build Agent):
-
-~~~json
-{
-  "iss": "spiffe://meddev.example/agent/build",
-  "aud": "spiffe://meddev.example/human/release-mgr-42",
-  "iat": 1772064310,
-  "exp": 1772064910,
-  "jti": "a1b2c3d4-0001-0000-0000-000000000004",
-  "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
-  "exec_act": "build_release_artifact",
-  "par": ["a1b2c3d4-0001-0000-0000-000000000003"],
-  "out_hash": "sha-256:Ry1YfOoW2XpC5Mq8HkGzNx3dL9vBa4sUjE7iKt0wPZc"
-}
-~~~
-
-Task 5 (Human Release Manager Approval):
-
-~~~json
-{
-  "iss": "spiffe://meddev.example/human/release-mgr-42",
-  "aud": "spiffe://meddev.example/system/ledger",
-  "iat": 1772064510,
-  "exp": 1772065110,
-  "jti": "a1b2c3d4-0001-0000-0000-000000000005",
-  "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
-  "exec_act": "approve_release",
-  "par": ["a1b2c3d4-0001-0000-0000-000000000004"],
-  "ext": {
-    "witnessed_by": [
-      "spiffe://meddev.example/audit/qa-observer-1"
-    ]
-  }
-}
-~~~
-
-The resulting DAG records the complete SDLC: spec review preceded
-implementation, implementation preceded testing, testing preceded
-build, and a human release manager approved the final release.
-The "ext" object in task 5 carries witness metadata via
-the "witnessed_by" extension key.
-
-~~~
-task-...-0001 (review_requirements_spec)
-  |
-  v
-task-...-0002 (implement_module)
-  |
-  v
-task-...-0003 (execute_test_suite)
-  |
-  v
-task-...-0004 (build_release_artifact)
-  |
-  v
-task-...-0005 (approve_release) [human]
-~~~
-
-An FDA auditor reconstructs this DAG by querying the audit ledger
-for all ECTs with wid "c2d3e4f5-a6b7-8901-cdef-012345678901" and
-verifying each signature.  The DAG provides cryptographic evidence
-that the SDLC followed the prescribed process with human oversight
-at the release gate.
-
-## Example 3: Cross-Organization Fan-In
-{:numbered="false"}
-
-A cross-organization workflow where two independent root tasks
-from different trust domains feed into a compliance verification
-step.  This demonstrates DAG fan-in across organizational
-boundaries.
-
-Task 001 (Bank's risk agent — root task):
-
-~~~json
-{
-  "iss": "spiffe://bank.example/agent/risk",
-  "aud": "spiffe://bank.example/agent/compliance",
-  "iat": 1772064150,
-  "exp": 1772064750,
-  "jti": "f1e2d3c4-0001-0000-0000-000000000001",
-  "wid": "d3e4f5a6-b7c8-9012-def0-123456789012",
-  "exec_act": "analyze_portfolio_risk",
-  "par": [],
-  "out_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg"
-}
-~~~
-
-Task 002 (External rating agency — root task, different trust
-domain):
-
-~~~json
-{
-  "iss": "spiffe://ratings.example/agent/credit",
-  "aud": "spiffe://bank.example/agent/compliance",
-  "iat": 1772064155,
-  "exp": 1772064755,
-  "jti": "f1e2d3c4-0002-0000-0000-000000000002",
-  "wid": "d3e4f5a6-b7c8-9012-def0-123456789012",
-  "exec_act": "assess_credit_rating",
-  "par": [],
-  "out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564"
-}
-~~~
-
-Task 003 (Bank's compliance agent — joins both parents):
-
-~~~json
-{
-  "iss": "spiffe://bank.example/agent/compliance",
-  "aud": "spiffe://bank.example/agent/execution",
-  "iat": 1772064200,
-  "exp": 1772064800,
-  "jti": "f1e2d3c4-0003-0000-0000-000000000003",
-  "wid": "d3e4f5a6-b7c8-9012-def0-123456789012",
-  "exec_act": "verify_trade_compliance",
-  "par": [
-    "f1e2d3c4-0001-0000-0000-000000000001",
-    "f1e2d3c4-0002-0000-0000-000000000002"
-  ]
-}
-~~~
-
-The "par" array in task 003 references two parents from different
-trust domains: `spiffe://bank.example` and
-`spiffe://ratings.example`.  The compliance agent verifies both
-parent ECTs — one signed by a local key and one by a federated
-key — before proceeding.  This demonstrates how ECTs support
-cross-organizational workflows while maintaining cryptographic
-accountability.
+framework for transparent and auditable supply chain records.
+ECTs and SCITT are complementary: the ECT "wid" claim can serve
+as a correlation identifier in SCITT Signed Statements, linking
+an ECT audit trail to a supply chain transparency record.
 
 # Acknowledgments
 {:numbered="false"}
diff --git a/draft-nennemann-wimse-ect-00.txt b/draft-nennemann-wimse-ect-00.txt
index 73d68e6..6e8809e 100644
--- a/draft-nennemann-wimse-ect-00.txt
+++ b/draft-nennemann-wimse-ect-00.txt
@@ -15,21 +15,16 @@ Abstract
 
    This document defines Execution Context Tokens (ECTs), an extension
    to the Workload Identity in Multi System Environments (WIMSE)
-   architecture for distributed agentic workflows in regulated
-   environments.  ECTs provide signed, structured records of task
-   execution order and compliance state across agent-to-agent
+   architecture for distributed agentic workflows.  ECTs provide signed,
+   structured records of task execution order across agent-to-agent
    communication.  By extending WIMSE Workload Identity Tokens with
    execution context claims in JSON Web Token (JWT) format, this
-   specification enables regulated systems to maintain structured audit
-   trails that support compliance verification.  ECTs use a directed
-   acyclic graph (DAG) structure to represent task dependencies and
-   integrate with WIMSE Workload Identity Tokens (WIT) using the same
-   signing model and cryptographic primitives.  Policy evaluation and
-   compensation extensions are defined in [I-D.nennemann-wimse-ect-pol].
-   A new HTTP header field, Execution-Context, is defined for
-   transporting ECTs alongside existing WIMSE headers.  ECTs are a
-   technical building block that supports, but does not by itself
-   constitute, compliance with regulatory frameworks.
+   specification enables systems to maintain structured audit trails of
+   agent execution.  ECTs use a directed acyclic graph (DAG) structure
+   to represent task dependencies and integrate with WIMSE Workload
+   Identity Tokens (WIT) using the same signing model and cryptographic
+   primitives.  A new HTTP header field, Execution-Context, is defined
+   for transporting ECTs alongside existing WIMSE headers.
 
 Status of This Memo
 
@@ -48,6 +43,11 @@ Status of This Memo
 
    This Internet-Draft will expire on 29 August 2026.
 
+Copyright Notice
+
+   Copyright (c) 2026 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
 
 
 
@@ -58,11 +58,6 @@ Nennemann                Expires 29 August 2026                 [Page 1]
 Internet-Draft           WIMSE Execution Context           February 2026
 
 
-Copyright Notice
-
-   Copyright (c) 2026 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
    This document is subject to BCP 78 and the IETF Trust's Legal
    Provisions Relating to IETF Documents (https://trustee.ietf.org/
    license-info) in effect on the date of publication of this document.
@@ -74,38 +69,43 @@ Copyright Notice
 
 Table of Contents
 
-   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
-     1.1.  Motivation  . . . . . . . . . . . . . . . . . . . . . . .   4
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
+     1.1.  Motivation  . . . . . . . . . . . . . . . . . . . . . . .   3
      1.2.  Problem Statement . . . . . . . . . . . . . . . . . . . .   4
-     1.3.  Scope and Applicability . . . . . . . . . . . . . . . . .   5
-     1.4.  Relationship to Regulatory Compliance . . . . . . . . . .   5
-   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   6
-   3.  WIMSE Architecture Integration  . . . . . . . . . . . . . . .   6
-     3.1.  WIMSE Foundation  . . . . . . . . . . . . . . . . . . . .   7
-     3.2.  Extension Model . . . . . . . . . . . . . . . . . . . . .   7
-     3.3.  Integration Points  . . . . . . . . . . . . . . . . . . .   8
-   4.  Execution Context Token Format  . . . . . . . . . . . . . . .   9
-     4.1.  JOSE Header . . . . . . . . . . . . . . . . . . . . . . .   9
-     4.2.  JWT Claims  . . . . . . . . . . . . . . . . . . . . . . .   9
-       4.2.1.  Standard JWT Claims . . . . . . . . . . . . . . . . .   9
-       4.2.2.  Execution Context . . . . . . . . . . . . . . . . . .  11
-       4.2.3.  Data Integrity  . . . . . . . . . . . . . . . . . . .  11
-       4.2.4.  Compensation and Rollback . . . . . . . . . . . . . .  12
-       4.2.5.  Extensions  . . . . . . . . . . . . . . . . . . . . .  12
-     4.3.  Complete ECT Example  . . . . . . . . . . . . . . . . . .  13
-   5.  HTTP Header Transport . . . . . . . . . . . . . . . . . . . .  13
-     5.1.  Execution-Context Header Field  . . . . . . . . . . . . .  13
-   6.  DAG Validation  . . . . . . . . . . . . . . . . . . . . . . .  14
-     6.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .  14
-     6.2.  Validation Rules  . . . . . . . . . . . . . . . . . . . .  14
-     6.3.  DAG Validation Algorithm  . . . . . . . . . . . . . . . .  15
-   7.  Signature and Token Verification  . . . . . . . . . . . . . .  17
-     7.1.  Verification Procedure  . . . . . . . . . . . . . . . . .  17
-     7.2.  Verification Pseudocode . . . . . . . . . . . . . . . . .  18
-   8.  Audit Ledger Interface  . . . . . . . . . . . . . . . . . . .  20
-   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  20
-     9.1.  Threat Model  . . . . . . . . . . . . . . . . . . . . . .  20
-     9.2.  Self-Assertion Limitation . . . . . . . . . . . . . . . .  21
+     1.3.  Scope and Applicability . . . . . . . . . . . . . . . . .   4
+   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   5
+   3.  WIMSE Architecture Integration  . . . . . . . . . . . . . . .   5
+     3.1.  WIMSE Foundation  . . . . . . . . . . . . . . . . . . . .   5
+     3.2.  Extension Model . . . . . . . . . . . . . . . . . . . . .   6
+     3.3.  Integration Points  . . . . . . . . . . . . . . . . . . .   6
+   4.  Execution Context Token Format  . . . . . . . . . . . . . . .   7
+     4.1.  JOSE Header . . . . . . . . . . . . . . . . . . . . . . .   8
+     4.2.  JWT Claims  . . . . . . . . . . . . . . . . . . . . . . .   8
+       4.2.1.  Standard JWT Claims . . . . . . . . . . . . . . . . .   8
+       4.2.2.  Execution Context . . . . . . . . . . . . . . . . . .  10
+       4.2.3.  Data Integrity  . . . . . . . . . . . . . . . . . . .  10
+       4.2.4.  Extensions  . . . . . . . . . . . . . . . . . . . . .  10
+     4.3.  Complete ECT Example  . . . . . . . . . . . . . . . . . .  11
+   5.  HTTP Header Transport . . . . . . . . . . . . . . . . . . . .  11
+     5.1.  Execution-Context Header Field  . . . . . . . . . . . . .  11
+   6.  DAG Validation  . . . . . . . . . . . . . . . . . . . . . . .  12
+     6.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .  12
+     6.2.  Validation Rules  . . . . . . . . . . . . . . . . . . . .  12
+   7.  Signature and Token Verification  . . . . . . . . . . . . . .  13
+     7.1.  Verification Procedure  . . . . . . . . . . . . . . . . .  13
+   8.  Audit Ledger Interface  . . . . . . . . . . . . . . . . . . .  15
+   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
+     9.1.  Threat Model  . . . . . . . . . . . . . . . . . . . . . .  15
+     9.2.  Self-Assertion Limitation . . . . . . . . . . . . . . . .  16
+     9.3.  Organizational Prerequisites  . . . . . . . . . . . . . .  16
+     9.4.  Signature Verification  . . . . . . . . . . . . . . . . .  16
+     9.5.  Replay Attack Prevention  . . . . . . . . . . . . . . . .  17
+     9.6.  Man-in-the-Middle Protection  . . . . . . . . . . . . . .  17
+     9.7.  Key Compromise  . . . . . . . . . . . . . . . . . . . . .  17
+     9.8.  Collusion and False Claims  . . . . . . . . . . . . . . .  18
+     9.9.  Denial of Service . . . . . . . . . . . . . . . . . . . .  18
+     9.10. Timestamp Accuracy  . . . . . . . . . . . . . . . . . . .  18
+     9.11. ECT Size Constraints  . . . . . . . . . . . . . . . . . .  19
 
 
 
@@ -114,61 +114,27 @@ Nennemann                Expires 29 August 2026                 [Page 2]
 Internet-Draft           WIMSE Execution Context           February 2026
 
 
-     9.3.  Organizational Prerequisites  . . . . . . . . . . . . . .  21
-     9.4.  Signature Verification  . . . . . . . . . . . . . . . . .  22
-     9.5.  Replay Attack Prevention  . . . . . . . . . . . . . . . .  22
-     9.6.  Man-in-the-Middle Protection  . . . . . . . . . . . . . .  22
-     9.7.  Key Compromise  . . . . . . . . . . . . . . . . . . . . .  23
-     9.8.  Collusion and False Claims  . . . . . . . . . . . . . . .  23
-     9.9.  Denial of Service . . . . . . . . . . . . . . . . . . . .  24
-     9.10. Timestamp Accuracy  . . . . . . . . . . . . . . . . . . .  24
-     9.11. ECT Size Constraints  . . . . . . . . . . . . . . . . . .  24
-   10. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  24
-     10.1.  Data Exposure in ECTs  . . . . . . . . . . . . . . . . .  24
-     10.2.  Data Minimization  . . . . . . . . . . . . . . . . . . .  25
-     10.3.  Storage and Access Control . . . . . . . . . . . . . . .  25
-     10.4.  Regulatory Access  . . . . . . . . . . . . . . . . . . .  25
-   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  25
-     11.1.  Media Type Registration  . . . . . . . . . . . . . . . .  25
-     11.2.  HTTP Header Field Registration . . . . . . . . . . . . .  26
-     11.3.  JWT Claims Registration  . . . . . . . . . . . . . . . .  27
-   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  27
-     12.1.  Normative References . . . . . . . . . . . . . . . . . .  27
-     12.2.  Informative References . . . . . . . . . . . . . . . . .  28
-   Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . .  30
-     Medical Device SDLC Workflow  . . . . . . . . . . . . . . . . .  30
-       FDA Audit with DAG Reconstruction . . . . . . . . . . . . . .  31
-     Cross-Organization Financial Trading  . . . . . . . . . . . . .  32
-     Compensation and Rollback . . . . . . . . . . . . . . . . . . .  34
-     Autonomous Logistics Coordination . . . . . . . . . . . . . . .  34
-   Related Work  . . . . . . . . . . . . . . . . . . . . . . . . . .  35
-     WIMSE Workload Identity . . . . . . . . . . . . . . . . . . . .  35
-     OAuth 2.0 Token Exchange and the "act" Claim  . . . . . . . . .  35
-     Transaction Tokens  . . . . . . . . . . . . . . . . . . . . . .  35
-     Distributed Tracing (OpenTelemetry) . . . . . . . . . . . . . .  36
-     Blockchain and Distributed Ledgers  . . . . . . . . . . . . . .  36
-     SCITT (Supply Chain Integrity, Transparency, and Trust) . . . .  37
-     W3C Verifiable Credentials  . . . . . . . . . . . . . . . . . .  37
-   Implementation Guidance . . . . . . . . . . . . . . . . . . . . .  37
-     Minimal Implementation  . . . . . . . . . . . . . . . . . . . .  37
-     Storage Recommendations . . . . . . . . . . . . . . . . . . . .  38
-     Performance Considerations  . . . . . . . . . . . . . . . . . .  38
-     Interoperability  . . . . . . . . . . . . . . . . . . . . . . .  38
-   Regulatory Compliance Mapping . . . . . . . . . . . . . . . . . .  38
-   Examples  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  39
-     Example 1: Simple Two-Agent Workflow  . . . . . . . . . . . . .  39
-     Example 2: Medical Device SDLC with Release Approval  . . . . .  40
-     Example 3: Parallel Execution with Join . . . . . . . . . . . .  43
-   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  44
-   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  44
-
-
-
-
-Nennemann                Expires 29 August 2026                 [Page 3]
-
-Internet-Draft           WIMSE Execution Context           February 2026
-
+   10. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  19
+     10.1.  Data Exposure in ECTs  . . . . . . . . . . . . . . . . .  19
+     10.2.  Data Minimization  . . . . . . . . . . . . . . . . . . .  20
+     10.3.  Storage and Access Control . . . . . . . . . . . . . . .  20
+   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  20
+     11.1.  Media Type Registration  . . . . . . . . . . . . . . . .  20
+     11.2.  HTTP Header Field Registration . . . . . . . . . . . . .  21
+     11.3.  JWT Claims Registration  . . . . . . . . . . . . . . . .  21
+   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  22
+     12.1.  Normative References . . . . . . . . . . . . . . . . . .  22
+     12.2.  Informative References . . . . . . . . . . . . . . . . .  23
+   Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . .  24
+     Cross-Organization Financial Trading  . . . . . . . . . . . . .  25
+   Related Work  . . . . . . . . . . . . . . . . . . . . . . . . . .  26
+     WIMSE Workload Identity . . . . . . . . . . . . . . . . . . . .  26
+     OAuth 2.0 Token Exchange and the "act" Claim  . . . . . . . . .  26
+     Transaction Tokens  . . . . . . . . . . . . . . . . . . . . . .  26
+     Distributed Tracing (OpenTelemetry) . . . . . . . . . . . . . .  27
+     SCITT (Supply Chain Integrity, Transparency, and Trust) . . . .  27
+   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  28
+   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  28
 
 1.  Introduction
 
@@ -188,15 +154,22 @@ Internet-Draft           WIMSE Execution Context           February 2026
    Regulated environments increasingly deploy autonomous agents that
    coordinate across organizational boundaries.  Domains such as
    healthcare, finance, and logistics require structured, auditable
-   records of automated decision-making and execution.  Table 2 in the
-   appendix illustrates how ECTs relate to specific regulatory
-   frameworks.
+   records of automated decision-making and execution.
 
    This document defines an extension to the WIMSE architecture that
    addresses the gap between workload identity and execution
    accountability.  WIMSE authenticates agents; this extension records
    what they did and in what order.
 
+
+
+
+
+Nennemann                Expires 29 August 2026                 [Page 3]
+
+Internet-Draft           WIMSE Execution Context           February 2026
+
+
    As identified in [I-D.ni-wimse-ai-agent-identity], call context in
    agentic workflows needs to be visible and preserved.  ECTs provide a
    mechanism to address this requirement with cryptographic assurances.
@@ -216,16 +189,6 @@ Internet-Draft           WIMSE Execution Context           February 2026
    3.  No mechanism exists to reconstruct the complete execution history
        of a distributed workflow for audit purposes.
 
-
-
-
-
-
-Nennemann                Expires 29 August 2026                 [Page 4]
-
-Internet-Draft           WIMSE Execution Context           February 2026
-
-
    Existing observability tools such as distributed tracing
    [OPENTELEMETRY] provide visibility for debugging and monitoring but
    do not provide cryptographic assurances.  Tracing data is not
@@ -246,9 +209,6 @@ Internet-Draft           WIMSE Execution Context           February 2026
 
    *  Audit ledger interface requirements (Section 8)
 
-   *  Policy evaluation and compensation extensions are defined
-      separately in [I-D.nennemann-wimse-ect-pol]
-
    The following are out of scope and are handled by WIMSE:
 
    *  Workload authentication and identity provisioning
@@ -259,36 +219,13 @@ Internet-Draft           WIMSE Execution Context           February 2026
 
    *  Credential lifecycle management
 
-1.4.  Relationship to Regulatory Compliance
-
-   ECTs are a technical mechanism that can support compliance programs
-   by providing structured, cryptographically signed execution records.
-   ECTs do not by themselves constitute compliance with any regulatory
-   framework referenced in this document.
-
-   Compliance with each referenced regulation requires organizational
-   controls, policies, procedures, validation, and governance measures
-   beyond the scope of this specification.  The regulatory references in
-   this document are intended to motivate the design requirements, not
-   to claim that implementing ECTs satisfies these regulations.
 
 
-
-
-
-
-Nennemann                Expires 29 August 2026                 [Page 5]
+Nennemann                Expires 29 August 2026                 [Page 4]
 
 Internet-Draft           WIMSE Execution Context           February 2026
 
 
-   ECTs provide evidence of claimed execution ordering.  They do not
-   independently verify that the claimed execution actually occurred as
-   described or that the agent faithfully performed the stated action.
-   The trustworthiness of ECT claims depends on the trustworthiness of
-   the signing agent and the integrity of the broader deployment
-   environment.
-
 2.  Conventions and Definitions
 
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
@@ -312,8 +249,7 @@ Internet-Draft           WIMSE Execution Context           February 2026
       this specification that records task execution details.
 
    Audit Ledger:  An append-only, immutable log of all ECTs within a
-      workflow or set of workflows, used for regulatory audit and
-      compliance verification.
+      workflow or set of workflows, used for audit and verification.
 
    Workload Identity Token (WIT):  A WIMSE credential proving a
       workload's identity within a trust domain.
@@ -325,19 +261,8 @@ Internet-Draft           WIMSE Execution Context           February 2026
       boundary with a shared identity issuer, corresponding to a SPIFFE
       [SPIFFE] trust domain.
 
-   Witness:  A third-party entity that observes and attests to the
-      execution of a task, providing additional accountability.
-
 3.  WIMSE Architecture Integration
 
-
-
-
-Nennemann                Expires 29 August 2026                 [Page 6]
-
-Internet-Draft           WIMSE Execution Context           February 2026
-
-
 3.1.  WIMSE Foundation
 
    The WIMSE architecture [I-D.ietf-wimse-arch] defines:
@@ -348,6 +273,15 @@ Internet-Draft           WIMSE Execution Context           February 2026
    *  Workload Proof Tokens (WPT) that prove possession of the private
       key associated with a WIT ("I control the key for Agent X")
 
+
+
+
+
+Nennemann                Expires 29 August 2026                 [Page 5]
+
+Internet-Draft           WIMSE Execution Context           February 2026
+
+
    *  Multi-hop authentication via the service-to-service protocol
       [I-D.ietf-wimse-s2s-protocol]
 
@@ -387,13 +321,6 @@ Internet-Draft           WIMSE Execution Context           February 2026
 
                Figure 1: WIMSE Extension Architecture Layers
 
-
-
-Nennemann                Expires 29 August 2026                 [Page 7]
-
-Internet-Draft           WIMSE Execution Context           February 2026
-
-
    This extension reuses the WIMSE signing model, extends JWT claims
    using standard JWT extensibility [RFC7519], and maintains WIMSE
    concepts including trust domains and workload identifiers.
@@ -403,6 +330,14 @@ Internet-Draft           WIMSE Execution Context           February 2026
    An ECT integrates with the WIMSE identity framework through the
    following mechanisms:
 
+
+
+
+Nennemann                Expires 29 August 2026                 [Page 6]
+
+Internet-Draft           WIMSE Execution Context           February 2026
+
+
    *  The ECT JOSE header "kid" parameter MUST reference the public key
       identifier from the agent's WIT.
 
@@ -441,20 +376,23 @@ Internet-Draft           WIMSE Execution Context           February 2026
    3.  Ledger (if deployed): Appends the verified ECT to the audit
        ledger.
 
-
-
-
-
-Nennemann                Expires 29 August 2026                 [Page 8]
-
-Internet-Draft           WIMSE Execution Context           February 2026
-
-
 4.  Execution Context Token Format
 
    An Execution Context Token is a JSON Web Token (JWT) [RFC7519] signed
-   as a JSON Web Signature (JWS) [RFC7515] using the Compact
-   Serialization.  JWS JSON Serialization MUST NOT be used for ECTs.
+   as a JSON Web Signature (JWS) [RFC7515].  ECTs MUST use JWS Compact
+   Serialization (the base64url-encoded header.payload.signature format)
+   so that they can be carried in a single HTTP header value.
+
+
+
+
+
+
+
+Nennemann                Expires 29 August 2026                 [Page 7]
+
+Internet-Draft           WIMSE Execution Context           February 2026
+
 
 4.1.  JOSE Header
 
@@ -499,19 +437,19 @@ Internet-Draft           WIMSE Execution Context           February 2026
       "sub" claim of the agent's WIT.  Non-WIMSE deployments MAY use
       other URI schemes (e.g., HTTPS URLs or URN:UUID identifiers).
 
-
-
-Nennemann                Expires 29 August 2026                 [Page 9]
-
-Internet-Draft           WIMSE Execution Context           February 2026
-
-
    aud:  REQUIRED.  StringOrURI or array of StringOrURI.  The intended
       recipient(s) of the ECT.  Because ECTs serve as both inter-agent
       messages and audit records, the "aud" claim SHOULD contain the
       identifiers of all entities that will verify the ECT.  In practice
       this means:
 
+
+
+Nennemann                Expires 29 August 2026                 [Page 8]
+
+Internet-Draft           WIMSE Execution Context           February 2026
+
+
       *  *Point-to-point delivery*: when an ECT is sent from one agent
          to a single next agent, "aud" contains that agent's workload
          identity.  The receiving agent verifies the ECT and forwards it
@@ -554,18 +492,20 @@ Internet-Draft           WIMSE Execution Context           February 2026
       identifier (for replay detection) and the task identifier (for DAG
       parent references in "par").  Receivers MUST reject ECTs whose
       "jti" has already been seen within the expiration window.  When
-
-
-
-Nennemann                Expires 29 August 2026                [Page 10]
-
-Internet-Draft           WIMSE Execution Context           February 2026
-
-
       "wid" is present, uniqueness is scoped to the workflow; when "wid"
       is absent, uniqueness MUST be enforced globally across the ECT
       store.
 
+
+
+
+
+
+Nennemann                Expires 29 August 2026                 [Page 9]
+
+Internet-Draft           WIMSE Execution Context           February 2026
+
+
 4.2.2.  Execution Context
 
    The following claims are defined by this specification:
@@ -584,7 +524,9 @@ Internet-Draft           WIMSE Execution Context           February 2026
       representing DAG dependencies.  Each element MUST be the "jti"
       value of a previously verified ECT.  An empty array indicates a
       root task with no dependencies.  A workflow MAY contain multiple
-      root tasks.
+      root tasks.  Parent ECTs may have passed their own "exp" time; ECT
+      expiration applies to the verification window of the ECT itself,
+      not to its validity as a parent reference in the ECT store.
 
 4.2.3.  Data Integrity
 
@@ -606,32 +548,20 @@ Internet-Draft           WIMSE Execution Context           February 2026
       data, using the same format and algorithm requirements as
       "inp_hash".
 
-
-
-
-
-
-
-
-Nennemann                Expires 29 August 2026                [Page 11]
-
-Internet-Draft           WIMSE Execution Context           February 2026
-
-
-4.2.4.  Compensation and Rollback
-
-   Compensation and rollback extensions are defined in
-   [I-D.nennemann-wimse-ect-pol].  The referenced parent ECTs may have
-   passed their own "exp" time; ECT expiration applies to the
-   verification window of the ECT itself, not to its validity as a
-   parent reference in the ECT store.
-
-4.2.5.  Extensions
+4.2.4.  Extensions
 
    ext:  OPTIONAL.  Object.  An extension object for domain-specific
       claims not defined by this specification.  Implementations that do
       not understand extension claims MUST ignore them.
 
+
+
+
+Nennemann                Expires 29 August 2026                [Page 10]
+
+Internet-Draft           WIMSE Execution Context           February 2026
+
+
    To avoid key collisions between different domains, extension key
    names SHOULD use reverse domain notation (e.g.,
    "com.example.custom_field") to avoid collisions between independently
@@ -641,38 +571,8 @@ Internet-Draft           WIMSE Execution Context           February 2026
    NOT exceed 5 levels.  Implementations SHOULD reject ECTs whose "ext"
    claim exceeds these limits.
 
-   The following extension keys are defined by this specification for
-   common use cases.  Because these keys are documented here, they use
-   short names without reverse domain prefixes:
-
-   *  "exec_time_ms": Integer.  Execution duration in milliseconds.
-
-   *  "regulated_domain": String.  Regulatory domain (e.g., "medtech",
-      "finance", "military").
-
-   *  "model_version": String.  AI/ML model version.
-
-   *  "witnessed_by": Array of StringOrURI.  Identifiers of third-party
-      entities that the issuer claims observed the task.  Note: this is
-      self-asserted; for verifiable witness attestation, witnesses
-      should submit independent signed ECTs.
-
-   *  "inp_classification": String.  Data sensitivity classification
-      (e.g., "public", "confidential", "restricted").
-
-   Additional extension keys for policy evaluation and compensation are
-   defined in [I-D.nennemann-wimse-ect-pol].
-
-
-
-
-
-
-
-Nennemann                Expires 29 August 2026                [Page 12]
-
-Internet-Draft           WIMSE Execution Context           February 2026
-
+   Extension keys for domain-specific use cases MAY be defined in future
+   documents.
 
 4.3.  Complete ECT Example
 
@@ -690,13 +590,7 @@ Internet-Draft           WIMSE Execution Context           February 2026
      "par": [],
 
      "inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
-     "out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564",
-
-     "ext": {
-       "exec_time_ms": 245,
-       "regulated_domain": "medtech",
-       "model_version": "clinical-reasoning-v4.2"
-     }
+     "out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564"
    }
 
                    Figure 4: Complete ECT Payload Example
@@ -715,6 +609,15 @@ Internet-Draft           WIMSE Execution Context           February 2026
    An agent sending a request to another agent includes the Execution-
    Context header alongside the WIMSE Workload-Identity header:
 
+
+
+
+
+Nennemann                Expires 29 August 2026                [Page 11]
+
+Internet-Draft           WIMSE Execution Context           February 2026
+
+
    GET /api/safety-check HTTP/1.1
    Host: safety-agent.example.com
    Workload-Identity: eyJhbGci...WIT...
@@ -722,14 +625,6 @@ Internet-Draft           WIMSE Execution Context           February 2026
 
                    Figure 5: HTTP Request with ECT Header
 
-
-
-
-Nennemann                Expires 29 August 2026                [Page 13]
-
-Internet-Draft           WIMSE Execution Context           February 2026
-
-
    When multiple parent tasks contribute context to a single request,
    multiple Execution-Context header field lines MAY be included, each
    carrying a separate ECT in JWS Compact Serialization format.
@@ -774,14 +669,7 @@ Internet-Draft           WIMSE Execution Context           February 2026
 
 
 
-
-
-
-
-
-
-
-Nennemann                Expires 29 August 2026                [Page 14]
+Nennemann                Expires 29 August 2026                [Page 12]
 
 Internet-Draft           WIMSE Execution Context           February 2026
 
@@ -805,103 +693,10 @@ Internet-Draft           WIMSE Execution Context           February 2026
        trust domain or to a trust domain with which a federation
        relationship has been established.
 
-6.3.  DAG Validation Algorithm
-
-   The following pseudocode describes the DAG validation procedure:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nennemann                Expires 29 August 2026                [Page 15]
-
-Internet-Draft           WIMSE Execution Context           February 2026
-
-
-   function validate_dag(ect, ect_store, clock_skew_tolerance):
-     // Step 1: Uniqueness check
-     if ect_store.contains(ect.jti, ect.wid):
-       return error("ECT ID already exists")
-
-     // Step 2: Parent existence and temporal ordering
-     for parent_id in ect.par:
-       parent = ect_store.get(parent_id)
-       if parent is null:
-         return error("Parent task not found: " + parent_id)
-       if parent.iat >= ect.iat + clock_skew_tolerance:
-         return error("Parent task not earlier than current")
-
-     // Step 3: Cycle detection (with traversal limit)
-     visited = set()
-     result = has_cycle(ect.jti, ect.par, ect_store, visited,
-                         max_ancestor_limit)
-     if result is error or result is true:
-       return error("Circular dependency or depth limit exceeded")
-
-     return success
-
-   function has_cycle(target_jti, parent_ids, ect_store,
-                      visited, max_depth):
-     if visited.size() >= max_depth:
-       return error("Maximum ancestor traversal limit exceeded")
-     for parent_id in parent_ids:
-       if parent_id == target_jti:
-         return true
-       if parent_id in visited:
-         continue
-       visited.add(parent_id)
-       parent = ect_store.get(parent_id)
-       if parent is not null:
-         result = has_cycle(target_jti, parent.par, ect_store,
-                             visited, max_depth)
-         if result is error or result is true:
-           return result
-     return false
-
-                    Figure 6: DAG Validation Pseudocode
-
-   The cycle detection traverses the ancestor graph rooted at the
-   current task's parents.  The complexity is O(V) where V is the number
-   of ancestor nodes reachable from the current task's parent
-   references.  For typical workflows with shallow DAGs, this is
-   efficient.  To prevent denial-of-service via extremely deep or wide
-   DAGs, implementations SHOULD enforce a maximum ancestor traversal
-
-
-
-Nennemann                Expires 29 August 2026                [Page 16]
-
-Internet-Draft           WIMSE Execution Context           February 2026
-
-
-   limit (RECOMMENDED: 10000 nodes).  If the limit is reached before
-   cycle detection completes, the ECT SHOULD be rejected.
-   Implementations SHOULD cache cycle detection results for previously
-   verified tasks to avoid redundant traversals.
+   To prevent denial-of-service via extremely deep or wide DAGs,
+   implementations SHOULD enforce a maximum ancestor traversal limit
+   (RECOMMENDED: 10000 nodes).  If the limit is reached before cycle
+   detection completes, the ECT SHOULD be rejected.
 
 7.  Signature and Token Verification
 
@@ -924,6 +719,17 @@ Internet-Draft           WIMSE Execution Context           February 2026
    5.   Retrieve the public key identified by "kid" and verify the JWS
         signature per [RFC7515] Section 5.2.
 
+
+
+
+
+
+
+Nennemann                Expires 29 August 2026                [Page 13]
+
+Internet-Draft           WIMSE Execution Context           February 2026
+
+
    6.   Verify that the signing key identified by "kid" has not been
         revoked within the trust domain.  Implementations MUST check the
         key's revocation status using the trust domain's key lifecycle
@@ -945,15 +751,6 @@ Internet-Draft           WIMSE Execution Context           February 2026
 
    10.  Verify the "exp" claim indicates the ECT has not expired.
 
-
-
-
-
-Nennemann                Expires 29 August 2026                [Page 17]
-
-Internet-Draft           WIMSE Execution Context           February 2026
-
-
    11.  Verify the "iat" claim is not unreasonably far in the past
         (implementation-specific threshold, RECOMMENDED maximum of 15
         minutes) and is not unreasonably far in the future (RECOMMENDED:
@@ -981,87 +778,10 @@ Internet-Draft           WIMSE Execution Context           February 2026
    step failed.  The receiving agent MUST NOT process the requested
    action when ECT verification fails.
 
-7.2.  Verification Pseudocode
-
-   function verify_ect(ect_jws, verifier_id,
-                        trust_domain_keys, ect_store):
-     // Parse JWS
-     (header, payload, signature) = parse_jws(ect_jws)
-
-     // Verify header
-     if header.typ != "wimse-exec+jwt":
-       return reject("Invalid typ parameter")
-
-     if header.alg == "none" or is_symmetric(header.alg):
-       return reject("Prohibited algorithm")
-
-     // Look up public key
-     public_key = trust_domain_keys.get(header.kid)
-     if public_key is null:
-       return reject("Unknown key identifier")
-
-     // Verify signature
-     if not verify_jws_signature(header, payload,
 
 
 
-Nennemann                Expires 29 August 2026                [Page 18]
-
-Internet-Draft           WIMSE Execution Context           February 2026
-
-
-                                  signature, public_key):
-       return reject("Invalid signature")
-
-     // Verify key not revoked
-     if is_key_revoked(header.kid, trust_domain_keys):
-       return reject("Signing key has been revoked")
-
-     // Verify algorithm alignment
-     wit = get_wit_for_key(header.kid)
-     if header.alg != wit.alg:
-       return reject("Algorithm mismatch with WIT")
-
-     // Verify issuer matches WIT subject
-     if payload.iss != wit.sub:
-       return reject("Issuer does not match WIT subject")
-
-     // Verify audience
-     if verifier_id not in payload.aud:
-       return reject("ECT not intended for this recipient")
-
-     // Verify not expired
-     if payload.exp < current_time():
-       return reject("ECT has expired")
-
-     // Verify iat freshness (not too old, not in the future)
-     if payload.iat < current_time() - max_age_threshold:
-       return reject("ECT issued too long ago")
-     if payload.iat > current_time() + clock_skew_tolerance:
-       return reject("ECT issued in the future")
-
-     // Verify required claims
-     for claim in ["jti", "exec_act", "par"]:
-       if claim not in payload:
-         return reject("Missing required claim: " + claim)
-
-     // Validate DAG (against ECT store or inline parent ECTs)
-     result = validate_dag(payload, ect_store,
-                            clock_skew_tolerance)
-     if result is error:
-       return reject("DAG validation failed")
-
-     // All checks passed; record if store is available
-     if ect_store is not null:
-       ect_store.append(payload)
-     return accept
-
-                   Figure 7: ECT Verification Pseudocode
-
-
-
-
-Nennemann                Expires 29 August 2026                [Page 19]
+Nennemann                Expires 29 August 2026                [Page 14]
 
 Internet-Draft           WIMSE Execution Context           February 2026
 
@@ -1117,7 +837,7 @@ Internet-Draft           WIMSE Execution Context           February 2026
 
 
 
-Nennemann                Expires 29 August 2026                [Page 20]
+Nennemann                Expires 29 August 2026                [Page 15]
 
 Internet-Draft           WIMSE Execution Context           February 2026
 
@@ -1138,20 +858,8 @@ Internet-Draft           WIMSE Execution Context           February 2026
    *  The agent faithfully performed the stated action
 
    The trustworthiness of ECT claims depends on the trustworthiness of
-   the signing agent.  To mitigate single-agent false claims, regulated
-   environments SHOULD use the "witnessed_by" extension key (carried in
-   "ext") to include independent third-party observers at critical
-   decision points.  However, this value is self-asserted by the ECT
-   issuer: the listed witnesses do not co-sign the ECT and there is no
-   cryptographic evidence within a single ECT that the witnesses
-   actually observed the task.  An issuing agent could list witnesses
-   that did not participate.
-
-   To strengthen witness attestation beyond self-assertion, witnesses
-   SHOULD submit their own independent signed ECTs referencing the
-   observed task's "jti" in the "par" array.  Auditors can then cross-
-   check the "witnessed_by" extension against independent witness ECTs
-   in the ECT store.
+   the signing agent and the integrity of the broader deployment
+   environment.
 
 9.3.  Organizational Prerequisites
 
@@ -1168,16 +876,6 @@ Internet-Draft           WIMSE Execution Context           February 2026
    *  Agent deployment governance: Agents are deployed and maintained in
       a manner that preserves their integrity.
 
-
-
-
-
-
-Nennemann                Expires 29 August 2026                [Page 21]
-
-Internet-Draft           WIMSE Execution Context           February 2026
-
-
 9.4.  Signature Verification
 
    ECTs MUST be signed with the agent's private key using JWS [RFC7515].
@@ -1191,6 +889,15 @@ Internet-Draft           WIMSE Execution Context           February 2026
    revoked, the ECT MUST be rejected entirely and the failure MUST be
    logged.
 
+
+
+
+
+Nennemann                Expires 29 August 2026                [Page 16]
+
+Internet-Draft           WIMSE Execution Context           February 2026
+
+
    Implementations MUST use established JWS libraries and MUST NOT
    implement custom signature verification.
 
@@ -1227,13 +934,6 @@ Internet-Draft           WIMSE Execution Context           February 2026
 
    *  ECT (execution accountability layer): Records what the agent did.
 
-
-
-Nennemann                Expires 29 August 2026                [Page 22]
-
-Internet-Draft           WIMSE Execution Context           February 2026
-
-
 9.7.  Key Compromise
 
    If an agent's private key is compromised, an attacker can forge ECTs
@@ -1247,6 +947,13 @@ Internet-Draft           WIMSE Execution Context           February 2026
 
    *  Trust domains MUST support rapid key revocation.
 
+
+
+Nennemann                Expires 29 August 2026                [Page 17]
+
+Internet-Draft           WIMSE Execution Context           February 2026
+
+
    *  Upon suspected compromise, the trust domain MUST revoke the
       compromised key and issue a new WIT with a fresh key pair.
 
@@ -1267,29 +974,12 @@ Internet-Draft           WIMSE Execution Context           February 2026
    *  Independent ledger maintenance: The ledger SHOULD be maintained by
       an entity independent of the workflow agents.
 
-   *  Witness attestation: Using the "witnessed_by" extension key in
-      "ext" to include independent third-party observers.
-
    *  Cross-verification: Multiple independent ledger replicas can be
       compared for consistency.
 
    *  Out-of-band audit: External auditors periodically verify ledger
       contents against expected workflow patterns.
 
-
-
-
-
-
-
-
-
-
-Nennemann                Expires 29 August 2026                [Page 23]
-
-Internet-Draft           WIMSE Execution Context           February 2026
-
-
 9.9.  Denial of Service
 
    ECT signature verification is computationally inexpensive
@@ -1311,6 +1001,15 @@ Internet-Draft           WIMSE Execution Context           February 2026
    SHOULD allow a configurable clock skew tolerance (RECOMMENDED: 30
    seconds).
 
+
+
+
+
+Nennemann                Expires 29 August 2026                [Page 18]
+
+Internet-Draft           WIMSE Execution Context           February 2026
+
+
    Cross-organizational deployments where agents span multiple trust
    domains with independent time sources MAY require a higher clock skew
    tolerance.  Deployments using trust domain federation SHOULD document
@@ -1327,7 +1026,7 @@ Internet-Draft           WIMSE Execution Context           February 2026
    maximum of 256 entries.  Workflows requiring more parent references
    SHOULD introduce intermediate aggregation tasks.  The "ext" object
    SHOULD NOT exceed 4096 bytes when serialized as JSON and SHOULD NOT
-   exceed a nesting depth of 5 levels (see also Section 4.2.5).
+   exceed a nesting depth of 5 levels (see also Section 4.2.4).
 
 10.  Privacy Considerations
 
@@ -1339,13 +1038,6 @@ Internet-Draft           WIMSE Execution Context           February 2026
 
    *  Action descriptions ("exec_act") for audit trail completeness
 
-
-
-Nennemann                Expires 29 August 2026                [Page 24]
-
-Internet-Draft           WIMSE Execution Context           February 2026
-
-
    *  Timestamps ("iat", "exp") for temporal ordering
 
    ECTs are designed to NOT reveal:
@@ -1359,33 +1051,43 @@ Internet-Draft           WIMSE Execution Context           February 2026
 
    *  Personally identifiable information (PII)
 
+
+
+
+
+
+
+
+
+
+
+Nennemann                Expires 29 August 2026                [Page 19]
+
+Internet-Draft           WIMSE Execution Context           February 2026
+
+
 10.2.  Data Minimization
 
    Implementations SHOULD minimize the information included in ECTs.
    The "exec_act" claim SHOULD use structured identifiers (e.g.,
    "process_payment") rather than natural language descriptions.
-   Extension keys in "ext" (Section 4.2.5) deserve particular attention:
+   Extension keys in "ext" (Section 4.2.4) deserve particular attention:
    human-readable values risk exposing sensitive operational details.
-   See Section 4.2.5 for guidance on using structured identifiers.
+   See Section 4.2.4 for guidance on using structured identifiers.
 
 10.3.  Storage and Access Control
 
    ECTs stored in audit ledgers SHOULD be access-controlled so that only
-   authorized auditors and regulators can read them.  Implementations
-   SHOULD consider encryption at rest for ledger storage containing
-   sensitive regulatory data.
+   authorized auditors can read them.  Implementations SHOULD consider
+   encryption at rest for ledger storage.  ECTs provide structural
+   records of execution ordering; they are not intended for public
+   disclosure.
 
    Full input and output data (corresponding to the hashes in ECTs)
    SHOULD be stored separately from the ledger with additional access
    controls, since auditors may need to verify hash correctness but
    general access to the data values is not needed.
 
-10.4.  Regulatory Access
-
-   ECTs are designed for interpretation by qualified human auditors and
-   regulators.  ECTs provide structural records of execution ordering;
-   they are not intended for public disclosure.
-
 11.  IANA Considerations
 
 11.1.  Media Type Registration
@@ -1395,13 +1097,6 @@ Internet-Draft           WIMSE Execution Context           February 2026
 
    Type name:  application
 
-
-
-Nennemann                Expires 29 August 2026                [Page 25]
-
-Internet-Draft           WIMSE Execution Context           February 2026
-
-
    Subtype name:  wimse-exec+jwt
 
    Required parameters:  none
@@ -1419,9 +1114,17 @@ Internet-Draft           WIMSE Execution Context           February 2026
 
    Published specification:  This document
 
+
+
+
+Nennemann                Expires 29 August 2026                [Page 20]
+
+Internet-Draft           WIMSE Execution Context           February 2026
+
+
    Applications that use this media type:  Applications that implement
-      regulated agentic workflows requiring execution context tracing
-      and audit trails.
+      agentic workflows requiring execution context tracing and audit
+      trails.
 
    Additional information:  Magic number(s): none File extension(s):
       none Macintosh file type code(s): none
@@ -1449,20 +1152,32 @@ Internet-Draft           WIMSE Execution Context           February 2026
 
    Specification document:  This document, Section 5
 
-
-
-
-
-Nennemann                Expires 29 August 2026                [Page 26]
-
-Internet-Draft           WIMSE Execution Context           February 2026
-
-
 11.3.  JWT Claims Registration
 
    This document requests registration of the following claims in the
    "JSON Web Token Claims" registry maintained by IANA:
 
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nennemann                Expires 29 August 2026                [Page 21]
+
+Internet-Draft           WIMSE Execution Context           February 2026
+
+
    +============+=====================+===================+===========+
    | Claim Name | Claim Description   | Change Controller | Reference |
    +============+=====================+===================+===========+
@@ -1482,14 +1197,11 @@ Internet-Draft           WIMSE Execution Context           February 2026
    |            |                     |                   |   4.2.3   |
    +------------+---------------------+-------------------+-----------+
    |    ext     | Extension Object    |        IETF       |  Section  |
-   |            |                     |                   |   4.2.5   |
+   |            |                     |                   |   4.2.4   |
    +------------+---------------------+-------------------+-----------+
 
                     Table 1: JWT Claims Registrations
 
-   Policy evaluation claims and the ECT Policy Decision Values registry
-   are defined in [I-D.nennemann-wimse-ect-pol].
-
 12.  References
 
 12.1.  Normative References
@@ -1506,14 +1218,6 @@ Internet-Draft           WIMSE Execution Context           February 2026
               Campbell, B., Salowey, J. A., Schwenkschuster, A., and Y.
               Sheffer, "WIMSE Workload-to-Workload Authentication", Work
               in Progress, Internet-Draft, draft-ietf-wimse-s2s-
-
-
-
-Nennemann                Expires 29 August 2026                [Page 27]
-
-Internet-Draft           WIMSE Execution Context           February 2026
-
-
               protocol-07, 16 October 2025,
               <https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
               s2s-protocol-07>.
@@ -1523,6 +1227,13 @@ Internet-Draft           WIMSE Execution Context           February 2026
               DOI 10.17487/RFC2119, March 1997,
               <https://www.rfc-editor.org/rfc/rfc2119>.
 
+
+
+Nennemann                Expires 29 August 2026                [Page 22]
+
+Internet-Draft           WIMSE Execution Context           February 2026
+
+
    [RFC7515]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
               Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
               2015, <https://www.rfc-editor.org/rfc/rfc7515>.
@@ -1554,36 +1265,6 @@ Internet-Draft           WIMSE Execution Context           February 2026
 
 12.2.  Informative References
 
-   [DORA]     European Parliament and Council of the European Union,
-              "Regulation (EU) 2022/2554 on digital operational
-              resilience for the financial sector (DORA)", 14 December
-              2022, <https://eur-lex.europa.eu/eli/reg/2022/2554>.
-
-   [EU-AI-ACT]
-              European Parliament and Council of the European Union,
-              "Regulation (EU) 2024/1689 of the European Parliament and
-
-
-
-Nennemann                Expires 29 August 2026                [Page 28]
-
-Internet-Draft           WIMSE Execution Context           February 2026
-
-
-              of the Council laying down harmonised rules on artificial
-              intelligence (Artificial Intelligence Act)", 13 June 2024,
-              <https://eur-lex.europa.eu/eli/reg/2024/1689>.
-
-   [EU-MDR]   European Parliament and Council of the European Union,
-              "Regulation (EU) 2017/745 on medical devices (MDR)", 5
-              April 2017, <https://eur-lex.europa.eu/eli/reg/2017/745>.
-
-   [FDA-21CFR11]
-              U.S. Food and Drug Administration, "Title 21, Code of
-              Federal Regulations, Part 11: Electronic Records;
-              Electronic Signatures", <https://www.ecfr.gov/current/
-              title-21/chapter-I/subchapter-A/part-11>.
-
    [I-D.ietf-oauth-transaction-tokens]
               Tulshibagwale, A., Fletcher, G., and P. Kasselman,
               "Transaction Tokens", Work in Progress, Internet-Draft,
@@ -1599,11 +1280,15 @@ Internet-Draft           WIMSE Execution Context           February 2026
               October 2025, <https://datatracker.ietf.org/doc/html/
               draft-ietf-scitt-architecture-22>.
 
-   [I-D.nennemann-wimse-ect-pol]
-              Nennemann, C., "Policy Evaluation and Compensation
-              Extensions for Execution Context Tokens",
-              <https://datatracker.ietf.org/doc/draft-nennemann-wimse-
-              ect-pol/>.
+
+
+
+
+
+Nennemann                Expires 29 August 2026                [Page 23]
+
+Internet-Draft           WIMSE Execution Context           February 2026
+
 
    [I-D.ni-wimse-ai-agent-identity]
               Yuan, N. and P. C. Liu, "WIMSE Applicability for AI
@@ -1619,19 +1304,6 @@ Internet-Draft           WIMSE Execution Context           February 2026
               <https://datatracker.ietf.org/doc/html/draft-oauth-
               transaction-tokens-for-agents-04>.
 
-
-
-Nennemann                Expires 29 August 2026                [Page 29]
-
-Internet-Draft           WIMSE Execution Context           February 2026
-
-
-   [MIFID-II] European Parliament and Council of the European Union,
-              "Directive 2014/65/EU of the European Parliament and of
-              the Council on markets in financial instruments (MiFID
-              II)", 15 May 2014,
-              <https://eur-lex.europa.eu/eli/dir/2014/65>.
-
    [OPENTELEMETRY]
               Cloud Native Computing Foundation, "OpenTelemetry
               Specification",
@@ -1657,128 +1329,23 @@ Internet-Draft           WIMSE Execution Context           February 2026
 
 Use Cases
 
-   This section describes representative use cases demonstrating how
-   ECTs provide execution records in regulated environments.  These
-   examples demonstrate ECT mechanics; production deployments would
-   include additional domain-specific requirements beyond the scope of
-   this specification.
+   This section describes a representative use case demonstrating how
+   ECTs provide structured execution records.
 
    Note: task identifiers in this section are abbreviated for
    readability.  In production, all "jti" values are required to be
    UUIDs per Section 4.2.2.
 
-Medical Device SDLC Workflow
-
-   In a medical device software development lifecycle (SDLC), AI agents
-   assist across multiple phases from requirements analysis through
-   release approval.  Regulatory frameworks including [FDA-21CFR11]
-   Section 11.10(e) and [EU-MDR] require audit trails documenting the
-   complete development process for software used in medical devices.
 
 
 
-Nennemann                Expires 29 August 2026                [Page 30]
+
+
+Nennemann                Expires 29 August 2026                [Page 24]
 
 Internet-Draft           WIMSE Execution Context           February 2026
 
 
-   Agent A (Spec Reviewer):
-     jti: task-001    par: []
-     exec_act: review_requirements_spec
-
-   Agent B (Code Generator):
-     jti: task-002    par: [task-001]
-     exec_act: implement_module
-
-   Agent C (Test Agent):
-     jti: task-003    par: [task-002]
-     exec_act: execute_test_suite
-
-   Agent D (Build Agent):
-     jti: task-004    par: [task-003]
-     exec_act: build_release_artifact
-
-   Human Release Manager:
-     jti: task-005    par: [task-004]
-     exec_act: approve_release
-     ext: {witnessed_by: [...]}  (extension metadata)
-
-                   Figure 8: Medical Device SDLC Workflow
-
-   ECTs record that requirements were reviewed before implementation
-   began, that tests were executed against the implemented code, that
-   the build artifact was validated, and that a human release manager
-   explicitly approved the release.  The DAG structure ensures no phase
-   was skipped or reordered.
-
-FDA Audit with DAG Reconstruction
-
-   During a regulatory audit, an FDA reviewer requests evidence of the
-   development process for a specific software release.  The auditing
-   authority retrieves all ECTs sharing the same workflow identifier
-   ("wid") from the audit ledger and reconstructs the complete DAG:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nennemann                Expires 29 August 2026                [Page 31]
-
-Internet-Draft           WIMSE Execution Context           February 2026
-
-
-   task-001 (review_requirements_spec)
-     |
-     v
-   task-002 (implement_module)
-     |
-     v
-   task-003 (execute_test_suite)
-     |
-     v
-   task-004 (build_release_artifact)
-     |
-     v
-   task-005 (approve_release) [human, witnessed]
-
-                 Figure 9: Reconstructed DAG for FDA Audit
-
-   The reconstructed DAG provides cryptographic evidence that:
-
-   *  Each phase was executed by an identified and authenticated agent.
-
-   *  The execution sequence was maintained (no step was bypassed).
-
-   *  A human-in-the-loop approved the final release, with independent
-      witness attestation.
-
-   *  Timestamps and execution durations are recorded for each step.
-
-   This can contribute to compliance with:
-
-   *  [FDA-21CFR11] Section 11.10(e): Computer-generated audit trails
-      that record the date, time, and identity of the operator.
-
-   *  [EU-MDR] Annex II: Technical documentation traceability for the
-      software development lifecycle.
-
-   *  [EU-AI-ACT] Article 12: Automatic logging capabilities for high-
-      risk AI systems involved in the development process.
-
-   *  [EU-AI-ACT] Article 14: ECTs can record evidence that human
-      oversight events occurred during the release process.
-
 Cross-Organization Financial Trading
 
    In a cross-organization trading workflow, an investment bank's agents
@@ -1787,13 +1354,6 @@ Cross-Organization Financial Trading
    records that independent assessments from both organizations were
    completed before trade execution.
 
-
-
-Nennemann                Expires 29 August 2026                [Page 32]
-
-Internet-Draft           WIMSE Execution Context           February 2026
-
-
    Trust Domain: bank.example
      Agent A1 (Portfolio Risk):
        jti: task-001    par: []
@@ -1817,7 +1377,7 @@ Internet-Draft           WIMSE Execution Context           February 2026
        iss: spiffe://bank.example/agent/execution
        exec_act: execute_trade
 
-               Figure 10: Cross-Organization Trading Workflow
+               Figure 6: Cross-Organization Trading Workflow
 
    The resulting DAG:
 
@@ -1832,80 +1392,21 @@ Internet-Draft           WIMSE Execution Context           February 2026
             task-004 (execute_trade)
               [bank.example]
 
-                     Figure 11: Cross-Organization DAG
+                      Figure 7: Cross-Organization DAG
+
+
+
+
+Nennemann                Expires 29 August 2026                [Page 25]
+
+Internet-Draft           WIMSE Execution Context           February 2026
+
 
    Task 003 has two parents from different trust domains, demonstrating
    cross-organizational fan-in.  The compliance agent verifies both
    parent ECTs — one signed by a local key and one by a federated key
    from the rating agency's trust domain.
 
-   This can contribute to compliance with:
-
-
-
-
-
-Nennemann                Expires 29 August 2026                [Page 33]
-
-Internet-Draft           WIMSE Execution Context           February 2026
-
-
-   *  [MIFID-II]: ECTs provide cryptographic records of the execution
-      sequence that can support transaction audit requirements.
-
-   *  [DORA] Article 12: ECTs contribute to ICT activity logging.
-
-   *  [EU-AI-ACT] Article 12: Logging of decisions made by AI-driven
-      systems.
-
-Compensation and Rollback
-
-   Compensation and rollback use cases are described in
-   [I-D.nennemann-wimse-ect-pol].  The core ECT mechanism supports
-   compensation through the "par" claim, which links a remediation ECT
-   to the original task.
-
-Autonomous Logistics Coordination
-
-   In a logistics workflow, multiple compliance checks complete before
-   shipment commitment.  The DAG structure records that all required
-   checks were completed:
-
-   Agent A (Route Planning):
-     jti: task-001    par: []
-     exec_act: plan_route
-
-   Agent B (Customs):
-     jti: task-002    par: [task-001]
-     exec_act: validate_customs
-
-   Agent C (Safety):
-     jti: task-003    par: [task-001]
-     exec_act: verify_cargo_safety
-
-   Agent D (Payment):
-     jti: task-004    par: [task-002, task-003]
-     exec_act: authorize_payment
-
-   System (Commitment):
-     jti: task-005    par: [task-004]
-     exec_act: commit_shipment
-
-             Figure 12: Logistics Workflow with Parallel Tasks
-
-   Note that tasks 002 and 003 both depend only on task-001 and can
-   execute in parallel.  Task 004 depends on both, demonstrating the
-   DAG's ability to represent parallel execution with a join point.
-
-
-
-
-
-Nennemann                Expires 29 August 2026                [Page 34]
-
-Internet-Draft           WIMSE Execution Context           February 2026
-
-
 Related Work
 
 WIMSE Workload Identity
@@ -1949,19 +1450,18 @@ Transaction Tokens
       downstream services, each receives the same "req_wl" value and the
       branching is invisible.
 
-   *  It is incomplete: only workloads that request a replacement token
-      from the Transaction Token Service appear in "req_wl"; workloads
-      that forward the token unchanged are not recorded.
 
 
 
-
-
-Nennemann                Expires 29 August 2026                [Page 35]
+Nennemann                Expires 29 August 2026                [Page 26]
 
 Internet-Draft           WIMSE Execution Context           February 2026
 
 
+   *  It is incomplete: only workloads that request a replacement token
+      from the Transaction Token Service appear in "req_wl"; workloads
+      that forward the token unchanged are not recorded.
+
    *  It carries no task-level granularity, no parent references, and no
       execution content.
 
@@ -1994,440 +1494,26 @@ Distributed Tracing (OpenTelemetry)
    while ECTs provide signed execution records.  ECTs may reference
    OpenTelemetry trace identifiers in the "ext" claim for correlation.
 
-Blockchain and Distributed Ledgers
-
-   Both ECTs and blockchain systems provide immutable records.  This
-   specification intentionally defines only the ECT token format and is
-   agnostic to the storage mechanism.  ECTs can be stored in append-only
-   logs, databases with cryptographic commitments, blockchain networks,
-   or any storage providing the required properties defined in
-   Section 8.
-
-
-
-
-
-
-
-
-
-
-
-Nennemann                Expires 29 August 2026                [Page 36]
-
-Internet-Draft           WIMSE Execution Context           February 2026
-
-
 SCITT (Supply Chain Integrity, Transparency, and Trust)
 
    The SCITT architecture [I-D.ietf-scitt-architecture] defines a
-   framework for creating transparent and auditable supply chain records
-   through Transparency Services, Signed Statements, and Receipts.  ECTs
-   and SCITT are naturally complementary: the ECT "wid" (Workflow
-   Identifier) claim can serve as a correlation identifier referenced in
-   SCITT Signed Statements, linking a complete ECT audit trail to a
-   supply chain transparency record.  For example, in a regulated
-   manufacturing workflow, each agent step produces an ECT (recording
-   what was done, by whom, under under what constraints), while the
-   overall workflow identified by "wid" is registered as a SCITT Signed
-   Statement on a Transparency Service.  This enables auditors to verify
-   both the individual execution steps (via ECT DAG validation) and the
-   end-to-end supply chain integrity (via SCITT Receipts) using the
-   "wid" as the shared correlation point.  The "ext" claim in ECTs
-   (Section 4.2.2) can carry SCITT-specific metadata such as
-   Transparency Service identifiers or Receipt references for tighter
-   integration.
-
-W3C Verifiable Credentials
-
-   W3C Verifiable Credentials represent claims about subjects (e.g.,
-   identity, qualifications).  ECTs represent execution records of
-   actions (what happened, in what order).  While both use JWT/JWS as a
-   serialization format, their semantics and use cases are distinct.
-
-Implementation Guidance
-
-Minimal Implementation
-
-   A minimal conforming implementation needs to:
-
-   1.  Create JWTs with all required claims ("iss", "aud", "iat", "exp",
-       "jti", "exec_act", "par").
-
-   2.  Sign ECTs with the agent's private key using an algorithm
-       matching the WIT (ES256 recommended).
-
-   3.  Verify ECT signatures against WIT public keys.
-
-   4.  Perform DAG validation (parent existence, temporal ordering,
-       cycle detection).
-
-   5.  If an audit ledger is deployed, append verified ECTs to it.
+   framework for transparent and auditable supply chain records.  ECTs
+   and SCITT are complementary: the ECT "wid" claim can serve as a
+   correlation identifier in SCITT Signed Statements, linking an ECT
+   audit trail to a supply chain transparency record.
 
 
 
 
 
 
-Nennemann                Expires 29 August 2026                [Page 37]
+
+
+Nennemann                Expires 29 August 2026                [Page 27]
 
 Internet-Draft           WIMSE Execution Context           February 2026
 
 
-Storage Recommendations
-
-   *  Append-only log: Simplest approach; immutability by design.
-
-   *  Database with hash chains: Periodic cryptographic commitments over
-      batches of entries.
-
-   *  Distributed ledger: Maximum immutability guarantees for cross-
-      organizational audit.
-
-   *  Hybrid: Hot storage in a database, cold archive in immutable
-      storage.
-
-Performance Considerations
-
-   *  ES256 signature verification: approximately 1ms per ECT on modern
-      hardware.
-
-   *  DAG validation: O(V) where V is the number of reachable ancestor
-      nodes (typically small for shallow workflows).
-
-   *  JSON serialization: sub-millisecond per ECT.
-
-   *  Total per-request overhead: approximately 5-10ms, acceptable for
-      regulated workflows where correctness is prioritized over latency.
-
-Interoperability
-
-   Implementations are expected to use established JWT/JWS libraries
-   (JOSE) for token creation and verification.  Custom cryptographic
-   implementations are strongly discouraged.  Implementations are
-   expected to be tested against multiple JWT libraries to ensure
-   interoperability.
-
-Regulatory Compliance Mapping
-
-   The following table summarizes how ECTs can contribute to compliance
-   with various regulatory frameworks.  ECTs are a technical building
-   block; achieving compliance requires additional organizational
-   measures beyond this specification.
-
-
-
-
-
-
-
-
-
-
-
-Nennemann                Expires 29 August 2026                [Page 38]
-
-Internet-Draft           WIMSE Execution Context           February 2026
-
-
-    +============+========================+==========================+
-    | Regulation | Requirement            | ECT Contribution         |
-    +============+========================+==========================+
-    | FDA 21 CFR | Audit trails recording | Cryptographic signatures |
-    | Part 11    | date, time, operator,  | and append-only ledger   |
-    |            | actions (11.10(e))     | contribute to audit      |
-    |            |                        | trail requirements       |
-    +------------+------------------------+--------------------------+
-    | EU MDR     | Technical              | ECTs provide signed      |
-    |            | documentation          | records of AI-assisted   |
-    |            | traceability (Annex    | decision sequences       |
-    |            | II)                    |                          |
-    +------------+------------------------+--------------------------+
-    | EU AI Act  | Automatic logging      | ECTs contribute          |
-    | Art. 12    | capabilities for high- | cryptographic activity   |
-    |            | risk AI                | logging                  |
-    +------------+------------------------+--------------------------+
-    | EU AI Act  | Human oversight        | ECTs can record evidence |
-    | Art. 14    | capability             | that human oversight     |
-    |            |                        | events occurred          |
-    +------------+------------------------+--------------------------+
-    | MiFID II   | Transaction records    | ECTs provide             |
-    |            | for supervisory        | cryptographic execution  |
-    |            | authorities            | sequence records         |
-    +------------+------------------------+--------------------------+
-    | DORA Art.  | ICT activity logging   | ECT ledger contributes   |
-    | 12         | policies               | to ICT activity audit    |
-    |            |                        | trail                    |
-    +------------+------------------------+--------------------------+
-
-                  Table 2: Regulatory Compliance Mapping
-
-Examples
-
-Example 1: Simple Two-Agent Workflow
-
-   Agent A executes a data retrieval task and sends the ECT to Agent B:
-
-   ECT JOSE Header:
-
-   {
-     "alg": "ES256",
-     "typ": "wimse-exec+jwt",
-     "kid": "agent-a-key-2026-02"
-   }
-
-   ECT Payload:
-
-
-
-
-Nennemann                Expires 29 August 2026                [Page 39]
-
-Internet-Draft           WIMSE Execution Context           February 2026
-
-
-   {
-     "iss": "spiffe://example.com/agent/data-retrieval",
-     "aud": "spiffe://example.com/agent/validator",
-     "iat": 1772064150,
-     "exp": 1772064750,
-     "jti": "550e8400-e29b-41d4-a716-446655440001",
-     "wid": "b1c2d3e4-f5a6-7890-bcde-f01234567890",
-     "exec_act": "fetch_patient_data",
-     "par": [],
-     "inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
-     "out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564"
-   }
-
-   Agent B receives the ECT, verifies it, executes a validation task,
-   and creates its own ECT:
-
-   {
-     "iss": "spiffe://example.com/agent/validator",
-     "aud": "spiffe://example.com/system/ledger",
-     "iat": 1772064160,
-     "exp": 1772064760,
-     "jti": "550e8400-e29b-41d4-a716-446655440002",
-     "wid": "b1c2d3e4-f5a6-7890-bcde-f01234567890",
-     "exec_act": "validate_safety",
-     "par": ["550e8400-e29b-41d4-a716-446655440001"]
-   }
-
-   The resulting DAG:
-
-   task-...-0001 (fetch_patient_data)
-     |
-     v
-   task-...-0002 (validate_safety)
-
-Example 2: Medical Device SDLC with Release Approval
-
-   A multi-step medical device software lifecycle workflow with
-   autonomous agents and human release approval:
-
-   Task 1 (Spec Review Agent):
-
-
-
-
-
-
-
-
-
-
-
-Nennemann                Expires 29 August 2026                [Page 40]
-
-Internet-Draft           WIMSE Execution Context           February 2026
-
-
-   {
-     "iss": "spiffe://meddev.example/agent/spec-reviewer",
-     "aud": "spiffe://meddev.example/agent/code-gen",
-     "iat": 1772064150,
-     "exp": 1772064750,
-     "jti": "a1b2c3d4-0001-0000-0000-000000000001",
-     "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
-     "exec_act": "review_requirements_spec",
-     "par": [],
-     "inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
-     "out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564"
-   }
-
-   Task 2 (Code Generation Agent):
-
-   {
-     "iss": "spiffe://meddev.example/agent/code-gen",
-     "aud": "spiffe://meddev.example/agent/test-runner",
-     "iat": 1772064200,
-     "exp": 1772064800,
-     "jti": "a1b2c3d4-0001-0000-0000-000000000002",
-     "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
-     "exec_act": "implement_module",
-     "par": ["a1b2c3d4-0001-0000-0000-000000000001"]
-   }
-
-   Task 3 (Autonomous Test Agent):
-
-   {
-     "iss": "spiffe://meddev.example/agent/test-runner",
-     "aud": "spiffe://meddev.example/agent/build",
-     "iat": 1772064260,
-     "exp": 1772064860,
-     "jti": "a1b2c3d4-0001-0000-0000-000000000003",
-     "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
-     "exec_act": "execute_test_suite",
-     "par": ["a1b2c3d4-0001-0000-0000-000000000002"]
-   }
-
-   Task 4 (Build Agent):
-
-
-
-
-
-
-
-
-
-
-
-Nennemann                Expires 29 August 2026                [Page 41]
-
-Internet-Draft           WIMSE Execution Context           February 2026
-
-
-   {
-     "iss": "spiffe://meddev.example/agent/build",
-     "aud": "spiffe://meddev.example/human/release-mgr-42",
-     "iat": 1772064310,
-     "exp": 1772064910,
-     "jti": "a1b2c3d4-0001-0000-0000-000000000004",
-     "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
-     "exec_act": "build_release_artifact",
-     "par": ["a1b2c3d4-0001-0000-0000-000000000003"],
-     "out_hash": "sha-256:Ry1YfOoW2XpC5Mq8HkGzNx3dL9vBa4sUjE7iKt0wPZc"
-   }
-
-   Task 5 (Human Release Manager Approval):
-
-   {
-     "iss": "spiffe://meddev.example/human/release-mgr-42",
-     "aud": "spiffe://meddev.example/system/ledger",
-     "iat": 1772064510,
-     "exp": 1772065110,
-     "jti": "a1b2c3d4-0001-0000-0000-000000000005",
-     "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
-     "exec_act": "approve_release",
-     "par": ["a1b2c3d4-0001-0000-0000-000000000004"],
-     "ext": {
-       "witnessed_by": [
-         "spiffe://meddev.example/audit/qa-observer-1"
-       ]
-     }
-   }
-
-   The resulting DAG records the complete SDLC: spec review preceded
-   implementation, implementation preceded testing, testing preceded
-   build, and a human release manager approved the final release.  The
-   "ext" object in task 5 carries witness metadata via the
-   "witnessed_by" extension key.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nennemann                Expires 29 August 2026                [Page 42]
-
-Internet-Draft           WIMSE Execution Context           February 2026
-
-
-   task-...-0001 (review_requirements_spec)
-     |
-     v
-   task-...-0002 (implement_module)
-     |
-     v
-   task-...-0003 (execute_test_suite)
-     |
-     v
-   task-...-0004 (build_release_artifact)
-     |
-     v
-   task-...-0005 (approve_release) [human]
-
-   An FDA auditor reconstructs this DAG by querying the audit ledger for
-   all ECTs with wid "c2d3e4f5-a6b7-8901-cdef-012345678901" and
-   verifying each signature.  The DAG provides cryptographic evidence
-   that the SDLC followed the prescribed process with human oversight at
-   the release gate.
-
-Example 3: Parallel Execution with Join
-
-   A workflow where two tasks execute in parallel and a third task
-   depends on both:
-
-   task-...-0001 (assess_risk)
-     |            \
-     v             v
-   task-...-0002  task-...-0003
-   (check         (verify
-   compliance)    liquidity)
-     |            /
-     v           v
-   task-...-0004 (execute_trade)
-
-   Task 004 ECT payload:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nennemann                Expires 29 August 2026                [Page 43]
-
-Internet-Draft           WIMSE Execution Context           February 2026
-
-
-   {
-     "iss": "spiffe://bank.example/agent/execution",
-     "aud": "spiffe://bank.example/system/ledger",
-     "iat": 1772064250,
-     "exp": 1772064850,
-     "jti": "f1e2d3c4-0004-0000-0000-000000000004",
-     "wid": "d3e4f5a6-b7c8-9012-def0-123456789012",
-     "exec_act": "execute_trade",
-     "par": [
-       "f1e2d3c4-0002-0000-0000-000000000002",
-       "f1e2d3c4-0003-0000-0000-000000000003"
-     ]
-   }
-
-   The "par" array with two entries records that both compliance
-   checking and liquidity verification were completed before trade
-   execution.
-
 Acknowledgments
 
    The author thanks the WIMSE working group for their foundational work
@@ -2461,4 +1547,22 @@ Author's Address
 
 
 
-Nennemann                Expires 29 August 2026                [Page 44]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nennemann                Expires 29 August 2026                [Page 28]
diff --git a/draft-nennemann-wimse-ect-00.xml b/draft-nennemann-wimse-ect-00.xml
index 34c600a..3bfa42b 100644
--- a/draft-nennemann-wimse-ect-00.xml
+++ b/draft-nennemann-wimse-ect-00.xml
@@ -27,32 +27,26 @@
 
     <area>Security</area>
     <workgroup>WIMSE</workgroup>
-    <keyword>execution context</keyword> <keyword>workload identity</keyword> <keyword>agentic workflows</keyword> <keyword>audit trail</keyword> <keyword>compliance</keyword> <keyword>regulated systems</keyword>
+    <keyword>execution context</keyword> <keyword>workload identity</keyword> <keyword>agentic workflows</keyword> <keyword>audit trail</keyword>
 
     <abstract>
 
 
-<?line 91?>
+<?line 53?>
 
 <t>This document defines Execution Context Tokens (ECTs), an extension
 to the Workload Identity in Multi System Environments (WIMSE)
-architecture for distributed agentic workflows in regulated
-environments.  ECTs provide signed, structured records of task
-execution order and compliance state across agent-to-agent
-communication.  By extending WIMSE Workload Identity
+architecture for distributed agentic workflows.  ECTs provide
+signed, structured records of task execution order across
+agent-to-agent communication.  By extending WIMSE Workload Identity
 Tokens with execution context claims in JSON Web Token (JWT)
-format, this specification enables regulated systems to maintain
-structured audit trails that support compliance verification.
-ECTs use a directed acyclic graph (DAG) structure to represent task
-dependencies and integrate with WIMSE Workload Identity Tokens (WIT)
-using the same signing model and cryptographic primitives.
-Policy evaluation and compensation extensions are defined in
-<xref target="I-D.nennemann-wimse-ect-pol"/>.  A new
-HTTP header field,
+format, this specification enables systems to maintain structured
+audit trails of agent execution.  ECTs use a directed acyclic
+graph (DAG) structure to represent task dependencies and integrate
+with WIMSE Workload Identity Tokens (WIT) using the same signing
+model and cryptographic primitives.  A new HTTP header field,
 Execution-Context, is defined for transporting ECTs alongside
-existing WIMSE headers.  ECTs are a technical building block that
-supports, but does not by itself constitute, compliance with
-regulatory frameworks.</t>
+existing WIMSE headers.</t>
 
 
 
@@ -65,7 +59,7 @@ regulatory frameworks.</t>
   <middle>
 
 
-<?line 113?>
+<?line 69?>
 
 <section anchor="introduction"><name>Introduction</name>
 
@@ -86,9 +80,7 @@ what was done or in what order.</t>
 <t>Regulated environments increasingly deploy autonomous agents that
 coordinate across organizational boundaries.  Domains such as
 healthcare, finance, and logistics require structured, auditable
-records of automated decision-making and execution.
-<xref target="_table-regulatory"/> in the appendix illustrates how ECTs relate
-to specific regulatory frameworks.</t>
+records of automated decision-making and execution.</t>
 
 <t>This document defines an extension to the WIMSE architecture that
 addresses the gap between workload identity and execution
@@ -134,8 +126,6 @@ regulatory audit scenarios.</t>
 (<xref target="wimse-integration"/>)</t>
   <t>An HTTP header for ECT transport (<xref target="http-header"/>)</t>
   <t>Audit ledger interface requirements (<xref target="ledger-interface"/>)</t>
-  <t>Policy evaluation and compensation extensions are defined
-separately in <xref target="I-D.nennemann-wimse-ect-pol"/></t>
 </list></t>
 
 <t>The following are out of scope and are handled by WIMSE:</t>
@@ -147,27 +137,6 @@ separately in <xref target="I-D.nennemann-wimse-ect-pol"/></t>
   <t>Credential lifecycle management</t>
 </list></t>
 
-</section>
-<section anchor="relationship-to-regulatory-compliance"><name>Relationship to Regulatory Compliance</name>
-
-<t>ECTs are a technical mechanism that can support compliance programs
-by providing structured, cryptographically signed execution
-records.  ECTs do not by themselves constitute compliance with any
-regulatory framework referenced in this document.</t>
-
-<t>Compliance with each referenced regulation requires organizational
-controls, policies, procedures, validation, and governance measures
-beyond the scope of this specification.  The regulatory references
-in this document are intended to motivate the design requirements,
-not to claim that implementing ECTs satisfies these regulations.</t>
-
-<t>ECTs provide evidence of claimed execution ordering.  They do not
-independently verify that the claimed execution actually occurred
-as described or that the agent faithfully performed the stated
-action.  The trustworthiness of ECT claims depends on the
-trustworthiness of the signing agent and the integrity of the
-broader deployment environment.</t>
-
 </section>
 </section>
 <section anchor="conventions-and-definitions"><name>Conventions and Definitions</name>
@@ -206,8 +175,7 @@ records task execution details.</t>
   <dt>Audit Ledger:</dt>
   <dd>
     <t>An append-only, immutable log of all ECTs within a workflow or
-set of workflows, used for regulatory audit and compliance
-verification.</t>
+set of workflows, used for audit and verification.</t>
   </dd>
   <dt>Workload Identity Token (WIT):</dt>
   <dd>
@@ -225,11 +193,6 @@ authentication.</t>
 shared identity issuer, corresponding to a SPIFFE <xref target="SPIFFE"/>
 trust domain.</t>
   </dd>
-  <dt>Witness:</dt>
-  <dd>
-    <t>A third-party entity that observes and attests to the execution
-of a task, providing additional accountability.</t>
-  </dd>
 </dl>
 
 </section>
@@ -339,8 +302,10 @@ ledger.</t>
 <section anchor="ect-format"><name>Execution Context Token Format</name>
 
 <t>An Execution Context Token is a JSON Web Token (JWT) <xref target="RFC7519"/>
-signed as a JSON Web Signature (JWS) <xref target="RFC7515"/> using the Compact
-Serialization.  JWS JSON Serialization <bcp14>MUST NOT</bcp14> be used for ECTs.</t>
+signed as a JSON Web Signature (JWS) <xref target="RFC7515"/>.  ECTs <bcp14>MUST</bcp14> use
+JWS Compact Serialization (the base64url-encoded
+<spanx style="verb">header.payload.signature</spanx> format) so that they can be carried in
+a single HTTP header value.</t>
 
 <section anchor="jose-header"><name>JOSE Header</name>
 
@@ -492,7 +457,10 @@ collision with the "act" (Actor) claim registered by
 representing DAG dependencies.  Each element <bcp14>MUST</bcp14> be the "jti"
 value of a previously verified ECT.  An empty array indicates
 a root task with no dependencies.  A workflow <bcp14>MAY</bcp14> contain
-multiple root tasks.</t>
+multiple root tasks.  Parent ECTs may have passed their own
+"exp" time; ECT expiration applies to the verification window
+of the ECT itself, not to its validity as a parent reference
+in the ECT store.</t>
   </dd>
 </dl>
 
@@ -523,15 +491,6 @@ using the same format and algorithm requirements as "inp_hash".</t>
   </dd>
 </dl>
 
-</section>
-<section anchor="compensation-claims"><name>Compensation and Rollback</name>
-
-<t>Compensation and rollback extensions are defined in
-<xref target="I-D.nennemann-wimse-ect-pol"/>.  The referenced
-parent ECTs may have passed their own "exp" time; ECT expiration
-applies to the verification window of the ECT itself, not to its
-validity as a parent reference in the ECT store.</t>
-
 </section>
 <section anchor="extension-claims"><name>Extensions</name>
 
@@ -554,25 +513,8 @@ nesting depth within the "ext" object <bcp14>SHOULD NOT</bcp14> exceed 5
 levels.  Implementations <bcp14>SHOULD</bcp14> reject ECTs whose "ext" claim
 exceeds these limits.</t>
 
-<t>The following extension keys are defined by this specification
-for common use cases.  Because these keys are documented here,
-they use short names without reverse domain prefixes:</t>
-
-<t><list style="symbols">
-  <t>"exec_time_ms": Integer.  Execution duration in milliseconds.</t>
-  <t>"regulated_domain": String.  Regulatory domain (e.g.,
-"medtech", "finance", "military").</t>
-  <t>"model_version": String.  AI/ML model version.</t>
-  <t>"witnessed_by": Array of StringOrURI.  Identifiers of
-third-party entities that the issuer claims observed the
-task.  Note: this is self-asserted; for verifiable witness
-attestation, witnesses should submit independent signed ECTs.</t>
-  <t>"inp_classification": String.  Data sensitivity classification
-(e.g., "public", "confidential", "restricted").</t>
-</list></t>
-
-<t>Additional extension keys for policy evaluation and compensation
-are defined in <xref target="I-D.nennemann-wimse-ect-pol"/>.</t>
+<t>Extension keys for domain-specific use cases <bcp14>MAY</bcp14> be defined in
+future documents.</t>
 
 </section>
 </section>
@@ -593,13 +535,7 @@ are defined in <xref target="I-D.nennemann-wimse-ect-pol"/>.</t>
   "par": [],
 
   "inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
-  "out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564",
-
-  "ext": {
-    "exec_time_ms": 245,
-    "regulated_domain": "medtech",
-    "model_version": "clinical-reasoning-v4.2"
-  }
+  "out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564"
 }
 ]]></sourcecode></figure>
 
@@ -689,63 +625,10 @@ same trust domain or to a trust domain with which a federation
 relationship has been established.</t>
 </list></t>
 
-</section>
-<section anchor="dag-validation-algorithm"><name>DAG Validation Algorithm</name>
-
-<t>The following pseudocode describes the DAG validation procedure:</t>
-
-<figure title="DAG Validation Pseudocode" anchor="fig-dag-validation"><sourcecode type="pseudocode"><![CDATA[
-function validate_dag(ect, ect_store, clock_skew_tolerance):
-  // Step 1: Uniqueness check
-  if ect_store.contains(ect.jti, ect.wid):
-    return error("ECT ID already exists")
-
-  // Step 2: Parent existence and temporal ordering
-  for parent_id in ect.par:
-    parent = ect_store.get(parent_id)
-    if parent is null:
-      return error("Parent task not found: " + parent_id)
-    if parent.iat >= ect.iat + clock_skew_tolerance:
-      return error("Parent task not earlier than current")
-
-  // Step 3: Cycle detection (with traversal limit)
-  visited = set()
-  result = has_cycle(ect.jti, ect.par, ect_store, visited,
-                      max_ancestor_limit)
-  if result is error or result is true:
-    return error("Circular dependency or depth limit exceeded")
-
-  return success
-
-function has_cycle(target_jti, parent_ids, ect_store,
-                   visited, max_depth):
-  if visited.size() >= max_depth:
-    return error("Maximum ancestor traversal limit exceeded")
-  for parent_id in parent_ids:
-    if parent_id == target_jti:
-      return true
-    if parent_id in visited:
-      continue
-    visited.add(parent_id)
-    parent = ect_store.get(parent_id)
-    if parent is not null:
-      result = has_cycle(target_jti, parent.par, ect_store,
-                          visited, max_depth)
-      if result is error or result is true:
-        return result
-  return false
-]]></sourcecode></figure>
-
-<t>The cycle detection traverses the ancestor graph rooted at the
-current task's parents.  The complexity is O(V) where V is the
-number of ancestor nodes reachable from the current task's parent
-references.  For typical workflows with shallow DAGs, this is
-efficient.  To prevent denial-of-service via extremely deep or
-wide DAGs, implementations <bcp14>SHOULD</bcp14> enforce a maximum ancestor
-traversal limit (<bcp14>RECOMMENDED</bcp14>: 10000 nodes).  If the limit is
-reached before cycle detection completes, the ECT <bcp14>SHOULD</bcp14> be
-rejected.  Implementations <bcp14>SHOULD</bcp14> cache cycle detection results
-for previously verified tasks to avoid redundant traversals.</t>
+<t>To prevent denial-of-service via extremely deep or wide DAGs,
+implementations <bcp14>SHOULD</bcp14> enforce a maximum ancestor traversal limit
+(<bcp14>RECOMMENDED</bcp14>: 10000 nodes).  If the limit is reached before cycle
+detection completes, the ECT <bcp14>SHOULD</bcp14> be rejected.</t>
 
 </section>
 </section>
@@ -808,76 +691,6 @@ revealing which specific verification step failed.  The receiving
 agent <bcp14>MUST NOT</bcp14> process the requested action when ECT verification
 fails.</t>
 
-</section>
-<section anchor="verification-pseudocode"><name>Verification Pseudocode</name>
-
-<figure title="ECT Verification Pseudocode" anchor="fig-verification"><sourcecode type="pseudocode"><![CDATA[
-function verify_ect(ect_jws, verifier_id,
-                     trust_domain_keys, ect_store):
-  // Parse JWS
-  (header, payload, signature) = parse_jws(ect_jws)
-
-  // Verify header
-  if header.typ != "wimse-exec+jwt":
-    return reject("Invalid typ parameter")
-
-  if header.alg == "none" or is_symmetric(header.alg):
-    return reject("Prohibited algorithm")
-
-  // Look up public key
-  public_key = trust_domain_keys.get(header.kid)
-  if public_key is null:
-    return reject("Unknown key identifier")
-
-  // Verify signature
-  if not verify_jws_signature(header, payload,
-                               signature, public_key):
-    return reject("Invalid signature")
-
-  // Verify key not revoked
-  if is_key_revoked(header.kid, trust_domain_keys):
-    return reject("Signing key has been revoked")
-
-  // Verify algorithm alignment
-  wit = get_wit_for_key(header.kid)
-  if header.alg != wit.alg:
-    return reject("Algorithm mismatch with WIT")
-
-  // Verify issuer matches WIT subject
-  if payload.iss != wit.sub:
-    return reject("Issuer does not match WIT subject")
-
-  // Verify audience
-  if verifier_id not in payload.aud:
-    return reject("ECT not intended for this recipient")
-
-  // Verify not expired
-  if payload.exp < current_time():
-    return reject("ECT has expired")
-
-  // Verify iat freshness (not too old, not in the future)
-  if payload.iat < current_time() - max_age_threshold:
-    return reject("ECT issued too long ago")
-  if payload.iat > current_time() + clock_skew_tolerance:
-    return reject("ECT issued in the future")
-
-  // Verify required claims
-  for claim in ["jti", "exec_act", "par"]:
-    if claim not in payload:
-      return reject("Missing required claim: " + claim)
-
-  // Validate DAG (against ECT store or inline parent ECTs)
-  result = validate_dag(payload, ect_store,
-                         clock_skew_tolerance)
-  if result is error:
-    return reject("DAG validation failed")
-
-  // All checks passed; record if store is available
-  if ect_store is not null:
-    ect_store.append(payload)
-  return accept
-]]></sourcecode></figure>
-
 </section>
 </section>
 <section anchor="ledger-interface"><name>Audit Ledger Interface</name>
@@ -945,21 +758,8 @@ compromised or malicious agent could create ECTs with false claims
 </list></t>
 
 <t>The trustworthiness of ECT claims depends on the trustworthiness
-of the signing agent.  To mitigate single-agent false claims,
-regulated environments <bcp14>SHOULD</bcp14> use the "witnessed_by"
-extension key (carried in "ext") to include independent
-third-party observers at critical decision points.  However,
-this value is self-asserted by the ECT issuer: the listed
-witnesses do not co-sign the ECT and there is no cryptographic
-evidence within a single ECT that the witnesses actually
-observed the task.  An issuing agent could list witnesses that
-did not participate.</t>
-
-<t>To strengthen witness attestation beyond self-assertion, witnesses
-<bcp14>SHOULD</bcp14> submit their own independent signed ECTs referencing the
-observed task's "jti" in the "par" array.  Auditors can then
-cross-check the "witnessed_by" extension against independent
-witness ECTs in the ECT store.</t>
+of the signing agent and the integrity of the broader deployment
+environment.</t>
 
 </section>
 <section anchor="organizational-prerequisites"><name>Organizational Prerequisites</name>
@@ -1065,8 +865,6 @@ create a false execution history if they control the ledger.</t>
 <t><list style="symbols">
   <t>Independent ledger maintenance: The ledger <bcp14>SHOULD</bcp14> be maintained
 by an entity independent of the workflow agents.</t>
-  <t>Witness attestation: Using the "witnessed_by" extension
-key in "ext" to include independent third-party observers.</t>
   <t>Cross-verification: Multiple independent ledger replicas can be
 compared for consistency.</t>
   <t>Out-of-band audit: External auditors periodically verify ledger
@@ -1156,22 +954,16 @@ structured identifiers.</t>
 <section anchor="storage-and-access-control"><name>Storage and Access Control</name>
 
 <t>ECTs stored in audit ledgers <bcp14>SHOULD</bcp14> be access-controlled so that
-only authorized auditors and regulators can read them.
-Implementations <bcp14>SHOULD</bcp14> consider encryption at rest for ledger
-storage containing sensitive regulatory data.</t>
+only authorized auditors can read them.  Implementations <bcp14>SHOULD</bcp14>
+consider encryption at rest for ledger storage.  ECTs provide
+structural records of execution ordering; they are not intended
+for public disclosure.</t>
 
 <t>Full input and output data (corresponding to the hashes in ECTs)
 <bcp14>SHOULD</bcp14> be stored separately from the ledger with additional access
 controls, since auditors may need to verify hash correctness but
 general access to the data values is not needed.</t>
 
-</section>
-<section anchor="regulatory-access"><name>Regulatory Access</name>
-
-<t>ECTs are designed for interpretation by qualified human auditors
-and regulators.  ECTs provide structural records of execution
-ordering; they are not intended for public disclosure.</t>
-
 </section>
 </section>
 <section anchor="iana-considerations"><name>IANA Considerations</name>
@@ -1218,8 +1010,8 @@ separated by period characters.</t>
   </dd>
   <dt>Applications that use this media type:</dt>
   <dd>
-    <t>Applications that implement regulated agentic workflows requiring
-execution context tracing and audit trails.</t>
+    <t>Applications that implement agentic workflows requiring execution
+context tracing and audit trails.</t>
   </dd>
   <dt>Additional information:</dt>
   <dd>
@@ -1308,10 +1100,6 @@ the "JSON Web Token Claims" registry maintained by IANA:</t>
       <c><xref target="extension-claims"/></c>
 </texttable>
 
-<t>Policy evaluation claims and the ECT Policy Decision Values
-registry are defined in
-<xref target="I-D.nennemann-wimse-ect-pol"/>.</t>
-
 </section>
 </section>
 
@@ -1589,15 +1377,6 @@ been incorporated into this document. This document obsoletes RFC
    
 </reference>
 
-<reference anchor="I-D.nennemann-wimse-ect-pol" target="https://datatracker.ietf.org/doc/draft-nennemann-wimse-ect-pol/">
-  <front>
-    <title>Policy Evaluation and Compensation Extensions for Execution Context Tokens</title>
-    <author fullname="Christian Nennemann">
-      <organization></organization>
-    </author>
-    <date />
-  </front>
-</reference>
 <reference anchor="SPIFFE" target="https://spiffe.io/docs/latest/spiffe-about/overview/">
   <front>
     <title>Secure Production Identity Framework for Everyone (SPIFFE)</title>
@@ -1607,51 +1386,6 @@ been incorporated into this document. This document obsoletes RFC
     <date />
   </front>
 </reference>
-<reference anchor="EU-AI-ACT" target="https://eur-lex.europa.eu/eli/reg/2024/1689">
-  <front>
-    <title>Regulation (EU) 2024/1689 of the European Parliament and of the Council laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)</title>
-    <author >
-      <organization>European Parliament and Council of the European Union</organization>
-    </author>
-    <date year="2024" month="June" day="13"/>
-  </front>
-</reference>
-<reference anchor="FDA-21CFR11" target="https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11">
-  <front>
-    <title>Title 21, Code of Federal Regulations, Part 11: Electronic Records; Electronic Signatures</title>
-    <author >
-      <organization>U.S. Food and Drug Administration</organization>
-    </author>
-    <date />
-  </front>
-</reference>
-<reference anchor="MIFID-II" target="https://eur-lex.europa.eu/eli/dir/2014/65">
-  <front>
-    <title>Directive 2014/65/EU of the European Parliament and of the Council on markets in financial instruments (MiFID II)</title>
-    <author >
-      <organization>European Parliament and Council of the European Union</organization>
-    </author>
-    <date year="2014" month="May" day="15"/>
-  </front>
-</reference>
-<reference anchor="DORA" target="https://eur-lex.europa.eu/eli/reg/2022/2554">
-  <front>
-    <title>Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA)</title>
-    <author >
-      <organization>European Parliament and Council of the European Union</organization>
-    </author>
-    <date year="2022" month="December" day="14"/>
-  </front>
-</reference>
-<reference anchor="EU-MDR" target="https://eur-lex.europa.eu/eli/reg/2017/745">
-  <front>
-    <title>Regulation (EU) 2017/745 on medical devices (MDR)</title>
-    <author >
-      <organization>European Parliament and Council of the European Union</organization>
-    </author>
-    <date year="2017" month="April" day="05"/>
-  </front>
-</reference>
 <reference anchor="OPENTELEMETRY" target="https://opentelemetry.io/docs/specs/otel/">
   <front>
     <title>OpenTelemetry Specification</title>
@@ -1763,107 +1497,17 @@ been incorporated into this document. This document obsoletes RFC
 </references>
 
 
-<?line 1230?>
+<?line 986?>
 
 <section numbered="false" anchor="use-cases"><name>Use Cases</name>
 
-<t>This section describes representative use cases demonstrating how
-ECTs provide execution records in regulated environments.  These
-examples demonstrate ECT mechanics; production deployments would
-include additional domain-specific requirements beyond the scope
-of this specification.</t>
+<t>This section describes a representative use case demonstrating how
+ECTs provide structured execution records.</t>
 
 <t>Note: task identifiers in this section are abbreviated for
 readability.  In production, all "jti" values are required to be
 UUIDs per <xref target="exec-claims"/>.</t>
 
-<section numbered="false" anchor="medical-device-sdlc-workflow"><name>Medical Device SDLC Workflow</name>
-
-<t>In a medical device software development lifecycle (SDLC),
-AI agents assist across multiple phases from requirements
-analysis through release approval.  Regulatory frameworks
-including <xref target="FDA-21CFR11"/> Section 11.10(e) and <xref target="EU-MDR"/> require
-audit trails documenting the complete development process for
-software used in medical devices.</t>
-
-<figure title="Medical Device SDLC Workflow" anchor="fig-medtech-sdlc"><artwork><![CDATA[
-Agent A (Spec Reviewer):
-  jti: task-001    par: []
-  exec_act: review_requirements_spec
-
-Agent B (Code Generator):
-  jti: task-002    par: [task-001]
-  exec_act: implement_module
-
-Agent C (Test Agent):
-  jti: task-003    par: [task-002]
-  exec_act: execute_test_suite
-
-Agent D (Build Agent):
-  jti: task-004    par: [task-003]
-  exec_act: build_release_artifact
-
-Human Release Manager:
-  jti: task-005    par: [task-004]
-  exec_act: approve_release
-  ext: {witnessed_by: [...]}  (extension metadata)
-]]></artwork></figure>
-
-<t>ECTs record that requirements were reviewed before implementation
-began, that tests were executed against the implemented code, that
-the build artifact was validated, and that a human release manager
-explicitly approved the release.  The DAG structure ensures no
-phase was skipped or reordered.</t>
-
-<section numbered="false" anchor="fda-audit-with-dag-reconstruction"><name>FDA Audit with DAG Reconstruction</name>
-
-<t>During a regulatory audit, an FDA reviewer requests evidence of
-the development process for a specific software release.  The
-auditing authority retrieves all ECTs sharing the same workflow
-identifier ("wid") from the audit ledger and reconstructs the
-complete DAG:</t>
-
-<figure title="Reconstructed DAG for FDA Audit" anchor="fig-fda-audit"><artwork><![CDATA[
-task-001 (review_requirements_spec)
-  |
-  v
-task-002 (implement_module)
-  |
-  v
-task-003 (execute_test_suite)
-  |
-  v
-task-004 (build_release_artifact)
-  |
-  v
-task-005 (approve_release) [human, witnessed]
-]]></artwork></figure>
-
-<t>The reconstructed DAG provides cryptographic evidence that:</t>
-
-<t><list style="symbols">
-  <t>Each phase was executed by an identified and authenticated agent.</t>
-  <t>The execution sequence was maintained (no step was bypassed).</t>
-  <t>A human-in-the-loop approved the final release, with independent
-witness attestation.</t>
-  <t>Timestamps and execution durations are recorded for each step.</t>
-</list></t>
-
-<t>This can contribute to compliance with:</t>
-
-<t><list style="symbols">
-  <t><xref target="FDA-21CFR11"/> Section 11.10(e): Computer-generated audit trails
-that record the date, time, and identity of the operator.</t>
-  <t><xref target="EU-MDR"/> Annex II: Technical documentation traceability for the
-software development lifecycle.</t>
-  <t><xref target="EU-AI-ACT"/> Article 12: Automatic logging capabilities for
-high-risk AI systems involved in the development process.</t>
-  <t><xref target="EU-AI-ACT"/> Article 14: ECTs can record evidence that human
-oversight events occurred during the release process.</t>
-</list></t>
-
-</section>
-</section>
 <section numbered="false" anchor="cross-organization-financial-trading"><name>Cross-Organization Financial Trading</name>
 
 <t>In a cross-organization trading workflow, an investment bank's
@@ -1917,57 +1561,6 @@ demonstrating cross-organizational fan-in.  The compliance agent
 verifies both parent ECTs — one signed by a local key and one by
 a federated key from the rating agency's trust domain.</t>
 
-<t>This can contribute to compliance with:</t>
-
-<t><list style="symbols">
-  <t><xref target="MIFID-II"/>: ECTs provide cryptographic records of the execution
-sequence that can support transaction audit requirements.</t>
-  <t><xref target="DORA"/> Article 12: ECTs contribute to ICT activity logging.</t>
-  <t><xref target="EU-AI-ACT"/> Article 12: Logging of decisions made by AI-driven
-systems.</t>
-</list></t>
-
-</section>
-<section numbered="false" anchor="compensation-and-rollback"><name>Compensation and Rollback</name>
-
-<t>Compensation and rollback use cases are described in
-<xref target="I-D.nennemann-wimse-ect-pol"/>.  The core
-ECT mechanism supports compensation through the "par" claim,
-which links a remediation ECT to the original task.</t>
-
-</section>
-<section numbered="false" anchor="autonomous-logistics-coordination"><name>Autonomous Logistics Coordination</name>
-
-<t>In a logistics workflow, multiple compliance checks complete
-before shipment commitment.  The DAG structure records that all
-required checks were completed:</t>
-
-<figure title="Logistics Workflow with Parallel Tasks" anchor="fig-logistics"><artwork><![CDATA[
-Agent A (Route Planning):
-  jti: task-001    par: []
-  exec_act: plan_route
-
-Agent B (Customs):
-  jti: task-002    par: [task-001]
-  exec_act: validate_customs
-
-Agent C (Safety):
-  jti: task-003    par: [task-001]
-  exec_act: verify_cargo_safety
-
-Agent D (Payment):
-  jti: task-004    par: [task-002, task-003]
-  exec_act: authorize_payment
-
-System (Commitment):
-  jti: task-005    par: [task-004]
-  exec_act: commit_shipment
-]]></artwork></figure>
-
-<t>Note that tasks 002 and 003 both depend only on task-001 and can
-execute in parallel.  Task 004 depends on both, demonstrating the
-DAG's ability to represent parallel execution with a join point.</t>
-
 </section>
 </section>
 <section numbered="false" anchor="related-work"><name>Related Work</name>
@@ -1992,7 +1585,8 @@ delegation chain: "who is acting on behalf of whom."  While
 the nesting superficially resembles a chain, it is strictly
 linear (each "act" object contains at most one nested "act"),
 represents authorization delegation rather than task execution,
-and carries no task identifiers or input/output integrity data.  The "act" chain cannot represent
+and carries no task identifiers or input/output integrity
+data.  The "act" chain cannot represent
 branching (fan-out) or convergence (fan-in) and therefore
 cannot form a DAG.</t>
 
@@ -2056,350 +1650,14 @@ provide observability while ECTs provide signed execution records.
 ECTs may reference OpenTelemetry trace identifiers in the "ext"
 claim for correlation.</t>
 
-</section>
-<section numbered="false" anchor="blockchain-and-distributed-ledgers"><name>Blockchain and Distributed Ledgers</name>
-
-<t>Both ECTs and blockchain systems provide immutable records.  This
-specification intentionally defines only the ECT token format and
-is agnostic to the storage mechanism.  ECTs can be stored in
-append-only logs, databases with cryptographic commitments,
-blockchain networks, or any storage providing the required
-properties defined in <xref target="ledger-interface"/>.</t>
-
 </section>
 <section numbered="false" anchor="scitt-supply-chain-integrity-transparency-and-trust"><name>SCITT (Supply Chain Integrity, Transparency, and Trust)</name>
 
 <t>The SCITT architecture <xref target="I-D.ietf-scitt-architecture"/> defines a
-framework for creating transparent and auditable supply chain
-records through Transparency Services, Signed Statements, and
-Receipts.  ECTs and SCITT are naturally complementary: the ECT
-"wid" (Workflow Identifier) claim can serve as a correlation
-identifier referenced in SCITT Signed Statements, linking a
-complete ECT audit trail to a supply chain transparency record.
-For example, in a regulated manufacturing workflow, each agent
-step produces an ECT (recording what was done, by whom, under
-under what constraints), while the overall workflow identified by "wid" is
-registered as a SCITT Signed Statement on a Transparency Service.
-This enables auditors to verify both the individual execution
-steps (via ECT DAG validation) and the end-to-end supply chain
-integrity (via SCITT Receipts) using the "wid" as the shared
-correlation point.  The "ext" claim in ECTs (<xref target="exec-claims"/>)
-can carry SCITT-specific metadata such as Transparency Service
-identifiers or Receipt references for tighter integration.</t>
-
-</section>
-<section numbered="false" anchor="w3c-verifiable-credentials"><name>W3C Verifiable Credentials</name>
-
-<t>W3C Verifiable Credentials represent claims about subjects (e.g.,
-identity, qualifications).  ECTs represent execution records of
-actions (what happened, in what order).  While
-both use JWT/JWS as a serialization format, their semantics and
-use cases are distinct.</t>
-
-</section>
-</section>
-<section numbered="false" anchor="implementation-guidance"><name>Implementation Guidance</name>
-
-<section numbered="false" anchor="minimal-implementation"><name>Minimal Implementation</name>
-
-<t>A minimal conforming implementation needs to:</t>
-
-<t><list style="numbers" type="1">
-  <t>Create JWTs with all required claims ("iss", "aud", "iat",
-"exp", "jti", "exec_act", "par").</t>
-  <t>Sign ECTs with the agent's private key using an algorithm
-matching the WIT (ES256 recommended).</t>
-  <t>Verify ECT signatures against WIT public keys.</t>
-  <t>Perform DAG validation (parent existence, temporal ordering,
-cycle detection).</t>
-  <t>If an audit ledger is deployed, append verified ECTs to it.</t>
-</list></t>
-
-</section>
-<section numbered="false" anchor="storage-recommendations"><name>Storage Recommendations</name>
-
-<t><list style="symbols">
-  <t>Append-only log: Simplest approach; immutability by design.</t>
-  <t>Database with hash chains: Periodic cryptographic commitments
-over batches of entries.</t>
-  <t>Distributed ledger: Maximum immutability guarantees for
-cross-organizational audit.</t>
-  <t>Hybrid: Hot storage in a database, cold archive in immutable
-storage.</t>
-</list></t>
-
-</section>
-<section numbered="false" anchor="performance-considerations"><name>Performance Considerations</name>
-
-<t><list style="symbols">
-  <t>ES256 signature verification: approximately 1ms per ECT on
-modern hardware.</t>
-  <t>DAG validation: O(V) where V is the number of reachable ancestor
-nodes (typically small for shallow workflows).</t>
-  <t>JSON serialization: sub-millisecond per ECT.</t>
-  <t>Total per-request overhead: approximately 5-10ms, acceptable
-for regulated workflows where correctness is prioritized over
-latency.</t>
-</list></t>
-
-</section>
-<section numbered="false" anchor="interoperability"><name>Interoperability</name>
-
-<t>Implementations are expected to use established JWT/JWS libraries
-(JOSE) for token creation and verification.  Custom cryptographic
-implementations are strongly discouraged.  Implementations are
-expected to be tested against multiple JWT libraries to ensure
-interoperability.</t>
-
-</section>
-</section>
-<section numbered="false" anchor="regulatory-compliance-mapping"><name>Regulatory Compliance Mapping</name>
-
-<t>The following table summarizes how ECTs can contribute to
-compliance with various regulatory frameworks.  ECTs are a
-technical building block; achieving compliance requires
-additional organizational measures beyond this specification.</t>
-
-<texttable title="Regulatory Compliance Mapping" anchor="_table-regulatory">
-      <ttcol align='left'>Regulation</ttcol>
-      <ttcol align='left'>Requirement</ttcol>
-      <ttcol align='left'>ECT Contribution</ttcol>
-      <c>FDA 21 CFR Part 11</c>
-      <c>Audit trails recording date, time, operator, actions (11.10(e))</c>
-      <c>Cryptographic signatures and append-only ledger contribute to audit trail requirements</c>
-      <c>EU MDR</c>
-      <c>Technical documentation traceability (Annex II)</c>
-      <c>ECTs provide signed records of AI-assisted decision sequences</c>
-      <c>EU AI Act Art. 12</c>
-      <c>Automatic logging capabilities for high-risk AI</c>
-      <c>ECTs contribute cryptographic activity logging</c>
-      <c>EU AI Act Art. 14</c>
-      <c>Human oversight capability</c>
-      <c>ECTs can record evidence that human oversight events occurred</c>
-      <c>MiFID II</c>
-      <c>Transaction records for supervisory authorities</c>
-      <c>ECTs provide cryptographic execution sequence records</c>
-      <c>DORA Art. 12</c>
-      <c>ICT activity logging policies</c>
-      <c>ECT ledger contributes to ICT activity audit trail</c>
-</texttable>
-
-</section>
-<section numbered="false" anchor="examples"><name>Examples</name>
-
-<section numbered="false" anchor="example-1-simple-two-agent-workflow"><name>Example 1: Simple Two-Agent Workflow</name>
-
-<t>Agent A executes a data retrieval task and sends the ECT to
-Agent B:</t>
-
-<t>ECT JOSE Header:</t>
-
-<figure><sourcecode type="json"><![CDATA[
-{
-  "alg": "ES256",
-  "typ": "wimse-exec+jwt",
-  "kid": "agent-a-key-2026-02"
-}
-]]></sourcecode></figure>
-
-<t>ECT Payload:</t>
-
-<figure><sourcecode type="json"><![CDATA[
-{
-  "iss": "spiffe://example.com/agent/data-retrieval",
-  "aud": "spiffe://example.com/agent/validator",
-  "iat": 1772064150,
-  "exp": 1772064750,
-  "jti": "550e8400-e29b-41d4-a716-446655440001",
-  "wid": "b1c2d3e4-f5a6-7890-bcde-f01234567890",
-  "exec_act": "fetch_patient_data",
-  "par": [],
-  "inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
-  "out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564"
-}
-]]></sourcecode></figure>
-
-<t>Agent B receives the ECT, verifies it, executes a validation
-task, and creates its own ECT:</t>
-
-<figure><sourcecode type="json"><![CDATA[
-{
-  "iss": "spiffe://example.com/agent/validator",
-  "aud": "spiffe://example.com/system/ledger",
-  "iat": 1772064160,
-  "exp": 1772064760,
-  "jti": "550e8400-e29b-41d4-a716-446655440002",
-  "wid": "b1c2d3e4-f5a6-7890-bcde-f01234567890",
-  "exec_act": "validate_safety",
-  "par": ["550e8400-e29b-41d4-a716-446655440001"]
-}
-]]></sourcecode></figure>
-
-<t>The resulting DAG:</t>
-
-<figure><artwork><![CDATA[
-task-...-0001 (fetch_patient_data)
-  |
-  v
-task-...-0002 (validate_safety)
-]]></artwork></figure>
-
-</section>
-<section numbered="false" anchor="example-2-medical-device-sdlc-with-release-approval"><name>Example 2: Medical Device SDLC with Release Approval</name>
-
-<t>A multi-step medical device software lifecycle workflow with
-autonomous agents and human release approval:</t>
-
-<t>Task 1 (Spec Review Agent):</t>
-
-<figure><sourcecode type="json"><![CDATA[
-{
-  "iss": "spiffe://meddev.example/agent/spec-reviewer",
-  "aud": "spiffe://meddev.example/agent/code-gen",
-  "iat": 1772064150,
-  "exp": 1772064750,
-  "jti": "a1b2c3d4-0001-0000-0000-000000000001",
-  "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
-  "exec_act": "review_requirements_spec",
-  "par": [],
-  "inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
-  "out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564"
-}
-]]></sourcecode></figure>
-
-<t>Task 2 (Code Generation Agent):</t>
-
-<figure><sourcecode type="json"><![CDATA[
-{
-  "iss": "spiffe://meddev.example/agent/code-gen",
-  "aud": "spiffe://meddev.example/agent/test-runner",
-  "iat": 1772064200,
-  "exp": 1772064800,
-  "jti": "a1b2c3d4-0001-0000-0000-000000000002",
-  "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
-  "exec_act": "implement_module",
-  "par": ["a1b2c3d4-0001-0000-0000-000000000001"]
-}
-]]></sourcecode></figure>
-
-<t>Task 3 (Autonomous Test Agent):</t>
-
-<figure><sourcecode type="json"><![CDATA[
-{
-  "iss": "spiffe://meddev.example/agent/test-runner",
-  "aud": "spiffe://meddev.example/agent/build",
-  "iat": 1772064260,
-  "exp": 1772064860,
-  "jti": "a1b2c3d4-0001-0000-0000-000000000003",
-  "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
-  "exec_act": "execute_test_suite",
-  "par": ["a1b2c3d4-0001-0000-0000-000000000002"]
-}
-]]></sourcecode></figure>
-
-<t>Task 4 (Build Agent):</t>
-
-<figure><sourcecode type="json"><![CDATA[
-{
-  "iss": "spiffe://meddev.example/agent/build",
-  "aud": "spiffe://meddev.example/human/release-mgr-42",
-  "iat": 1772064310,
-  "exp": 1772064910,
-  "jti": "a1b2c3d4-0001-0000-0000-000000000004",
-  "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
-  "exec_act": "build_release_artifact",
-  "par": ["a1b2c3d4-0001-0000-0000-000000000003"],
-  "out_hash": "sha-256:Ry1YfOoW2XpC5Mq8HkGzNx3dL9vBa4sUjE7iKt0wPZc"
-}
-]]></sourcecode></figure>
-
-<t>Task 5 (Human Release Manager Approval):</t>
-
-<figure><sourcecode type="json"><![CDATA[
-{
-  "iss": "spiffe://meddev.example/human/release-mgr-42",
-  "aud": "spiffe://meddev.example/system/ledger",
-  "iat": 1772064510,
-  "exp": 1772065110,
-  "jti": "a1b2c3d4-0001-0000-0000-000000000005",
-  "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
-  "exec_act": "approve_release",
-  "par": ["a1b2c3d4-0001-0000-0000-000000000004"],
-  "ext": {
-    "witnessed_by": [
-      "spiffe://meddev.example/audit/qa-observer-1"
-    ]
-  }
-}
-]]></sourcecode></figure>
-
-<t>The resulting DAG records the complete SDLC: spec review preceded
-implementation, implementation preceded testing, testing preceded
-build, and a human release manager approved the final release.
-The "ext" object in task 5 carries witness metadata via
-the "witnessed_by" extension key.</t>
-
-<figure><artwork><![CDATA[
-task-...-0001 (review_requirements_spec)
-  |
-  v
-task-...-0002 (implement_module)
-  |
-  v
-task-...-0003 (execute_test_suite)
-  |
-  v
-task-...-0004 (build_release_artifact)
-  |
-  v
-task-...-0005 (approve_release) [human]
-]]></artwork></figure>
-
-<t>An FDA auditor reconstructs this DAG by querying the audit ledger
-for all ECTs with wid "c2d3e4f5-a6b7-8901-cdef-012345678901" and
-verifying each signature.  The DAG provides cryptographic evidence
-that the SDLC followed the prescribed process with human oversight
-at the release gate.</t>
-
-</section>
-<section numbered="false" anchor="example-3-parallel-execution-with-join"><name>Example 3: Parallel Execution with Join</name>
-
-<t>A workflow where two tasks execute in parallel and a third task
-depends on both:</t>
-
-<figure><artwork><![CDATA[
-task-...-0001 (assess_risk)
-  |            \
-  v             v
-task-...-0002  task-...-0003
-(check         (verify
-compliance)    liquidity)
-  |            /
-  v           v
-task-...-0004 (execute_trade)
-]]></artwork></figure>
-
-<t>Task 004 ECT payload:</t>
-
-<figure><sourcecode type="json"><![CDATA[
-{
-  "iss": "spiffe://bank.example/agent/execution",
-  "aud": "spiffe://bank.example/system/ledger",
-  "iat": 1772064250,
-  "exp": 1772064850,
-  "jti": "f1e2d3c4-0004-0000-0000-000000000004",
-  "wid": "d3e4f5a6-b7c8-9012-def0-123456789012",
-  "exec_act": "execute_trade",
-  "par": [
-    "f1e2d3c4-0002-0000-0000-000000000002",
-    "f1e2d3c4-0003-0000-0000-000000000003"
-  ]
-}
-]]></sourcecode></figure>
-
-<t>The "par" array with two entries records that both compliance
-checking and liquidity verification were completed before trade
-execution.</t>
+framework for transparent and auditable supply chain records.
+ECTs and SCITT are complementary: the ECT "wid" claim can serve
+as a correlation identifier in SCITT Signed Statements, linking
+an ECT audit trail to a supply chain transparency record.</t>
 
 </section>
 </section>
@@ -2417,485 +1675,334 @@ tracing is built.</t>
   </back>
 
 <!-- ##markdown-source:
-H4sIAAAAAAAAA82963bbVrIu+h9PgU3/CNWLoERZsh2mu9eWZTlWL8tWS3LS
-2Z0MLZCEKMQkwQZAyWzHa5yHOA+wn2U/ynmSU19VzRsIynZW/9geiS2RwLzU
-rFnzq+tMkiSq83qWDePOyYdsvKrzYhEfF4s6+1DHV8X7bFHFN0UZv8irusxH
-qzqbxEfTbFHn4/jHonx/Myvuq06UjkZldkeN/Hh6dnkSbzTVicZpnU2Lcj2M
-q3oSTYrxIp1Tr5MyvamTRbZYZPN0sUju83mVJdm4Tvb2omo1mudVRe3U6yU9
-fHpy9TJarOajrBxGE2pwGFGfj6O0zFLq+5I6LfN63YnuaWTTslgtzYg60fts
-TZ9OhlEcJ3FmxzeW8fGneGtWpJM4n2CC9Zo/TXW292a28ulqktdxXab5jH8f
-F/PlLE8X44x/LbPpapaCWNW6qrN5FUXpqr4tSu6f/o/jm9VsJjQ4vi2JuvRy
-/MbQgZ8oymm6yP+ZYqA0+cUkW2YLDC2+yKosLce3WckP0iv5bBjnWX3zPy0p
-+5MsihZFOaf37zL0e/Hy+Onh4ND9+NT9+K378Zn++O3hk33z42Cwhx9Pkxd9
-9KLLhCG0fFztV8myLOpiXMyGUZQvbhqjeHx4aFp+9uTbx6aTg/2BaW2Rmy7y
-hBcgMWtin2hhmSX6A0EMS58Xs3y8jk/u0tmKyRiniwnx5JwIWckHJx9q+pl+
-Ej7ftgk60m5aTrN6GN/W9bIa7u4SD6bEA+P3WckE6NOS7RJv725naxrjLrfF
-/BvfpLMq498df+BP8ln+uDw/ffnyJJwv74AsPi+LyWrMszhVssUvS2oLPCzT
-vMvKdbHI4q40s9M+v2qZ39xk/bzApKpdcHRV66dJOipW9W5BLd3l2X3bpE7e
-JUenydHxVTjKC9kcGF735N1OvL+3f7A7ePLs27i4ievbLD5ZlcUyo/mepyVt
-qjlYHgunXx8Xq8U4n8WzdJ0vpvGkuF/Et2k5LxZ5RTuuXM2yKsZal3V+k4/z
-dBbntJazWU6cNKY5H7kvTv0vjsb1FkJkqzKZZR/6GUaW0j+72SzfpV2+awfv
-zR+fJXtPksHj1pUlJhlunaOZXJMU7xZEL2ri5YujZH9w/PJiMAipeoV/4/1B
-j5qYZHj/ZTbJSpqjo3fVQ3d1TO/GJzNix5JoNqYHxiQaq+/8zy7z6SKtiZu2
-sP79/X0/G9+U/Wlxt0tcV9IEdnksNLzd8W26rLMyOd0lGW5+OdpdUufJYPBF
-/M9Uete/7Mcvi2LCtHlRrqbx0WSeL3Aa8Yzo8bPTl6cvktPTkBwv8pLmQjKH
-VmNwsPvkcPfk3VfyF7HQPC3fZ3VF/BPf5AsS78JM1PsKb1Vx9yyn3uPT069i
-nEle7uqwArYZENscJoPDfz3bvHh7cfTZXbi/u394eIB5T/JpXtNUqRGhM/1M
-rJDPct4oECHoxtGkImLTh13083v2kHQd7qH9ZED/HfzriUFy6ezFxefIMXi6
-+/TgkLkgm+RjmuQku8vHGRb9xcXvmKQ0GC7402QPa/6vn+Pb85M3VyevT85O
-ri5+Cqf6lk6/q2yWzbO6XMeXy2wMachzb58UtQwxKS/Y06CiF6vdgr74sgON
-p3M8K1aT+A2jAT6I6bAlGf6SZjMxG9rCiWqc1zWjjLwm/iJhFKCNAj0kJAjo
-LOfTLqn5rDYPbfs+IfYVVEGPRklCaG4EeTKuo+jqNq/oRBnz9qYFJw6nBd8K
-jbsnx1fVTo9WhDClAomoLnhJfjRw0p7BJEXOVrM6jy8ZFMYni7ucpK1KEgaq
-O5E/Xd5oEw96b4BRtGnBZpR5DfaJz2lwMSGxOwJPcUUCPZv0YsgubpxOSpH7
-zENp9T5ysJg+zkrmMwds6U3qJE7HZVFVMhIiqBAyosfmq4VyEXX9fC0EmWB1
-RSnYoEekRLzP69tNSB6PZymhJkzwL5dv38Q/ZiOhetz9y49XO5GAyh6Rmlas
-8pk4zhbpCBhgA4XHtDSElRc1/R95hPDQPD1zm9ZxtVouCzopvekT0LFd9COm
-7aoietAC4ahBM+P1mABnPC3T5S3JwqPvdxy50XeZLUmKgrOY3gbQj3MaLIgN
-mEIvE5WZJlvoZpnvx1Oiw6oCicFwFUkHXmZ8MCcQMJMVLNfLuuAx0diWZT7P
-sfuqfqTwOAvh8diHx5mDx6Rl6YbAQKOPHx+A4Z8+EQ8cxYvsPnp1dXUe32Yp
-GOomz2aTXmS3U6LbqRdj12nbfLhg02IBMBUmdTorFtOKGJm4FGjYspU0bdkd
-o0xj2j+3C5bZo1U+YyYczYrxe17cSBeX0BDtKtrtRP1FUccj2qF1lc1uwILU
-RU1brudzABYlUqYiVTa+MZiaaMlyZJ5PJjNSux4BV1oQTr8/is8KIrpIOBIy
-v1s62C5joX9DG/v0yex34v5itKpqq9WyAsrSQ1a2viUFeXr7GfZijjCPRKRY
-kKyw359f7RDZeTa8FBVUgXEGqaA/xkYPjDaG62uJNGwjam+LezvkKvbGTAuf
-jm/jgj4ojRCiBZ7FBC8JkcVuH5jhJnZGNInIfsqTSESUeMyJNXxV3Ge0zXub
-pgDmv8zxSjqZ0E6unNiK0vGYDrE6HRFIqtdEl/9YFPcY0v1tEROMgryCjKBN
-JqqZbUvEcHQPuXOf4vihnmgTEEPwZyyMaXQXVpz5cp4eG5dZitnP1kTG5axY
-g27FopgXKxXUItVISlNbhNmcGPdtDNgtfA6XJI9oAi+KOVO2WhHd0yoiOs3q
-2zHtsJ4iv6zH/DErptiSY0jcf6xIGnqHTE+EKwRy5J03GOCc5zIhyQ0Bk8zT
-9yAXGrRU7RPf8LuJ23bELPmCFzpdQn7mH+J8NluxRqAMxJKgzEAsnMbmdIi3
-7d32U98/1GNzqDOjB2c0U1b5Iav4qWm6jEdZfZ8Ri7Wwkj/DTb7RLjzON4v4
-nRx2blBKUGEdep7WP5/oSRLyzlGl/ZMI5m9VfG+1s3z61NPtpRYyemcTfSyy
-bMKn6ojOR1pGWinuno+58i6bqFiODApJCUzThiUFbo7XzDbieSnz8Brw+Rec
-XFFaVasSTIcVI4lK+5i6m8eXgCV4CetYZhmNuOQlAKWILzFbVVDBMWVBYiSr
-5Dg2G0pnFilOIFg4eHAlwoNDliG2qyDwl7iD6MdLwochiVMWzvRSh02o9Fle
-KUzO/5lNOtwqNcjv22eEVWiQV4QZ4r/10AidLNgrb1c1Aej4f/U7UbRPnbwp
-ANKwgycenZkKPOGAoDw4C/S4z1m+eM/QxINjBu/FcxxOwiWWA2glHku/bd2B
-LgsRBbwt+CjNSPg47kevtPa8JSEWArRremFIIBhtuSqXRcUscGJwQDECr+kG
-on6LmZVZQXOA+PQ8iZRAOXJnprCwNMPIOxutplMjlGBfonGiBVl9Xnvzaoiy
-PF6lA1L6hYKUYsWxwpsrYfA5Gq1TgmBlkt3xbhQhi8/pWOenMDofiAhtqjEB
-3zIvdH9cjklv41ePloRgxkqgLdIOmhAf5Vt0HVZ1dmJB3XH340cgPfnt06cd
-epfQrgd2GcSBkSzGVV4DIejtSTpNCHbmovRJC6eKftE3738ncK3stGKbOIea
-EeGVuxelpaPgZBeL5/GVQ5V4FcptIg/oS0zEWTaZZiUj8fImJQTjSaUK78kD
-iX1AXv7dUJrmUWXLFGfXbO0J5m24WtDjTTGbCbpAUwWxI22eyi44PqTdSFh0
-AlTLNOQFtmCvAQb5yDA0ZpbGQMHqSfwffKzoNjIP09BIErDUJbYpATQnDBfi
-rMKBnVe31lQRPHtMmAD9ENiY5TcZNKbMfwKce5GpufI2X0KOXDhOP3Z+lqgV
-73vHC8TxmA7xFl2OpkgMM6+ikU6XVQQftWzboJ7s0tPXaB4qEKhFIi2t2QyS
-3mkSTUWCSLNuVSaI426yEna2iQAdb7fSzj5uNMOo2HuldIYsZd0myotwpJck
-JekoAdsS2uNDhd6GvbcXu40pomcKIz/jPSJvWuGhaJStC/qK9U7mOzZENVVx
-VQ+8adqRVlFzcryW2FckLyasqovOlHEvIvuC7diLWFgWYiqQBc9xxOBbqzli
-+1U3uUCzKvMIxKeIbyMRgTvmyXCb/npb+SWTWuuC0zSsY464hK0EaxkLn3kb
-zVhgUIwZlpBmBuW3GtMGowfZtKovy2F7k9I6wx209vQIJnzNVh/RJ5TUNfYi
-sRFRdgFkRTOB6FNjioyUvSPUQNTyMLerNgTpPtVlFikLASGPRSOCUhCvonPw
-CnqKCQ4hHCF3WAsWerDgQ+jl/LsIsvdEx3tWCjpn7y6vOj35N37zln++OPnr
-u9OLkxf4+fLV0evX9odIn7h89fbd6xfuJ/fm8duzs5M3L+Rl+jQOPoo6Z0c/
-dYS/O2/Pr07fvjl63dnYcMyTgm9Z4hOwZbxYRW7F6J3nx+f/538PDkh4/4+L
-l8f7g8G3hCrkl2eDpwf0yz2JW+mtWNBCyq8MFqHFpKztMdxOl7C80y4krqhu
-2bdFG4ao+Ye/gzK/DOM/jsbLwcGf9QNMOPjQ0Cz4kGm2+cnGy0LElo9aurHU
-DD5vUDoc79FPwe+G7t6Hf/x3AqFZnAye/fufo+ZhRwswF5G/qlqkIx1xDJqH
-0RAQwFOCjRLGVDWGJnMy0hG8xZjSk62oCLxiRCP2SqyWj4KBzblbHJVjMEm8
-IkZnTGsRsx5JxPw0XCjuBN4r1ZcA6TPEFhSM6SGaXhi74pHaFb93dkXpSwyN
-DnVZ+yITaxv8ugdDUU8AMopFrAWTgWbMp7KqT4y0H4CEMpKGifbjRw0rsJad
-iRyMG7Za1p5ja4puKB+TrIZNFgoso7PXDL7M+rL6n2A/9Ujuz1dsKYA1gslO
-m4mF+8ZyESUYdfHqWF22JzwFrLiBrENDOL0c2oKjLTY0MaEJgQTHjh364TMH
-QtYy5zeVw2B20CyiqUdBV35fnjFObHF+R0s2ctF/pC2RuqQmDDzqzfIfKwJr
-ySy7yxDEEkJC8DTDOrECBZMoiAjLOuS2dLHFlrRWtAOS36awtttJ5qQlwdpG
-S08NLQvxFsAsoNENxEfyA+HeWEjhESKvcWjJyIha5SSBf5lAuLTOm010QzWv
-pzXiFypjy/G1UNY9wXw9Dw+mk0muk2lYaXC2CTGOfFOQr8F8fLSpnDC6lfc8
-j1d01W5Y2mbh9TW2z1hvmQZsdGjnM5p5yGkGxXc7p3E6l1Cv+G8saf2vf+rs
-+J1v2oX9nj0WVICxLBnXUe84/0lZLsY522GEVdhUghEoUOV38CTYVofEA2B7
-eXJbLJv6zF2eCpJ5wCLdIvVDm3Tz9PEhnM8NagWDIBULB84iMH5dRE6FDbUz
-z4YsonGLxZkXWeIzRHQTVdUE5QxMhVWX8zIwV0G7tEtN5FLXV6jrePMy9sQk
-fp0vxBo7FvAmW4aaX0KC0UlVFWXVYqVzlg/mdRtdFZ/BH6VwWzyDSheaO/aZ
-iJCtJJ6l66yMjE2V4aihE39lUWoqtg5ug78hCv7Xf/0XjWuc57SD6ujfkq/+
-82/Rb8Ya+Jp765rtthNv/fMbXsJrV8M43E1diaAa7u7Wk11ezd0POx3/nXN5
-R/bPw/sAL/2uKW0d9pYv7n435aCAKN0clDgKFngn/jubpRCN8ItSgV5DXJND
-BNDLA5/pPKt7DXLLH4FWu4ql4tu0uoV9tW22/5fT7u1STqBh7CMgYkCLd0Q6
-7NghMBk6vNEIb0NzEaAkOjX8T56hq/PfoQLtq+jjMH50k08T3muVxJj8yYYB
-m90fnJLMClXnk1oifXfGynhQVGb6zuyeyo0q/suPRqFV77c1euMbbU8Fh4dE
-e2qNEiFYKfhXNMN+tNlKEIh31AlyaEjnm1z8hY8eBUf+eZFDMH985J35BMDw
-IU2WECs2gvXxV583clonLdRtdxBZG5dntaWW//LWusPjzvuc+B12Rdoj9Dtr
-itb2IofwakSSUs9gNy/qvZg768M3oNMV/Ns0VR2oU/irnkQfUe8dQnMdtcSo
-yojwCDs9QI1NKlqDsoV8py881LfT9yfIkxiZUBZHPg58UEzRQBQKcFrnY5q1
-5o7ZtCjp4XncDUhJn3uk3OFhULs07LE2bF90amnWQLXS6Y90NPMWZOE9T9+L
-m5GN1YrHZZOqm3vK5n+s/kbMhBleDjd4WcKtZ2MkGgwVqYd74yjkfi+0X153
-43SiQciPzxFNteFRH0Jq/BEwzR1FR39GaF1zmPIkyFyGKAaa8uTPgQzxTPJW
-kvAQX8lUL+t0DFQC0SGUbIWgikDhW7sj7ZGF5JLQw2fgXs8AK+VekQcENOrI
-EVbY+YqFAk1KbL+BOujcgnJURWJrE5eo2hZTnPDf2a2TQ/hsGBFz9pkbJMve
-Q96x4PC+YFMiaZbfOVNdV9dsR1tgI4Mo/taleaWxJIKOdobxD+ZRXcYWNRQM
-iHUMNDCGKcHUSQu/0XkS1y41O+EzZO+L6xJ06IbubRqbRiYrxyhvGh/3vZgO
-YnQ5Zr1aDTTGbgHXpDkvaWQitrIJtXu0FDsoKKukmoiLSFRDPiLFJcrvs8K3
-zQzyUkTYx0eeS0zE/ZYXwJmtQW3+aRWplEuDh21YNl64dC8ckl7oImDgI0A4
-4yVNLZ2pSk7EoFekqeCL2JgRIVuteQAAQo44Foa6BT8++rWgJVS/mXBh8+zh
-5gBZU5WE7uSyUlRl0a8V6b8fidAsZJGEdLl/+KTTwyf1eolP1P9FpPy3X+9r
-+QqHG30lEQtpQhsiySfJYP9xJ/oUShQZkcoSO1CdzMmHFOoaxAl1D0OCsZ2q
-Md2EQVeW6g1Rj+ASeCV0J/cRjo7Zt50N24+FOD61aqOoW9yI8VsxTexKP+PY
-OoyOaQZjVDpbZcEidhakOnboscv1HEG70MvMOEhBz/rTfi9+hWZBzleXj58d
-4PfDwf7OBjOwyVQDaiS4J61Mq7Dp2DwB5hrqOCmzJW0fY0WiZWxQ1h7jGR92
-zRXGZxNx7a/y6lbiR2I5nuRYBMpDRljVY2MqPWtDRhyaGlvXA3vLY37DQ0RM
-NXA4MVPL0jdAkYFOZoc5UcwDQ/MhwrDr9ZTX652q+SpsStaoZ0XxPl4tVbwy
-Y4zroGmiqOO9htERO5MIcSyeHdqY93UiqNjbl8t0zcejbscqHhUmsDSBsYIa
-w/EYAGiF1kGYUjMq90GjLg/uEY5r16gMs2lSaek3sB0bVjFhs/kiQoDemnXD
-KMrF/Oct3WUNE/fb8t3FKQfd0L9mGddm7cTsaLxYsZ7j29BtbgHBSI5/Z0az
-WVgArVbW8WHwn1bF/yMfmokcmn/e/SOR/PbP/9kzANIMqlOtRgY+q5XMx6uI
-sVkkBkh7Q2QdD0BbtgbmW41vM/gXzD4nBHVJX7yuxPD97uLN8N07jNjpMsDZ
-dOZtJybckoQyU3b+hUS+unVeW7Hk58ucWu5WOzY7gSn8PBunGKl4ZWGWhWhh
-hmTfmoaSE2GyqkqnxmjL2qpapkTd6NBnDVXDO26szUv2mboCGNCIExhhljl9
-ZF21mWWBCGACNi/WkXJYGFIkFNDnf6D//sAaHqyJrNXROsxysOMf/jBkjx6w
-vAI6ZleRWQsBT4rR2LzN0ZpZvMCOUpCvkzL7tLaWPuazeEN74ljBNhBooZ+B
-lya6C7x5nwJO5bUBOhruQht8lN2msxuzYrJH+nbi4ovCzPUNl5vbNnl8WYv6
-RX/EvTRbB+jKdK1cmt5AKKfxrwUj1lihnXPaaPAYcGELscxMPPDqBi9mYvQK
-AN4c7xyYduThQJJpzJQG9XrLZM2MNkzIg+1mWEZopQtdd943OlgORWeW93hU
-aCBP//z3jpUdmQCUPs1d7YQYSkefbH9OQhh31bzz8y8I0T5BjIg5emISD+P3
-ylQSM0FiBI5mZ3pml3Rl42wxASYnCUkJA6RzlBUOLNeOizwT36K6UvxoA/8Q
-5xaWMz6MmaZTZ0lAe46VEdjMQZfIJEAbvjqvb3NPpy94sB36rGPREdbCRKW4
-93lv1mxfLo2/Cc1J2mg6gsV1lOK4RhgaT8dsJEgNamGUmY1PD/1//8//i+0U
-qnBmF8kYBGnEVjrpwBVgE1BqiN03qzkt1fgFTd0EdeRzIiqJrdtcYSUPh6Qn
-79MJIKQ58Y0nNbXhlhO14vfiSqbaoT51WAA2SPrE4vCmqEWicDwrtS8roGGJ
-8kDooR1l0xQHfvahCfM2p0HP5Goq4xl5p0MLBlbJzigRS0jrdIi/BofxPF+w
-P16EBk8HCIwQFZJbdA5LUnBpyRYTZBTc5ohMNrBD3J8pKR9sHBgjNQRY9j1x
-ibrj4eJg7qCBqrYdgJXOYnTTibtviCzPM2ov29EDSQI8rSWIGX/kn3xK3ebq
-VNY3xOFXcGhnQNHZbB2tSF3gpYZjhUbza523HtUMeaazYsR+odUi/8cqaxjb
-fNGmhwPTi5fVP2hp7IwSFNAwKkNJAIazl7n4wTn4TLhOIRq075SFPbIYxKPa
-ofF2YuOIrfwhiE/aG2JX1oYXb5LBZAyJ3ximfRxRoFye4uh7s61cgJmVCBCB
-F3xKQtiqKfRXajrS0L37W1JqdZi3ULhnxB0TOgbgbKo4it8aQjwuZmkE/oIt
-BHuDVBna73nljCCyBhxcBcEDH+BEJU7kDrfvZGvZ19PRxtvmUMlQTWHMJ6td
-aA3RNnIB0dSZYvBNE8THR9i8oabgALlicD/XqxXiEyS6F73JxPCETGiPbW9p
-+azhshwmOWNiFoDAlAeLbFyNktVS056szJrswXVcGXH+4jUx37a9galq8o0J
-T2al0BujRnUh8jW2Af16GrngO8UsHZUT16RlQXCJcUKjJ7PrKr3J6jWiz8bp
-bMyZBteTAsiWOZJERzYU0hrJgeMJSFpcPrSyKAAxiTtmYp2YGO9WSEnswp+A
-cHdFPmENcjbjwF13SMoz3SNkZxsJVWZI1+HTa7Q2REQhDiYibZgG/Y4M7q+Y
-kAh4PffOXg/IMPz3gkKwLX2HnYEimQh6u548Uuw+a81gIym1dJcXq8paRDNj
-dD1axNl8CaTCY6NNKOkZCGOJy6LQoTEZFkVzDB57QntSZAbFwyAT20Sl++gF
-YvdPbQTkx0cI5k9sSORntpOJL3UhlIHF2ATLR15EmHFdYgqI7yZSZMRYqi1K
-KgEnK3KFleU1XJzbt2Poo8ezFuijS24PzCvCXiIc4w6eS6zhaAhU9ORgVc4S
-omRB2l6CBzoOvXaq2zTZP3wyXByM/jr96fbs5scf09fJP6Yffij/+jJ9+/P1
-1YeqPD44rfZ+GFQvRy/uj6fTjuYQ0vs8Ls9g5ral2/hE2Kwc00iUUYy3CgDi
-6M1R/IZ3zKmpOUPUfYVWj2yrF8z95dpuYh10x87g8bODjn5+ONjn8T1on7Mt
-gPto6Tzvl/2KRPks4zSaCgU2oDt4E5WNw9a1ybbeYJIj0IrAq5BODN2y9L0R
-C5evjtClmd/Zi8MefzYwyZr8ulKUpQay8IF37zIp61Cm93ExrlH4YoNLaD8Q
-O/5udhO2tvzWSF5WrMFAyFInSMAAWxp27+jeDOr54N0L2n+jdPyetqmfgeE2
-6cYbpXnjv5PvLMq4CcSPPJgfz0lI3aaIhUo54EdiaaBzkWxfdhhlfseHt4cu
-OJQls+FqgchQXOsQtEoDzR8q8GvEJxHrc2C8Jj4y2t0mZLAkAFbQXxzx4NQL
-V/7tCGBKxbL15hf8qSRSsfErMQgCTCeCUdxkD5kSN3ZDpEqrplusFvAW1mKs
-NF1r68zj+XRRiA43B47X05LNq/a8rGy25gQaNdNJ3f89r7AD3sGJXPlbHIK5
-rDITGUdj0ioiIhU7xIF9q5+viNDza06D7+zYo7tlII2sggliNBk7OgYFxxV8
-RrISPeJiBIsJrQ/rLneZgusq/2fWM9Fw7PWhZtgLZM9qGXFxw+FqHZgYzOq5
-4O8Y7dKbB3vfPqG1qmF9N6gcrUUEU/nQp3HTqesB5s80eBhxBGrVIvj0YQHr
-AVTnJnmZI2nGZHewBlj1N2P3DG/QIn4BvkV5CUjGecERszFOnMqzYUpnri2N
-QKfmYDHogZBrfrG6xREhXOOf5R7L0CLc5B80oJOx3s/XEAg/X8+rzlBQR1b2
-Ped6PFmpHk2vz3MwD1ItJzRvasGmtf58LT1QI1Y4e7lUJtTTHt90ciKRCoef
-5nfjxzkCadJyTQchWudYnJ+vMQMagN/00enu2WstPKFf8xv3EqiL8YzW9MJR
-ux35NDDa8jZvxPRa861nxdetrnG+E6NWEpoKITabfWY3CeRvSbT5jgWTc7TH
-Okqc4RwmrB5tM3hOxljNJmrbDKw96qkVg07CB9TP1zQw2oW2sI5HJ8aSFdix
-zu8gnsNHodMa/YJdQaxBFIubXEPH8TvtWzjgaCJYlujIRSo3OB2zXH42OTEK
-D7vPJSGK9+nYpPPiBFFfanPf5b4hKvBIqUxs+oERRTTcYtoUE+iYUDBS8gSw
-wcL28PNGDePW05qeHjx9ur/35GBwuMcf4gS2Hz7VD6GNULuHh3vZs4O9vSTb
-/3aUHAwmB0n6dPAkOTh48uTw8IC+2RtQ03jjXp3Se6PBeH/yOMkObg6TJ0+f
-fZuko/EkyW72BvuPDw7xSUf7Va1uiPWEsCF+uq5hcXPaJOwXw/jvv0gfFvoM
-Pwu2W7E2N2nwm9/I6+N0L93/9fpDcX0433v37NXV8+dvnr85fv235++nT5Np
-8tMyy7//y/zwyYFOFxJ4GH9kM7JMBTJLRNb+waHYqJ0scqLIiRl5hAWGJ086
-ZoETMdERGyV3B/19wOtPDf8+suLAlsbDH7DkuXKa5+Z/FPvxRFc2H/jjIz8d
-WEOXmwFX+tZLnN4auxjmspjCEbWfRu1ebxbCicR6MRjsffq0peqNgSViItdT
-zW9DtaDcWX9QL+nHSxMCEkZ6RL4xT6JGFLdKM+pNV9iPWgrPmzofYG1d2Zxl
-Pj6X1EcxibudPoGa8W0KD5oESB6ZULdKS0GlW8PcTLxV9XC4WzMUy6+QZMPT
-NOBNZEv0/clVvJsuc5UECfs/eDl2B/1B9Kqo6mGs3/FQ+p4QiVpi37L1X25H
-34/zfr8P32y/vznc4CHYLOihjVA37SYIdTPReGy6wHoK19mQt6bzRCKeOECc
-yxxYR71vUFOa9yL79lb6ClfNmI81fFgXZtJjc2+EaMO1rKXhgs8ynmp2NgJS
-nZZZaUztCOb+3NhglK4jAfXETXf5RPIf1I9rbdFLVWNtSrOob77+xHx/eoMc
-bEMjvHnDBcDCkDZwox2tZzsWWzBxRGnpq3tJM8uMySpqOqpMRY3ZzJBhYjwD
-1ohee+UyIm1Q2wmrhtkIR1OTseEO/qZCGeUKAxRllEPZYJj7wWZ5szkrqMfA
-EvCtlnbVrA0sIa3cQ1mJ6i/jlWCDlm+Mp1kFPGsiG/mIExzHBIRYNckppm4M
-o4htGfnqUCEKbeZq9yIuBsfkgNe5KB+uTGINg0BIwlgRQ05jnvETYEw+aFYa
-nxnkIXuD7CrVkTEjguaOxOwlcFWhptA161AfZ99ilouIXESB11wXO+QM414S
-lsoX2MUC1by1voCfU/ehxyt2upqJQ231XDK9b4jSUUdhZF9jdlWdLU0ZnSth
-fJSmVG/GUDy07G8Rm7Qx8KnPqhF3qkk9HKnEaVRdE4gT+hj4NGIg1lMK8eu6
-Sx1h85umr2XHyAN19HqR5YJSeKzGLyQlblzsuxm9SAb4YzmmVa3kXKgGm2Ao
-dZebZnOStlXt4sZ5P0QucEDDKU3UoAh2cV6w894XAs6kww3IbLvKQ5453XKr
-vuC4yrAPvy8sJOYja4F3zLbjhKgv47TEjUScrBaTB+mEGN2rbE6oh3SXt7pr
-lT88NzU2N9PO70gD8WMTrjhlZ7WaQZuObjWVmUpQ3MByhgJp3AQrWFNSq61D
-WNzBdTHLOJ8t7npZ7cP48V6sOvdOnxu4ksXosSBmCShDHcb/KT/0aTDxHwkf
-5bMJ/yxpRNzXNfq6tn39p/H72841HU70OTc8biEEid/Bi2tj0KcrOqDpEOWS
-bKQvxjBfoLCvUlpWiW3ohN4rFB6SWovw2R+Hz4pjM5+nZT5b+47IWIueNGoA
-dXWtMsP/GxbHnZ6WTJHocjuCdr4i5uUK5OozYwGOZJ6e3ehbeOwAxgk5rRi/
-vXQFBcARqB/oSVHvzDKGd40EJ12CjcRqkDWsRL1+U4mE0IFLAr0Utax5FKLr
-PLAPDrlQlEu4hr9WIlvHNOJz/+C04YiAws6ZHIsNPcjThRAsmrm9LN0klCSN
-b7hIuK3FVfqld+AKZxe4renDQ320gR+sd6Wp/i+rbDUpoDjYCieV5RTvuLBQ
-TVNU3HvRzWohLlvrVyWs0iWyERwd19fMR73WXbSD1JXd3fiSzqJ4MPTOHwmB
-grf1xjXSN+FkaLxPq8kd9Omc2BkqbYitiRhlWZRdDianQy08Ejo7kdfnvl04
-twXYZGrknbcL2U7DD1/nLJbRN/tiOcNBmvmTN9ppVnftCzsiri0PQwSTamyK
-L4cj95232H4spEnvjv8t3tYgy6s/c/ciuloJ/mXdZShkbaS07qGQbo+H8TFv
-IBsAEnflSC5T2Am4dtQ8rzFIVKrC4fknYKHuDjvSKtIk6ANi32veiOGC0owC
-1tEWNKhu4888/XDNldzo6WvbLVFG+0HGCiYqh6f5iDZc1sY1x3mJSIAyLMyh
-NnOJXhJ7Ngx7UWRfr1ZjYM7IbQc3OynXfc0TtAtY+XNsm5qZNk+Q+2c2p4np
-N304Dro7WHb7SNuUztIP+XxFqoESqblK/oRa+NyNeBjyHL7/059iN7sGe4HE
-m2/kCzN+8zi2db7QZ83c0smkuXt+zx4jdg732QbrbS5OkwG38N2WNdKnv5z/
-PIrJ146ppFa7b5YI1UBjmGhI+3MrnDsa8DBu7FblAJX1ljGkXA1iK6DysLYT
-+XjsG6MhVop/RC37ILVC4rfdH4yG+YNavPQ2IA4XMb0sCq5+DAgmirHJZ23t
-ylNRqdOXYN/1kivJuSqnLHuqWw4fxMll8gLyKspucJEIVjXwxtHGztMZ6q+Y
-shPQdrMPNfzY7M8jMVeUiKHKtMWmrqWnvMIs1N9s7LOouc9CgDrYoz9CDMXp
-DPT5SRo408epq80VNAqxp+RY2BFZ2LLVYzdG4xuNCv9V7Ftri+0ReGO9oqRo
-o0bKonYShcNxvCQ4nKaSP/eD7x3/+Cgw9ogK7D9wbvBGMyVX1Z/KqcB1oPWG
-+WxR4JNnnbeZcEmnn2ZBbzeO0YzBGqkaI7xcup5KprUWr6LpunwgrBEBdWgF
-MHn5Rl3RP39o1KLjlDpj6HOZUMTJzRwsVcw2GuBU6LYGIAkl60xqSUp4OVc5
-iavNJDQF5bb9TBPWN5r2wHgav18U9wstTyiECbOwtHKM53pulAw6ZAcoDSW7
-83Pgw2QvMSLwcJxVxKyg4Gy7BA2607oKpx/296m7Jy0kNMnm27oE5madCEEA
-IrvviMEnW2e1JVzIIFxROqi3bypuyvIqTcAvmu63SY++1yrGXo1OW1hTvZPj
-TK5Rgv3XaxnGjF789vjyXJiX9romSUkXoxXqksarJbA8Jx49bXBCO5NxtpQ5
-URpJlarBb+bbP2s07dUo8NtrSb6i98UG0yhO5Hg1yMb+tjkHl6EUZKmYJIxv
-JOPCFufnM93l9Ug0MTeSsyxiU1BPMw2qlTl1LF8JuHGNb6RypBUHZGvk5Xdq
-ILcp6bJUYmrUPBmTt2BtCRL5EEYupvlshcghvP6jyR+wmSbqlvItlz3P3iRE
-COYuzOtKIjINiL6DvX5AX46a0rBZE/xpTyqzhziWilXWwSB8ne1CYbz+wiYE
-kDCRzplGaSWmrG54QNtgJnaUVbfFjOSzdwDb41pp67IWdlRCPtjtzYrN39xx
-cKwvUBZVqs4vPCNUnGLDuJzGgBks8MnniAQqjDWpYUzCXhzsW0KJf0Kt3hpm
-0WUrR8/zXfc0xB5hMCKTNVWTM/Sz2SwREzfapiPlXI/Rpv7PcrRZFBrv0DFx
-Khl8krbEEXQSIRhWshFri2T4W9DCI3Lpm34hHMeG1I1amzaOc/EIbTdgmgio
-SDeCfWBWTKeaSN8oXB7HJwzXTZJj5EVESZAvMC7vRMtiTQ+SrWvPrlJjTeOl
-NQg09yJgUZJyVlS8UQXvbBStEM8XISLIzqAcicuF8X1hLkfLxmiJdZqFJDdw
-sPc47hKgHuUT2tw7UFnwPk5oWipJckEhdeu4BnbijwXoaCODqPtu4Yrkm3Zs
-5ZbN3GiZjEYVy7hIbo2KybpZ2iONaQpIUlIVSkUJ/aShWpELuxaDmV2SdlZh
-THzle+EioZIN4VVyqquOSWxTgCQLpLk20Y2WwNwAsc5Itt1oxnv5mpgVRpDr
-X1Hn0kgG0mm3KJ98UmvExjXCiDx91VjVBNgKJOoqWnVI1a7MDmnDSzyKvs0Y
-jLVHJY28LcYH+blPSDX+H3/awKWB/UE2YbdzKlwDxc3hBbGeuAYJMsCaoBgV
-a11dW2DadQ/ttHZB+sJtPmJDk8Ue1mb1WtP4HSCIDDQF8YgAG/Rky4J2+l5M
-CzAsuHcCA15jMO8WDIQbJQo6DaLaFZC2cdgoM9ACXNtvN5buAXNEHIDfnjfe
-dqqZhbGvNMfIAbV8gQZjXBkpLQx9fq2feVTqbdKxvd9LD2NbG7a21xyCg5I0
-1ClXro44yZSWDYYb+umaJCl621wwj7eIWenRPtcRaRmSyz+YE4Tm6iB6xddV
-c0Qa2GjwKeQlwVNNV2PzEy9Un54zvdL37QsgTVkEJx17LW5QQ7GfGgKdoODX
-2VonnXOxgJYeIbzkUS3jLmEJfLuL1gVo9ukhtXCC9CH8ZQJeOLqs277eBvNp
-KxsETZGJTxiNTf9dCZAvYkZsOi0HuXYaRBafXTCGOBGj8DS7tthv67gkQZc7
-ZHdNOi06LX38udnHQxb27d0EU2nSoQHm1BhrQHT8923Y7hdrmJVnQ1ZoWGXN
-oM5yyZ8NOxUvA/9oB6duHYaEXRMI4Xz1fCyzG9qLcgjs/IFjyJ5AX2JgbfUa
-tVr3WwnfALECACzVj0LMipBjjVTJb0wcgue7b3ijNs3LziwtMNZMdccZdCU/
-KLDoBjjFq4O0BUlIkGRQavLUXoXy8dHG5ScaG6SRYn5YAcFzV5M7AOoaWm+q
-aQcj5OzroqqT22JMv6SzdZVLyp5D+b6W5V2E07wXDdgyNxc0KRNKNLRfwyOy
-V9za4KMwptPJzgWzaeowIFaDpEDEt48UBPnXbdYYrc/iVSuHdkCQCklQyKmr
-opY6uggHzjkO2NRz6QWXGQk5KsS5RBzFJmNp3n9i46cM3tQYJswa8fR+TcIH
-lalQ+1WbqDSuls4jb4IVwsZxI9wwfiteTwPxDYs4y6oEbzCLz4uJmMPYJcbZ
-8WrKDCNDdJBaakvqecLLXdR+uIJcfWEigHCpHVvhU9zkVNTFQqPI3P15sYTJ
-0XjFrWBKyBG+I3g34qpDpH9tjsFkAlpvADYkrIzpTAwrcgmHGQWMfRxPxBYW
-tYWetuaGBn2p9tJyl5oY+org9pFFYTvk1DNGQXKzlDFmeXVHOElPr1Ik6p9l
-5XtEppaZ2Og2RzHKLOnFfonyzeYmy2YljMjF1el1hAWb97UUaZmTYos7Vwpc
-5KcVpGK+zR7tcSiECVOoTOi1mlrdzXuVeX4cPO/fH0Ejma5IXmswCptuHx8e
-7puUBlwgR6TTYtVhLEMt36VjDiKUat/SD3yNXF4bASb2zsW4m8vX+uaOXFog
-t0E0jLmRKfCvMV1BEripgsLuOu82F+SawKFQFnO++F57RQJIyTXra9TL5BqP
-rmNOnwrrr1uIXIzC1Ww2hA71UFA+KrlpY2qsEdhQa00V3strt5OVfSK3GaV6
-B2dKOQY18gF9XaFICAmSfCkpSw90Zh7KvCiiiLdEOkMvNFgNi2y5z0euS0N2
-0BFnB+HL13CUGW+SlzkE09/MfvfJu4UqSC8yEVHam7GWmCIEUt1GYNi9lOBB
-WUuTUeeVBAiK3XIMratzC6GLm5ctB8Cs1GDCMSctCQu5+zCUl3QExqCP3zT8
-0xgkUj9Klc0TuVxSShJ0x1yfpKmYWy9CslWKv+AypNi/DElf4+xjLeYttbyr
-RkBkLZUdVrikHdlVJqrctPBFFynppGXff809Ss2Ho7Z7lMRBjLuXp1gKiTpP
-zMDcavS24ZlGUWWXVoesuihI+4q7piRwvpBMHU42tRVtF150spdkp0l0kG6o
-vZTXeuu9XNAqwAlgzFyTGzGn2gyU1g1glZNyqA5oGLwil1anzDMuEr+SpjGs
-GiDcuAvUXtRlb6/wovitr811Ytgs8vMETZbgkdTW8cpO8Z7BSL0m+KKaiWrC
-oBdtsyVqG3FSMQGzbDGtb6VUDHOMl0YY621poRzxkguNEViTC2ubHr4lzbBZ
-j9KblwQ3CL7wI4q1ilcs4B5H2FiiZBcR5yNoWswma3kZhUY78xnITFfruIQB
-niJa34YXw5zTuQEkitiWSkWIoHBvPc3lYuI0tBXRVYDasFZ7s+xE8ZnIYgah
-qN1H9KEN70pbOdd947YacyeeXkIXL2fpWG7fwP2H7oJC7zK8IdfU4Ze4dAJf
-9GzuTlT5K0esOCxwM7HNGEYBZI39tIeqKw/id+JBLxQkbGAuOU/bUVfcQF3o
-Soooe1e2+V0d6c0ikr/A6D+omS8WmgUHoywWpqSPuey3Ur6109CD1RrpfZ3T
-KI5bSrqb2pd+VXdxVsPivJm/1lahd1sl3kgVOGcvCSttNkpFhWUiI68nL2kj
-LM9tomq8OmK47VFh2/YeWmIEgniAz8QCxN2KA72zZfykLedpRzxdD3lN2Nxy
-0zoKfwQPeMQk2WK2tsUBfNdYZF1jGEpb3AKONy/cmKNmZvmoTAUyUps2KNuq
-pLHUVXiwVO6FlBQ7YigLEaTFgZUPzdEo6fqNQnVVwwd7mPje3LqIXNk5rcvh
-FTET8Gwi2vzAAJPDjWAsfpSO6NXCWk6twZSU6NTdHWGtqlrrPeJapv4KkFyQ
-745Np567m9OhMpsmxOlQkV9gQQqP8q2HaiMFqYwLYZ35bvWrjZh/l6/lMtJ1
-dirxWKmV+UT+KRbkhskgNLSalYPUGZc4g0Lyy8IrIBS04lwjetzMUvbBSvGT
-gjUqO5pt7OdZEySGrbhhUgHSJlwJTupUaWwESlVzeJs2a47n1nJxplicuQlE
-L7uarOTGosw3CrSlCBAXn6WLJF8k1G5ylk8QR3NuqRqCcR4P1GuTUyw3tFgl
-2dxaa+oA8XNStFVOs6vXl6xP4F86HBfSSWWCU7i+YVhyO3rgtq3P3QLQi9zl
-zFaPz10lPj8DIRbX8Jk40N35UmlC9cH+wLvTG8rMjBXZGjVRYDBZZLRhcokT
-siYUZecJseSCr21LJChb6lkYvhZV5vXlLtOl6wZtblNQyYKKo9AI3sv1eqov
-s7KZ4LDYxd0J3ca9L64NviVe06JtJM9CyiuLW954xFXEJXKBwsP3ZzUvVLBH
-H99RzwwGsONsChoY0XoacwqOVT17/JjaCXgHkoiaZpEnUiSmh3YMDXuaL9CO
-huaaSscNFQnaRQTTEBN9S6SprbGSzFi9t2irRCEeqfsDT0cpGbB0LnVvi5Vk
-gU5SeLbZuEtA7rbiAifnbo5+5W+GswwYXqXl5B4C0tqnzooJF4/tvro8Y9cE
-MsAI4NJOZtyO54RoaqXtNy7NbhQUIyVHKxS5uDq88g5lQKsV4Au2qSN/bxMK
-aKYyTmsNCfINBXxJDkchkWam5XVN6CSSguDV4oeWaV4aNd/HaOlGc1JXO0iF
-1QAVBa+KibxQwTLjoYqTmBabiMMapylhCwu+rEDkyfMwZREFwfyBuWTn2drG
-TtL4OlFLLI6WMVGjI1PkJaviplr9kdErN8wqJEU4dYaYPAjP8e63NlVfG24i
-eyt3eOIVYVSPhiY5Zdvlx7OVdGLV1Ur1VXvEkZqr9p5ULQtOLAiV14rx1sHN
-cjYa6kx2IG8zBUayBT0NQ8nP52W2qam0GYmj+HNm4jaF5cdNdXoYv7Nxq9t0
-VbVtGvvHFvNH3Gr+YMMq68ShKf7MrEC+SQict/RgpehD91tqnE5jl82H1t+u
-aiQHjGyB+yGXXRNrq9HPpayGeilUR7BGVC7zwMqaaiGEM0QsWBouQbJyoWz+
-glMSuOySnM1R9EAIlUr3VZ1aMzQt4QcUDCIxG3VJmpfFh3zO9YnjwVxC0NEg
-vYwjs0SGkgpKvk4Gt40gEYF2Q+Tths+meMSbKR7R1hSPjRROKfNkUjo0hwOp
-+JVJ4XBOmxZMqGyM/PN1zAYKhvq89+T8PDo/1RsoCUeb4DtXgo1JbEvlVzJ/
-Xxq4rAqvGgAbxresjE2PuE+l3hqJEjrQIHBQq2yhwpDd5nqliCuVwBXhlCGu
-jKEcVzGuynS8VjnP2ptRfSQjuMsqRE/ibneEps0kxn507NKmw5xk3hScPyvb
-UG86semPv64m07nm/Tx0zq8X49uyWHAFO64gbmauFuw3V+c7fglOydhJP5/c
-HT2Q3B2JKGjYi/wrOLTovUy1WqZelRbx7phTXoz4vvjxJsGeYnvHDknq6W2m
-4blROFpwkde9BvH7p7/L6jUHqL3QXmw0hiIcmNGS7C5KiCNlRGwj1pWZZ/xs
-uSxxiqpBxUIAwpz51YxaDetNvpEgCUjqZoUMMAqe1djuqHWkjXBmUsttULMp
-5iiHcaOSEko8IauJmIkdjJJLbuyRvFLzRgY6W0dmSOjbKHPJLB6pKzkLaj0h
-jXI7XzvTgdR9kJoPnLTtIshj1HNVt1lfruOTzDRhF7kiE9VSNjLYbcBrLTfM
-y00rWlmeiEHLJSe9lilRg8GXloBkw2rk1ZWkA5BLS3qb0HsRQNMvElncRIex
-VH8U2xWhlYJUxY2qo2y6eiTYfLzpEDYFmk8+LDnM2Rbel8VccL0WKVsgAb0M
-Z458/QrWpS7nh+g1HiLlGmqUQY54e6w1v+CrWsqadl3s1I4X+w3WmtmUOvYQ
-JU78fpl09RyN1KWR5l7UuExJfGBSrhc5oa7crknn6KplYNJye3MUG/caAiVc
-tTleTlc3boexoMIVDybAFmKNiD6fcWYc61YFqZAZX47tXUimj89wEQWGr+Ep
-uLL6nOCYwR8a6qqFTlx4e/f89HTHMcFZvqA99U9X2ahOk7n32aetx7w+Jf41
-vwdTAcvwVT/SXWLKsm9ce+pdr91y0ctG4fidoLA7H/tI60wX0xVMHD6TodhY
-UOHRQtxu68bBy3zXkohtJJ9HAIYLwbS3K5JyqLQ3Yboqk3BARobdJGExUqsy
-i22wVDqLdLFR+TnLWjctc7KNt+BKquDkdtqos0DDmMBwR5zybpwsRgm1ergf
-r+Rr6im/lqhmQ9/LtSdpHbFXyKUSOKTN9gJTGFXQSslohYsGb8txVSFEgpk3
-EWuQNVt1eeIK1U1glnf/j6Nn6VVjleLaL1czs39dGXjZwN0ww03d3rphlTN3
-og2ThSnSNls7nKxKi6jyzlIrpIuMLwxh/By9ZeiEMta47N4LNZK4IQF0rKeR
-0h5xVoVtz4zUl0ImupELAxgLvaXFkRY72BR5N0a0ENQ2vtV1/A+SGuLQYXa2
-A47ChTU2T2MaNIzomRz8ImKRkb3fia6MgWzENqvTJ0ixeSSl6FtOqTMIxPgK
-l05oHfrUhBwg4s5gNDXy4Xx3Dxkd2b8HGq3hCovIeHpdB1XHvL1uOA0xODot
-eBQoTIxq3lphSwZzuRrV/pdhEkYUXdg4Qu86T6SmLUipNBeWt355giKSjPkC
-2uCBZ6O8/s4LFEzlmkdT4oodQZs3nMZhKnVP03T4DRvNR4TbqGOpjEgNtJWy
-DIpYXrbHlWHQkHwYzpZQNRukZq6hMisMVRNczPJUscVm60Kz85XxhTVuYBnG
-AddE0ZFbRDW6SrAI32NnWAXvbT7ofGku+oShMvH2/SbchNd542pIZLCbWnIe
-8KnC+sTeuYqhnKVT6kJ0/G61o5OO45e4sMkeKf43Z+ilLkjs3OAZ5lQsqXsm
-EtTAA4GJcWaCBCGJWA5rXfqbVcmnbmNMx7cl7h8lXnxjKiD3Yrgu/qetiNxH
-0tWpEQQrOCL4TdIh377BDhHXHhOYDz59QMZ3xGfQlq5I4SQQoCcGn2D85OnJ
-1UuWIX4FW65FG4gSlLLl7xJfdnz6nRImKFdrZMyrNdAZX2cM9wfpGuyFYjdP
-F6Pb0XHhLg5730YnapVC8qSRNBulP2n3caY6vqReiT7M6ZeNGG2Z1caW6BEs
-8Qv7fmremtqgnACXfwnlNFAsX0hN/cZtz9L95yT0b/Kc0NH88sJhQXwmrHJs
-WYU+u7A3PPwW/TZMkmTIf3s/DukLkuoTetjokl75dfoUzEb/ANS5u6I+ob3Y
-gF76WlSgXa7vyKfJgy+SlKVvtBqU1IT0kPGDrxpFBE8xNGKg/0o/Me+1X8kj
-LRjdhR58K5Dqq5sAw//mbsfQWy/CgW8g4N84EYOTIPRDk4SxhQsrZGCcbxRs
-N/dyaUwFl7eWh16Y8Lwf5ECzLPWV95eQ+pgkXN8OAOYdnCDITaBdQYdIwvcf
-fKLJiKTOJn/qsGuh86kRju3KvPm3S9xl7hYFemQu9ha2BNwW91GAytzBYkBZ
-vojbYyLFXFFlkVZS9tsWIql7d1x9h/YnKzNIz3gH50lkM4LdQdW4tCQO7qHR
-gD4OPUBF0sic8M2LkPUKgsZFWeLl8aPYYVsbjVAUh2cpeS1QyhgcyP3EbgY9
-NsR58QICk22CB51zoyzCJWmmNkywqfoWjMIq/iJjV/3li9fHVhy0r/Qph37p
-axN5rSpu6nvhNb6jhIWkKxvSRbM7vejo1BhIcdcBHNhSBdnVs75l5mAVxSd1
-ZLKAEEZfrKa3sE+zkY19EDT78FYLGypY6aKCyT5+fPniKNkfHL+8GAy8Oi2D
-QX+w183EaPzx48m75OzFBX2vA4h8GGOPAFs40hQN9mdu8ruxgJY05jLIkHQA
-RkjVEjvUEZGKeIemgprLcNYT1kHVM2aeZG9vwNUV0hK3ASj+4svuYP+hN659
-ol2DDSNt+XncPUYFxu9ZK8NFcM2m913TprOwCwsPr+fs6zZNH8fdK+i7/NtG
-s483mt0Pm5Wtnl3Ds3ddrfLaNvwi7j5fIcynveWDjZYfhy2P8PK1cso1LB83
-UBeiV6wfXigHnXFYZ9ls/XCj9YOwdeG8zLTP39HHH31fJL3c7/d/+RRLRoac
-GaQPpThjdoIcPb0QIakms7E5Hh7anJ1P1lPD+YR+gWoVauKHZ06yNb7CFK6I
-b27tadQhIxp+S9ckrEltX+Wwg0kmrzG0YUrHhsKcG2ASMm0+AwI8VDU3m1ci
-akvcG8tlWWdrQ9WJ5qrxc2qQDoPMxBcBC0LEUoM7rd7ny6U4vsqMNXc1LDyK
-ae9rSiMbPNDYhSsADlq0SrsXUg0j9a00LBA42AWNKoVLBwptYLpeprRFNARZ
-hEZKBFMW0SN1y9lgVa9NUlkmtePFHEaKanCFmlHWIv9OVS52vePMP0Gqn9hI
-LDnU1WJkGxFLr1GwYqi7TeAg9OU3+v8usnKl25QcG888NlFLvhjYeOog7rZv
-6Y0nD+NuY3vuxH9n3nPx9pNfwltEJmmikl42n8cdxFHgF6yZZSNT9rDceMyG
-P4bJnJYrbDYMX4PpmNduOgmQ8AqDiTKNMP2agwRVLe9rYosDS9bagfY8daK7
-KCQkGJ+P1pKKzJFOR2r81YDCWVEswz2IS6Bmhi17G95LqZPQDM7oh74NuZit
-eW+VgSsaKGRLZmOgfUWUsMJ691qw6m6ShnksTMjPnexDNhVRA2UiVsk6C60T
-UWzkp8pSNlRCwnG1JI6SMiF45hLDpZyjfe7fgoYjgtYf4tNTUkKRECwnvWIG
-9d2X6Tgz9p4bW6H+YQhlezk6TY6Or9ARDPkEmQb7Q2LIuoDlYsxx1ax5pkvp
-Ai4twJCYfckJ2/QJhskF8Vxsp5jduYCqFlH1QNcHQxFAYitn0gVcLryFWDi+
-2Wd6W8caGGkzvbTakCftXb8cmMV+dz95JH7J15IhjuWqTIHsHsCp4w23PejP
-cNAISRbkRAdiVp72KF28/6aKbFgV3xBv0lKClMgxdYjbslOb2zdeG8Etb5uM
-lnzhrkkJfeUm2M5V4Parb3snn9GDNDfUhQ9gL1eVHPkQ7hHfrO1PWQ91d9m4
-YgFQwpMeikT9AuRDpoa5CocWUmEqyf/zoqxvSPss4gviKa3J8QBUjRFnOIzt
-HV1+w3pJF5hTMrUdyALu/2d2vTS9XfNDjUHKClSmOZf+umOH/JyGfCzrdcFP
-t4x4/+ERN3oxN5Fxo81h85pcy3fX8mJz0O2U3QdONxKuZYybcHrQi31g/QV0
-9uouhMPW2kDMF9feU254dFBb81zL6LZA8i8Yk3O4hEOysABjCg9suZ3Q3vq1
-KShUPASQWY5slPXQC0s2gE07y+3EsWOTbtv6gtf+7s/sl/Z6I39v8NEvXmmS
-n7dWKeE/u34Vk7uHnrxzTzqItWV5d/xWwxm0Vk35rfXTzR4PPFCHLh/qp2Vh
-UYf6gcWlpeP1hFEFs0N2Un1fmOLRgnPdTa6B1O1Foflp85Qg6X7DqMgvQi2o
-Q1L6tCwSoSlIW//uHVzYgyqb6qwEmKNjGTjABFzj29E6slJfg6ctMg8OlG+q
-ZgHbrwJGZ6cvT18kp6efPg1Dv2cITj3XZ+0jSnaNKabkkwf9mhB1TnzQfBtB
-U742ILjhxduLowZaEcgQjP0Uyb5jvQlTMczDkOe1Ah0asMlNBuKdZJz5dJpM
-yvyOi+cq0nG3VbbeEt0OIbZfEe0MmeqZllz1L78jeoxQLc84Wc0NWavgUk5r
-8HI5vGzA60Xi5Jzli/cVq6cSZ4NXOP9Z3O2aZjGTNGemAcDiopgjjJ2ICMfT
-GPEVCnO2KsIMp2b2BYeevJB0y4Ba8sheXqaAA5BGcvVsYZtW3T7AOqTmRq6A
-lDQc4plhw4R2UYCtzmdEfXPQf5ENbUlvXJd42beacVph9fXmMluRShITK89c
-dsn3DH6BqazZpAjwcVpOi2u5rNCzlZ1LHNEX2Mn2LWRoWMxsXIwJSoqiS94/
-jEp0yTY6+KypTJb72ix/IO0dS6msd0xp3VIMks8JPs9m2YzdRuwhgVldTVcc
-mIlFwS4FJVksC0iWRHBsJbP+fPMtKSZ6POkNFNy6uaoMZPMKPKC5XsNpAb2N
-+PYbXB8m2hwXtDG1b02LnuarYP/XItdCChwncpGJUwPTbd97tGvDSy5je8nl
-FmeMuRUzLce3OXIDsa020u/wLclVrijv0vair83bs2cKKGL1ZL5RRgTSasl1
-TXO5m1FkJiw52P0mD46OEtrVUQcJ9LkG5vNR++8aechFuPI6yFYxtUTo+KTH
-qIdZFhhFO5zihoINrj06SOnZ+KqYZhptl631XsOFHX2CW8GSRuCn9Spoam8j
-RiIKjpq38O/H+/099faefBiLm9a47zocNMjev/ZV5ETGZ0++fUwU9m+V3dqy
-XS9kCYoLkHN7bWfdI9Qt2nHl/vCV54M0bkMNbfSiGk35oYWUqmVPtgl6tizP
-oCVCpZ+pOixvWdMxa4oTHkc2cmNu09kNDm/6at7vIJ8Ua8epHhodTMdhViIr
-gwM/0cOck5ZTadbWQecYi9k6QnnAtCTMCRuSjF2Dl23x9RRJfgSlAMB0Jvzg
-Duqt2Gs3g6zK2JuOH57Jzjy7s3uRiJSSE9QXxaavj0PWvAo2rswDx/yZxHCm
-ON9FpslldlzRCKHut6BMF9CU2tmJJamIjoUpI7SuYNYdVzgFx27k8tT47s6j
-7/s24d0vMWWKyqDCXL4Y16bSIyzKXpirMVkJ8NuVSwjh+LdJKchNE3e0q5bv
-eEktJMDqNHbUKtRyHSWRfYqxDPVxAwOYf7yQTfBMr9Oy0WHdnNDi9sDb/An7
-APodyXXx4CrvnKp938n+2nzaF4MFhpN4ADiRrJpPn1CLZJly7mrISCZCSn2e
-pup/PJa65mBQ2XdXHxaJ7OwO4Z7r+5nZhCSOVvOVXH8nqRVp4gLXUKoGHmjT
-cOVcQsLqGvMtCSA8Wi9STlMrqqzSi8qCvGjWL2icifCmEF2qZtnURDfYJrvF
-mgQp+YO8a2WzDlumgf0M6xw4hzaS43o2Ys6J1SXfycUVcNVGvVLYUpV2QoWA
-Dy4MpgiVC6zd4wDP0rk58Sq50djUQqicF8VOyObBRHKRhhuTlCsnXh+JiVYm
-h5wVgaZDwR7tS8Ko3S4JFyrDols1cIMDTdKefzWCjvE72OHDXoj+96kas6Xl
-1UIOiomNYvULrZ3WTQGmaeukIy4QMU7CConSm/l1KB4IiYNig2FAICMcGy2j
-Xi+NKLQqVNSVjbVtT+HyAKmRxaHs6URP3MjPiveugkQuhXZyPa4/dHY4h9gf
-XOTKQ5ah6mEkI98ptCkBUqt2sD2/XIOD7X51W795iJi93+1oGWRhgLzyxBrn
-JsvNtn8Lz0iiVBn/RKeUIBwTH6viMdqa70+9cVRWWMGtp7hWjmJJ+YnPBRSf
-73d2uBhWZG5CkoFqATlc+i3I2pu15rh40430Zga+TRtenUYwDwSHHHgAfp26
-vlUJF7lQpc9iThgiEMyVoIgDwQ40xRlT4yIxENyO8TsuDjbPceneRtEHJryc
-h2GVEKmg7AJQNYfWK8B6pdGu3bdE0Su+V4Xg086Wc8V/hub39vzkzdXJ65Oz
-k6uLnwwM10H6VV41pNbAS4u2JVXZ9yRNstFKzCJcsKlYIABeqM2ZUGIOE2/E
-HQfn58gwqnG91n26roYOnm9ctB2pPYv4KGG2eqhM03e2oUiKXiTiF6qtOQOR
-3Da5tdLnzT1nYQ5gVKKwwnc8p/ZkgKZv3kdqkZeuEpIkXA9OTMBBKGnCs7UL
-vZ1EWseOhHXNx5px/hlNknPcN+vW2hsk7PVnJvsA7zXXOGuVL/JN1L7oIg/C
-fAYhy0YAXV8EG7I3rORukIC72oxQ01RAqVylieyl8VLJnniOVEvBBpiZv0Wk
-rNkWqPUcssQSZORaafK6qyJtpiOFmqOwUHMIaI3SxGewiZisjcyap5xdE7Fe
-uChgcjBWs406ymbZdKlt/lH0QEHnltQ6z+5Fh6Y3Xa0Tw5WcY7+Ss8zfeUjF
-DBa52s1xIDI3SnNrlN/l8enVVdy9XHEO+zH3aWsN9+Sk42N9vO7p2beq6i1y
-DIJbGtxmXajGeV0n/reeCptGoR7NqqUkEZtR1C59QO57l3EzrSJnHBRJ4g/e
-ICQi5KXsA0SOiz2aJxZx1bVlXfkb0UwmM0l3vPnDXaiF3+TG+G5LwLTRqtlA
-zrl2qaB0u1X8aBy7BXnhZAAtI4Z1V7RqG4vDdTG9jFI+83wCeXQcm0ve+9FL
-PofZ29KT6n3OfjEnfIcwGnHFO8su42KBWhw8IqGn9l5ExADpcR431K/RWpQ0
-gpy41IX/lmc8mGbxDBuq+TxyF24278VjuueVNWuYml7tpJPk8zbO6Iv7xFRA
-s1ltLpmN8Y0kf05y2nxIRnXIUe537CI1FiQITyqreMcQCnWRwPoYMK9T+7kJ
-Gb3hyR0vt0kmnKo6cosaIpHHS2o+9DO1rVGH+brbiPbdidhjxAiOe3UxzSYe
-EfcL36LLNrpFDWOGjtlPM2fDAII8bBVL74T48fGxln7kHQ1XvKCsLSfD9uc9
-E6sJiB9B0dPbTGx+rdEOeiYzUHOddszWd+1sRpsXN2rfoOaYb29Z0nPJet+0
-sNM3pitmmxXfhnS1C3STSvqZf8ennDo9Lb9g6+OzYGp4lNQGI4mEYdn97zWZ
-dqutmJOfiWvD99ofP5KEZyl+ivGxWht2iARN7BCt8X8sdYVoniZ8pfWSOC+N
-vifVB6XIPCe49+Ktl8j1udY/drRXqnoLztQNw+XdTGFP9MEFP81WQk2rLpee
-4eWdzzlfi/rxbjcNquC4ejphRU/CUCjSv+X6Or0k2l3z3ttM4BcKNK7EpZEc
-yuW8D17AIFDDXZQrVdWKOK/DrOkLM0dNOW1d9iS4qYGQy5AoztkTtYT/kej/
-zqAuwZqjtYJuGAteKMqR1fHuDRiCPFyxaDv00YCweKS3GyHfVutaoOmNCy6Q
-IChVMIIBufq/GuHW6sZngqLdV+tRmU+G8auitvCKD0KD2HowXE4E1NzxdxZ1
-wo9sqraB1soC7OtsZPhuIbfwX3s5H40l31JJKYqbtZSYSgHzDT9TNMlVSbLl
-k2K9I7vrFJ5qjp3MZgi959pmfXKsKFv9A4k2hNRNSGWd5VIrx4ybA0D5Jo4l
-ZyGKGQGrjiy85oQPk8HeHACNr65Rgoc+Fu8i7ltx/rps85xlArY/m4fRC72P
-97jSFhasmWi7xcfdSPJPWfvXkloozLpRl1ZEva1NG3Vxb7NW72BFQ9Cthg8E
-FWlJkErF2rD6RvMKcL5VgPTQxRQaTV6NixX4sO3ebajb/nBHGcf0e2H81lcP
-p4+rqIu6cxxOz/jEp5M6KK167WLTaE8ul1uDL6+CPEiD4ufzFKauiqtgW4Uq
-CAWJGmEsxOQll9wr27J7LIpH5pRcwcMRtxwmjp5Zx/qOGOs2z+4k59w2b2rw
-RV6+V0N4zLNUsgxsqldLdtdvhkCSjXnhYmCQKkh7+NhMkB+IXCKm/EUNIKp8
-fxAfv7yAm7uOBwNkVvp5Rw5q+4HJxg7Riy1aMTHPO0gMDSSwf75BvfIPADlv
-wqAcX8sIEksw4pN38dmLC+rji8KcuyYsekdIsmGu8OKPjk4TyQ5DdLDJazRB
-SLbzo1NkniIkqB8P9plan4uBDiOgf9uIQwrPq2Y4UmvHB9SMZBO5CGfb7dr2
-8WB49APB0ejyLH95+oIoB1J7BmlDMJbW8JTe5ZXYvyRRBHNukLqRjrCZNGDa
-RLeI2/Ko2xagRToIsnZMR5tMVG2Edvks5WfFepvbZl88IHPkgrITzffcioP1
-gXhgwE18dV8kEi/zcI6jCSXSAJFKUUJsb3QSB68ETiwmlWddMpFDQymtiPNA
-E/UlTOnXClCczie+4nwYdxgZMDbu0FGMTxr3nfJXuG0cflE0nqQJodFkf2//
-SbK334k+cUANd3du7uMLuwIWp7dtAK5aAvokDTX+lpOe7fSkT0D3h99SBFKU
-8gJA/jAePH26v/fkYHC4xx8C7tsPn+qHAP/U9OHhXvbsYG8vyfa/HSUHg8lB
-kj4dPEkODp48OTw8oG/2BtL0vcx/NBjvTx5nB8nNYfokefrs271kNJ5kyc3e
-YP/xweETfNLRblWvoLduMgKa16hVhxwkTFWegb6BKDAZvCl0hSnfpgmtynBx
-MPrr9Kfbs5sff0xfJ/+Yfvih/OvL9O311YeqPD44rfZ+GFQvRy/uj6dTadGW
-x/IaeX2c7qX7v15/KK4P53vvnr26ev78zfM3x6//9vz99GkyTX5aZvn3f5kf
-Pjmwa2nCzwKvJC2wvbgXoTA9nz89ezl4U8x4JmwDdwbhJhFq4etZo7HID3GF
-mG13RRK08cSTNp548rU8sf8v4AkbnidxdAFDfBlf/mIW68GY8n6/n+xxYPkm
-Fzby1vTR/bjbGJxkivoibX/YmrnNiMkkth5pavRWxR8DTtiyty2d26Vw3/ux
-eFHqYkhNQvdi0kjuNJnZQw3SHgS5zTan92FupIHRmBq5AgBgiUm7bGfK1veQ
-tIoEsN8prNLBaH/8mFgBy4m/9txf+icUVsKWN4dJ+mT0NCEuHCTElzeJx5eD
-Tcbcllj5f7vI4kXeD9PMAS/+GwsdLtgXrTEUnqRc4WKalmXe32tZ5md7X7vM
-+/+CZW7mxIYC6It47ZeA9I8JZbttGWTk/w7Sb9Dxi6jPelcb3dvk/rMnX0v3
-x/8Cum/mGX815fcblD9o1in4HfT2KPcZSrOU3VUpm8ynZXKw30Lyx4MWkn87
-+FqSH/wLSN6etP3VZH/c+WWrwLpYD366eVv8uP+35fHh2T+evXr//T/ffHg8
-ef3t3fP0oHr368nT/D/qvfvz/zUOBdZh3G0tB2FPz69dzu3L85l1/Rx2OmxZ
-0MPBVy/o4b9gQRu59V+9kge6kvBbDeOP4hYIavhTQ5ottn3fQJfc/UeamJL9
-yaDD7yD34NNWbOYll3jVW4CehmzZ0XoOuNBsjLqUDYNcr+kcMc+xqQ0mfvOD
-a4H5XwD5lgoYD6Tc2zKzLp451/DjQxuwZ1LwrSvvLk+jh25G4JtDW1HqF9Z1
-cFj1M8Ud9MEvqfCgj35pmQd9fHuth19Ul5I6HerqbZa5yCsJUUUB0axcG6eR
-74eRW0NMtQ3G2Kib9mWbh5174lpG21LhwFjivOynz1SNiOzFcAz0xbaq/AI3
-puafmfIi4pYJzUuRNmB4byoXV3paxeOhy7I5CbNW/lLkWz2ITjdg0zwiuyWq
-sCW/RncBX7kh13c1smzadSdNuOVMXHCBn3n6c9RMhm3yaBxwYtSVYvPmj+bF
-epZnJPuS7kM7gJhgvdHhbqPDDfZtpL260wbfwkyz/DIzzUN50u1nSvDG506U
-/Tal51mo9NwMMuLyMUvzgy+BCLIlSBEfPR0/S2gH7Ce0J/YSb0/sP4DKQLHg
-PJHDwR/G/kOgvPHs421QIsI54Z0R3vWo6nG+d1enB/mI7Oj3kuOZmUzMpWWa
-8L6OB+ovuPBd9rUcjd8vinssmbhKt3pXxNDLIY7vK/VzI+MLmxGjmZbFammS
-NfLSS8dKZ3wTOzacDZe3odT5wtgFJO9vs9JeZLM2ipvNhDQbKb2YuC/Py4Ke
-1ZwLL1ks/kyy2EZ52ciUl80rTSCL/n993C3ovgABAA==
+H4sIAAAAAAAAA81963bbyLXm/3qKGvpHSwkhW7bkdst9+hxZltvqY1uKJXen
+p5PlgCREog0CDABKZtzOOg8xDzDPMo8yTzJ7f3vXBSApJ5n5MV652CBQl137
+fqskSUybt0V2ZAenH7Pxss2r0p5UZZt9bO1V9SErG3td1fZ53rR1Plq22cQe
+T7Oyzcf2p6r+cF1Ut83ApKNRnd3QID+dvb48tWtDDcw4bbNpVa+ObNNOzKQa
+l+mcZp3U6XWblFlZZvO0LJPbfN5kSTZukwcPTLMczfOmoXHa1YJePju9emHK
+5XyU1UdmQgMeGZrzkUnrLKW5L2nSOm9XA3NLK5vW1XLhVjQwH7IVPZ0cGWsT
+m/n1jWV9eMpfFVU6sfmEN9iu8DTV3d663crT5SRvbVuneWFMumxnVY2h6b/W
+Xi+LQrZ3MqsJcHla2jdui3ijqqdpmf8t5TXQvspJtshKntW+zZosrcezrMaL
+9EleHNk8a6//w0Npb5IZU1b1nL6/yXjety9Ovj7cPwx//Tr89Zvw1yf6128O
+Hz90f93ff8B/PUue7/EsegK8hA2Pm4dNsqirthpXxZExeXndW8Wjw0M38pPH
+3zxykxw83HejlbmbIk8A28SBm9+4vDh78eL0CHt3iIlzzexFXU2WY5zamX5h
+X9QEZj4ZIOnpTVavqjKzOzLM7kDGSetp1h7ZWdsumqP795tFfn2d7eXVfULD
+5n5BiNS0+jRJR9WyvV/RSDd5dnsfAwDV7HVaNBn9+/zi9M3V6avT16dXb3/u
+rvScTvEqK7J51tYre7nIxvl1PsYpb15KRR+07gO/ooY+bO5X9MOm+a0N+MZ/
+EsYmQrWiWk7sGxwGkd18QQheTu2LallOsIL4NJtx3rY45LwlYiPwdg674hkS
+wu6ySQHxpAUrcC9t+z2hU5BDpVdNkhCdjIhv0DvGXM3yxtL2lnNG80l2nZdZ
+s84pHNPZOT25anaHlkiHntIT3kFb2XaWgfGAUD0e5KV9vSza3F6umjab29Py
+Jq+rkqeiocACdk28XeDLJGJqa2S+Zy0vwRK63xCGmiafltlkSOyrXmKIia2z
+MbGUxlbXdLDNh4it0OOstum4rprGCJa3lUCGWM58viwVLWiWZyvZ4YSPS/jn
+2gaNQuU2b2fr3MuOi5RIiqHww+X5G/tTNhIw2p0ffrraNUKkQ4IdHUETY6XN
+ynRU0Dk0gFtjCcLEccqW/hvt1ETsDtuVnfiFOFgtm8ymBFYCDGA6Xo2LfGym
+dbqY2Z3nx9/vhkF5qjpb1MTvaCjAz3HBcU4rSktixLQ9+rjNDDa+BTgeZX46
+u9qlNTAcGU0a4g2Wj40emHk1yQoMOq5Xi7bCmui8F3U+z5lm+MCPbZnd2pdX
+Vxd2lqV8hNd5VkyGxqNpomg6tIzNQOIJcAnEsKhqEB2AkRZVOW0YdbKPLAT8
+6crQzZ5QyDyfTAri5/dIDLSexdG/79nXFS1MaJfI51/G+2vPJD992sDmP392
+ON7Yuhotm9ZLQkg20IVgSzsjoTqdfekIGMruFUNsmxDG/35xtUuAxm4AjIYZ
+7Thj8tC/WidgzNpyY/FDy3ZMZFbd+iU3NlozgT4dz2xFDxw12nFaFHY8IwRv
+Ilxxy038jmgTxj/FJhKhqQg9+AxfVrcZSYvhuvoADMiI59ESy6q16WRC2N4E
+sjHpeEzsuU1HeUHvE1z+s6xueUm3s8ouspoJl+motMJmw1jCesztLKXTSpmx
+0kyEhoQQeAYGRKt7m02XLOAmROkRauTlmHQm3n2xYrIrqhXDrSqrebVshLyJ
+GdBIZlzRWHlJYzgIxspLWtgRJEydg4KeV3NAtlkS3NPGEJyKdjYmDW1ItFSm
+5TgbAj+KaspEMSacy/66JI4RsZuhqFfMmUzEY3mBc+xlQiyMBUIyTz8wuHjA
+wIy2yZpYlFgnSoCEHcmAXetZZQ3emqYLO8ra24yOf8Mxx7Ovn6lOEWGlA/BT
+4chhUbpZOVZ6n84mnygn7J7rcaPzE4PCr0Ir25Wrz5+Hivqq8dI3azKP2F82
+gRAYZfaGQEwngOnBpuubbKKc3ijHIG4/z4iYyryZ82cOxbEvPVicAfh3h/Oa
+tGmWNSMEUxFxO6Ixmm5uL1sCEX/E51hnGa24xhEwpAhneLekENY8bLqghRCJ
+Z42IE4fsujOjYo2Ukf07T8KSEtAnLutPQZQuwg6CH44EooJYHRgnfTSASUTP
+8kaVs/xv2WSAUWlAfO/fEVShRV6xzPvjkAchrs94fL5sSW2z/31vYMxDmuRN
+RVSRMnVNIjgDCthwB6BYnCoexLt4ziIvP/RVEyViOjgWHKqTOAygk3gk826a
+juFSCpmCLEiTWRQZMYaA/TwrnX1Llh5ItqNjuVkgMEWlWCzrRdUABU6dlKxG
+jGtKQDRvVXh+0hmOFUsW7Z8+dVTyIM8EhWUY6HvZaDmdOoYxr8qc1skjyOnj
+7N2nXS0hwlUSXjIvq+Upnzif8PpJOH2RB23TOXHzJLsBNQoD5OckcvEWr84o
+9jLkBDbNmLSzOq+UPi7HZC3g0+PFgtQqBdAWbsf6N8TsFg0bCvauFdXQ7nz6
+xDa3/Ovz5136lrS1SFmDitPR0RTXGBD09SSdJjdpkYupISOcqfbGc4P+A8P1
+vNPrJoQ5NIwwrzx8KCMdl12ljG29k6ugc/GnbFIl8oJ+BCAW2WSa1dAk6+uU
+tIuIKzX8nbyQ+Bf4Y2hb11VRiDQm6WXJKmSEbvwh8EOiENLdJna0kn0B6F45
+6ilPYONu30Az5vmMfon9T7B6RW33Mpn6RJ3ghHSUNStmE4hXS/YqCce8meHE
+1949IRnK85BwLvLrjLXwLH6DdE3ChRt+hegZ3z9nrMnxb9n9B1rRLSTv4PW7
+y6vBUP7fvjnH39+e/uHd2dvT5/z3y5fHr175vxh94/Ll+btXz8Pfwpcn569f
+n755Lh/TU9t5ZAavj38eCI0Mzi+uzs7fHL8aMNNvO3ieiglBggpHRxIKjL8x
+RFRjgqOIxWcnF//rf+4fkHj8b29fnDzc3/+G2IP848n+1wf0j1s6I5mtKols
+5Z/g+iRcshQqFeRmuiCVpGiGzIYaUjlLQsc6I9r83S8MmT8f2W9H48X+wXf6
+gDfceehg1nkImK0/WftYgLjh0YZpPDQ7z3uQ7q73+OfOvx3co4ff/jtJk8wm
++0/+/TvTpxA6ADIe+UjIBJysHRbRBaTfkTliWo40TadNAarOnnLkRDxhi8Uy
+hJbmRGkD1iTWMZ9WLM5YyGJapq8xI4kl47sNRiwMI4zGwo2Wy9oxSeFGFR+W
+zRk7/SoIZ2bGz52BeywGrv0+GLgyl1i8gX16QxfA2sZHbxmhaCbmSALNYEpD
+YliQsupBEJl38HZZSc8h8OmTOgW9+QRwb/AMQA223sfR0yImWcu+ANZEwWZf
+gYu6813w3hKmJ7KT5/MlVHlW+QF2IiYYyGvHRZCgGZsMp+OV0qHgVNAZGBZk
+cfml0iK2GKRijwogRPCMA2sEC2bu7pHwqyYwaL+4lhkvLUtYbzxXZNmKYRtP
+tIDFSP8h9Yb0G7U5+FW/G5ZExMmTguzHwtievGDcBc8Xk6qziYo0kUXbxaq0
+3GKYyV5syqCdpey38pvMSa1h05WOmAZaVOKDYj1eHbGEL/KXz5/p8zaSQayT
+6HKOY+spFvqf7q3Lc6gy8l3kmjRXm22xbQ6LWMn5gjMCpA09ffNJ0766Z+2E
+7M7gzKZziXbYP4KnxT//PNiNJ193c8QzR0jAzsIZOznYtcPUzpKW9MtqnMN0
+kcOCdcErYHOtrgp8w28y4uiSsAC4f5JZteirGzd5Kl6wOxwsG/hr18XS5/Ox
+GRGbuWo4MssSo4C5PqNeW5mg9XWVp8glIkxoiwMFh/wWbEiYJEFVrbZgk1Ve
+w8zrjoXHhpA/agKXOjd5pMiTG/blTPDEviLjCYQ1FjVJPAY0/IJ5CMmEpqqb
+DYZtMBaA66feun/NLkhi2sz7xOOrcKG9EyCUiLeCuEhXWW2cG4Kh6uGEnwBY
+fpyKeYAx8AtB8O9//zuta5yTwVe35vfJP/3n9+Y3Z0C/wmw7jtx27dY/v/FH
+/NnVke1S046EW47u328n93Ga9z/uDuJvLuQboZ+76YA/+pe2tHXZW364+Zch
+x+aKwi0I7ePOAe/aX2DJcdjozwoF+oygcBVkL1uUHTf5PCN7sgtu+SNKzH3V
+WshUaWbskti02//PYXe+EIF2ZGNdgxDQaxbCHXb9EgCGAQiNNFu2EUQlYadB
+BXdqZBsO/m+gQHRlPh3Ze9f5NAGtNRIM/DcfCXfU35GSQIVm8FmN99gDuHRO
+R+WZEr+wiF8MlW809oefrjTqY8SJ7f1E/IuOp4wj0vmGaiwKE2xUzVZ9Am7h
+Yik6QCTqRBPucefrXNzf9+51RP5FlTNj/nQvkvmkAvFD2izphkwIPqzTfNkv
+4GMO9JIJgsi7pyJHB438w7mPr9jBh5zwfZHySGSfWNhkdXZNOjZtV4TwcsTx
+KZHBYV80ezUXVsoc5iuG0xWHa2irulDxmcOJAGsRsw9InxrIsVg1zjgi5rfH
+qsY6FL0PxitdZ88jvWt3L94gNjHK1LsUwIdYl+oUPY1CFZyN+3HDOixLi2lV
+08tzu9MBJT2PQLmLZdC4tOyxDuw/DAZg1tMrZdKfSDSDBMG85+kH8czDv6Ma
+sRCpRm2m8Jjx6a8F4dzyco7q1DV7wn3QrYdQRgM2a6IQ877VeXHuzk9Li5C/
+PuOw91qA6Ii5xrespgVRdPwdvbm2THmTwVx3tRi2SSffdXhI5MXynARLfClb
+vWzTMWslzDoEkhtVUNVA2R19Q3YamOSCtIcvqHtDp1gp9go/IEWjNQGwgs5X
+YAq0KYkIdAyy4EkXUWWqUnVetlaI9uAZphU+9aSTM/PxWTCk0cl4CAE5TRYO
+d1AsY/ie6KYE0iwXOw5HsKNntqsjwJwXE9tHAa40NCra0e6R/dG9qse4wRBk
+BORz7NhAUFM6Wyd791r3SVi70CyeL4B9T7z9DIedbkSI1vZWDXDBGMVNFxa6
+FSPd8pRjWLbqCnEeAvbmO3lJKxO2lU1o3GNIRBE1CqqJeFUlMgYRKVEEfA+D
+b5vD4YWwsE/3Ii+ysPstHzBmbkxWiKWV5lywayh6+ZIeppCi9MFl+OCQAKl5
+COCSxIgMvYBcGNLh7SVtMi3UPGZAZ3aUNtnjg2VdJISWJGAn5i9Ce3uLdMU0
+tde4yf6ibHrXNpVYdojPjYl1ETt27CcvTWoRVs06HuubtFhmIi3BV5WaP937
+tSJsUK+1IHRfjGEvrP2mylSDEPQMWdnarw2Z0p/ozMCvOaXv8uHh48GQn7Sr
+BT/R/Do6ld//etvKTywn6SeJF6YJ0VaST5L9h48G5nOXOcmKlC35hepmTj+m
+bPkxZ6Lp2V/hHJ4a8J/kU/agWg/TvtQgzOPfHFPYo8Vh95vEzHYJY+2Zt0DF
+csMgzXKBUAFg4pHmCZCGVweY0cc4KuscuHy4g5Ks0AG9drmac6IWm3huHWTr
+Z3vTvaF9ycMyOF9ePnpywP8+3H+42xmH9wg/J3DUhb3Txo3KDhoHGsm6pImT
+OlsQJTqXEB1jD7JeI8ggN/snzM8mElhb5s1MordWJJ1IWFYYOb+yGcIDSu/6
+gG1QzMY+XoBYlcUXkXIFqLE+SMi04eh7+pXTwlz2ReDqWBgP31VW/Hl9jfN6
+px4D5Vs1jPOiqj7Y5UI5NRBj3HaGJogG3Ot5EJkyCRAnkklFhHnbJqJgR3Sp
+XMGRY2NHlUtLStjvQYOxpO3o4qqld5IE+olbd3pisbh7LPnDoLLMvndmw7wd
+h69DFZd0RdyKU1dWMDONIe21d3SXLfulz+t3b88Q8qb/d8e4cmcnPkR1axmr
+KsE2RTn3usVINIngkfPZn6z/el4HufIX7y34FvI3Efn73f1vCeSz7/4ydLqo
+W9SgWY6cJq4Ot1j15Qh3mTidPFoizEXW2YU0eL/NeJZxUMDROXH1S/rhVSPe
+6ndv3xy9e8crDmYRq+wkPrcDkzN1SGKkiJF3gcwnyvYRG6vifs8XOY280+y6
+nQiEn2XjlFcKZoLkDGYtQEgExCSyz4DJmiadakadGL7q5BLLZUDPelZLJG68
++0zoTP330I3yTFKEiFfQI9DTKlrgGWcDLDj5M4e5lbOzIuUkUnr+O/rP72As
+smMSBiKdQ5EzOv7ud0cIw7FZoLoh0FV4Vil6mKp78FWrwC2ZotRe0E05Om29
+0xB4ZtcMMWTqbNInvRbpNFWXW8G4eZuyZpa3TmfSYHPFOsEsLa7diQmN7PmN
+SwCJd65fhEz3TZvnH1ux5OiPxISKVUdRc1MrlqbXzJRT+2sF5deqlhgiLZq6
+wSrmBmC5nUR6cFi8eJx5Vtbl++uds3o8ilRK4mlASqdAR8fkPZY+SB9ZAG5Z
+jmmlpZ476EYXy+ckKB/hqMBA3v7TLwPPOzJRUPZo7+py5KUM9M3N70kC0X31
+FP3pz5y8eMo5hU70WGIP4w+KVECznNgIR4eDFxtx5MbxNGwA4CQmKUk4JEdh
+u/Bx7Ya8DwkIclwiRAwbxq5YiGOERQFhDJhOg1OCxwuozCl/SHlCliuNEXsG
+9GvMdPYcix3Qs4HXjvgsgM6c8eK/B222cFXXLnjEw9VLjlOmI3bespbN0XXd
+jiMk5ho0Ah2tEj699L//638wOXWtQUdFsgbRNKznTrpwBgkBlRSlHtt9s5zT
+UY2f09Z1L20+J6AS25rlqlZiOcQ9QacTViGdxHfhz9QnO000IDAUQ4CWRXPq
+slixKYg4+XBAFK1wFGST0fhyApoUJC90w6qjbJqywM8+9tW89W3QO7l63bCj
+SDps0IGVs0NL5COkczrk/9k/tPO8RBBdmAa2wxoYaVScGq17WJCtTEdWTjjX
+dpZzXqBTOySWmZLxAT/DuKjGnM7TfCAs0Rg6R0uAHbRQNdw7ysqgHF0P7M4b
+AsuzjMbLdlUgSXqVdyoB8Uex5FPo9k+n8WEmZCVxFDpjLTorVmZJ5gKOmmM0
+tJpf23yjqIbKMy2qEUJMyzL/6zLr+e1i1qbCAfDCscaCltYOLUEVGmhlXIUD
+dfYy52CRtUhWFqxTFY0N+RTMnvN7eVRii7TegUj8xot8WYIEmKMl7sjZ4PAm
+GXufmeP3lulf5xwsFHsdf+/IyvtLA0dgFvgWUpKZrXpVf6WhjVrftzMyanWZ
+M7bdC8KOCYkBjls1yKH1PpUIi8GNGL/YrcK0QaYM0XveBH+KnEHJGabMeDic
+OFGOY4Jweyqk5T9PR2tfO6GScQHTGJLVH7QmSDq+wLmMmerg696MT/eYeLuW
+QlDIVQdHJsddKj6pRLdiN7nEmy4SerEdHS1kDYrcmAgK9fTiAEiZitQinwyj
+YPXQ9JIVqIlgcMBK5kHZ+D0h3zba4K1qWrpLDoRRGK1RU7E4x836dFqVRiG9
+XXWWgfKJ92RlMeMS54QmFWbvm/Q6a1ecMjZOizHyfN9PKtZsgZHEOrIjAa3j
+HCyeWJOW6BGdLNfkTezAbWxgCfFmAkpCFzxhwN1U+QQWZFEgRS8ISXln53hM
+OOE4VJ1xIjuk12jlgMi1bwAiEUwPfsdO728ASE4ovYhkb6TIQP2PMjyYLOPY
+n1NFMmH0/jyxUqY+782Av5VGusmrZeOdq5nz3x6XNpsvWFPB2ogIJTmac1Js
+XVW6NIChrPpriNCTrSfVzNjwcJqJHyLaLBB1TrPNUs6PSJEEIPF1Up745Ikz
+DCAwnoIOI3GHAHfmIvJd17OwEE7X8uKQNbKsuNZU3AoKGtAKyhnL9j6zA+Zs
+5ADPOedXAl4Ird3jJGBNcKEHX2AELrnYv99du0uyNVECmovfMvA5B5UOMaO1
+q50rKcjYHsoxF+85zrudkXQTFfhdb6LwlBiPyU7ElCRU2gG/l3iX19Ga1zTh
+FwZB7x40szR5ePj4qDwY/WH68+z19U8/pa+Sv04//lj/4UV6/qf3Vx+b+uTg
+rHnw437zYvT89mQ6HWhdEH2PdUWuvsBQAssiwGb1mFaiKO5Cdqz6HL85tm9A
+62euQJWg+5JHPfajvgXd1ivPfnTRA7+DR08OBvr8cP8h1nenZ9GPwHRDRxeF
+AP1PJISKDOn3NHdVstUTbVRIHn7BybbZ2JlI6jbnf3XhBKUzSz84hnb58pin
+dPt7/fxwiGf7rgALnytEwe+4ZpQ19RsMQXSb3tpq3GZts44lRA+Ejv8yugla
+e3zrFe2plgQVzkOnk7jNaOnQfeCls0ZNGohl/UcgSQ7FdZd6PmK9RTmgj8FX
+eCoVA/AzJU5YM5SEkiW4dZfXbu34jNqHWmiwLDnG14pf0E2to+NQ8mlZibk0
+Z5VZBRM8mV40Nb4sacLGK7iYBu2HUd0sf8PCr4lxkjlJ3WQun43WpJERIeMB
+4cOeN4XJqq/m71ENOdj1UnLDQkw3jDfh3EaoaX41KKGoII5gr45QNVpO6Hxg
+Jtxkqsc2+d+yocthQ+iGhkEYyItFWXF1jSSzAVvz7vRCcrTlcenLgwffPKaz
+atnR7RRgHs2QRgj5SusmARfppl8Y8NAgc7PZQKn6sujFHa0YQ+KYjQwDTZN+
+gbEldTAOG+jYmk1oiONj3ufTWxwqkty9XsK97VKvNUfjxJXqsEDTSE1fSOWx
+mdvxdysa9KNMnO5wtMVxIg6WMUkqrocRpsr2+93vOyUPo5MdemT3v/764YPH
+B/uHD4ZOKfAPv9aHrOvQuIeHD7InBw8eJNnDb0bJwf7kIEm/3n+cHBw8fnx4
+eEC/PNinofmLWw15PRjtjx9OHiXZwfVh8vjrJ98k6Wg8SbLrB/sPHx0c8pOB
+zqs6I33FRh2Zk+Xkfcv2fNBV2To6sr/8Webw7OnoiwJxozzEkI7HxoO8Okkf
+pA9/ff+xen84f/DuycurZ8/ePHtz8uqPzz5Mv06myc+LLP/+h/nh44N+BI87
+U3B3DRfD66DFhZ52FMi7Z+Pkgytfb/PpXlxuo3mO/ewM/eoFMw1NdOqmmLvC
+zDYuUwqf98uwjdgn+/sPPn/eUnPtuKE4wdTTEI+h2kIe7Dsumt8WJTaxue5D
+zDymDKPxMhWPXKv4bC2iTEjRspOMY2WtSAsyffKK7J7BHvHS8SxlH7lkUx27
+vJhG+wGkW3NiXHJGc3duTD9vI66g97ksmh0j9G2+P72y99NFrtSYwMOJ47i/
+v7dvXlZNe2T1NyxlLyJksyFRJlv9MBt9P8739vY4+rK3t77czktsldBLa3kx
+Ok0nL8al7sA44fMUrPP5MX33qKRHIJsUZYQ+FBebzArzofFfb4WvYFUBPFZm
+rAczGcKhYzg3YCVn6bDgi4inGpBPl9KwRFY7Zxpnfn5pbex2ao3oEoRNZHlI
+srRGary3aaHqHoaesPAgMfLpU2yaAO/PyIosVw5G/OU1+kF0818YG/1qI++Q
+eHsII2oPX6UlLfhwRqnpu6JdxWpRODBMnO/Pu8naqBzV6IA6TrerhE+HAgNZ
+D/h81XDboYYXKFYq8l7Y9P7RlzfC7OvUO4IDnmvTGE3x5iOkk7urWEg94jgJ
+GH6xu4121cFZlwYFMSMqBADIbNVlshvfySHdUBys6TTqMiUI9RqWEBCGBh1B
+AA6OK1X13ZW/3vT3RTkrAy3XmTFxtrwr08pq5xVnfgh/rz+l1oijwBiGeQAx
+/IChI8KUVdy2a6IjepDlwiJL04mL6WF3McM5kAWl8pKpWNSl6KzfciRD6TDC
+Fb9dTdunsbjWaYPBpqs23dyd3u6aNlu4MvUrQXz7zvsrjyQGA4+qeJ2cIaxe
+6V6SmlYAIBcBNRc7LtTe9SJCGkEZGiqE8LlSaQBsft33pu46fqChnCgNVard
+sVbn+ZUS8pAo61YvnIEjLkiAc66hj8hBGWdH0tGp7xgjbtu0IckU9GBCaFAT
+plxekDB2cU8iPBczgeDlwQCy2x3Fochh5rFVPwhY5dDHSM49aiThU/I+toBs
+u4GJxjxOS8glpkxm4Z1w4oS+q2xOWk9a2HOlWsWPKBDFxA3YxRNp1q51CUlT
+hKPUXdAPZamh7jotYIBFwc1BMATxA5LLyzqEfCTg01ZFhuIXuxMVmx7ZRw+I
++OijCWdH8ABXchhDMGJwQFnqkf2L/GWPFmO/Jf0oLyb4u9QcYK73PNd7P9df
+XGTPT661M2I+heVhhK6S+JTjND5hdbokAU1CFO1IcuJ2HGoiSDv+KKcEX1M+
+5zLs+UI6/XBU7qT7roQu8nla54RCUajBissg69XY7+hZZQ7/15yQu+LDHElH
+irCCzXhFyIveZuoVBwPnzP+hJ/QtOHbAHhGRVtDfXoQ6X8YI7p0TcdFIZjkH
+laaNki0xSgny6qd1qESzftUIh9CFS12rtFRqsQoJyt9BB4doxBDqIzkiI7lr
+Y1rxRSw4fcIRq8IhXGTF19Qp6mMmWPULAcHdJFic2muSZj5eZSXywrx+li8Q
+7EKQy9fnY6mRs4N4GCl5XBbqavFYqpPKxn4tuEuyBS/ilhV2wo5maPoyRXej
+6MR9PNKP+XxJqgYfQStmEXt2UP0/Jw2wS4j7ZAY/IDQiJUH5ERgaQr1o2sLt
+VLxYxsEYHzr0gj9i5iGfKzqee1GaLstKyfD9MfZ2f7rX0TBF7sYvXDh9tF80
+oDy3CXK37Yjabpqs6fjYIWj7KeGELlqnsV0jJ7zgc0pVA4pSdAVX1VcivqWQ
+ZsgAI+7ArIj17NiSFKH3o8ub0ugYMnWddRESLOlo+qmdKg3WBkCxxqYBmHdI
+Mqs0o5CsFdRh2mY9t1U5wY8hsUtKataGjjhAaj+U1S2ZAdBtBDDd5E6tbY3c
+bL2y4kPEl2kp2U1cpdPNIRXNBcsJqpg7QSFufwQ9uNO5Ci4f7j2k6R5vAKEr
+h9k2JRM6GDE7PIUN3BCCT7buaosvH5a153Q021cNhvK4ShuIu5TFY9KrH7Q1
+UdTkw3ftUa//OKtbQf4sHpk1qKE9P7m8EOQlrqG5lzLFaMmNTexywaFX5DN+
+3cOEzUiGJEz16PRztVVtWK8IetIbOqqiisfbkNNJ34vi1yufDrjaqRf5pr+H
+kPjYSX5zuV1fSSKX74YHFS+kC0qSAgbJwYugfw41galZXhPcc4ghxSsMEA2+
+liGWNsjz0IDuU7XKfdGMHJXYN5p+59KhvAIjqTHdsCJpu0uOYPLnP7m0JJ/A
+pr6w2FwadnMAJSAb9i7IG9qjAAYE3/0Hex34IoKr0XgXU/Ziw9EQ4rqQGfv7
+3c+hjHbTgEqfZ0TMRCaX5LVG9OedrrQMHnP2zjWzqiD+HElDLzsVtiEZalc5
+5J3TiqtdJu7I2LKyc4ndEFYEzdemTDAhVbqDDF7RJq1uCC1EVNieBsu0uP/Q
+A0qcImpqa/RoB6rVMHJaDzVzhzNRjJYLNS4B8zYrikTsah6bRMqFitGejSp8
+tN/pib8hMXEmicGSDYl4voTvurW2ouJJDZLXILCioEXEpboBDWkaVXHXxLm4
+obZbTS7aY5QQ/AtFNZ12Oov4bmSkGtc1PXa50yaK/kgEnl03oESPYn23lW9W
+B/+sU+FxtE4dzKPwNLenKaoGhCr6zlpZnbjbSCNi3tkpmAwpdrEDLqR++niU
+mMRgkhjg4MEju/Oiqkf5hIh7ly19/p4ldK5ZEuhi573lrDvhsSg6Osi+2XlX
+hs53bhxfW7peciGb0ZC/rIv41qiarPrFh6mlLXDuo81wJspKoCUjJ8KEnAjR
+0v2RbEYVxNavYteftOgN8XUFp/oHAWKfWSjJZf2zMdfaDudet0j9zPcd+3Rv
+rdOYOgrVbRz7GIhsQt+cDgGBG7ASnqPDRGeHSLasmjaZVaTGlWmxIosIgfhA
+fTH3i7rO9RuE8pnnrhuisheeetFJ2TfVQo0h74nsBnicVJpzrid3EA1nw9RA
+YDdkWczKikhxtUlL0nKMqKMQUy0RO2cOcCJKYzZ04OD4XI7AnCvfGHY6Bwo4
+GnZ6Gbi0ZS1xL0vXuyXXCEvs0ORdc/VDXM18J5PrSiW1VWRwtUCOow023OSd
+W6Me2XP4MnwlgEORYPGIJwccdF5NRE1Fp0Mkw6qJ0XUT6SK1sk57PZPJW7Wx
+74KElGPNGcdKMnFAp9w2sWqrUl3KoZGsFZ85rVc69Lvi06r6sFyw6sx7OHu+
+vgaXPpN5fakW7T8tROG5lvwvXQUr4XAuuprKA9SabEqo6sylXGVD41JRwKtg
+RKTctdNPiAQ1mPXSxtEpmVGZATJbtKcwQf91Rgoja+uZ6M7rqxhlHvRiV3Dj
+F9fSuZ/4boKTXfvyskOe25IJYuYkcOhNzsVYNlowZt1lCOIXcT6LxsVh1QQK
+bW4b9/64837c441WMl2S3FfPFEwq7vcPHYCMd+7WSqDTNjfd3IJWfkvHiChI
+nyCZJ5ugg8PrlL1NvvkwaXLys365K43FpGNbz8gyrjmXOng7OZ+u6AHd84FI
+oiXtcZ9E4qNkkeaN6xhLZ/qRmDM3z0pbrrRHdXiYGCkc3c5N3udTjbqn2R+I
+J1ShoHhUY2hnArQt52BqCQVoeRUoWdHHBGKUZP12lq0iBHX8gee64poAYiT5
+QrqK3jGZeymLXIpSAZAWPAstVmMk6wEj7U2aFdfJMSFSjR9fsTfJeXk4OTFJ
+3W9J4X9z8o+xIXrJZVT5trJOi3E5x1LMIhWQt1JxwwXxLqsnygDutMlAQC10
+yGCma8YRBrC610NCUsCLiaJQ6FmnuKQrcIY2/0tjQU5RSOOQFdSGXLp1Ewdl
+voARNR1sQ/cDYUW+vwlm6JyBb39VjWE9TKSJora/1M+QsqdtgKQLUNOLjrSS
+yE1DST6pCzG7EQQWpOC0M84fWUWbaqWQI2hHQvcgS+JaTKesRykL99WuvpCp
+XX/ZqG3vW5J0KsVC5qy+Nqor+CBCEaeJFBnBzvNuX7wLIj0W5k3OOc5yCqLI
++EBa6scVf4hvR6M46MMEvhP2REWcoDPkOFc70g4IZqEYKHgle836tL+VfE4r
+WBSkIeLsuTdsaN5qp5yeiUbqR6hCwEdI2UTTeNdXVlFYuJTYYtwmX/5RSw84
+ddZ6vhSAG08SSS8u4eyJLWFJmwWX7Qkunko6WITT6kx1rG3dJB4MBarTsEi6
+uZVwepelK4JwzckbzR/321De5O2P2LvsdO8t/XRctXDcUkf8cOxfXM8H2tTT
+YFvvAqM6cAgndmuTe8U13cJaE80UBcG7vVGc9z6qvCI116jk2z7DBvdnx9X5
+BTen3WkQOCM76/GmHJJdMeLvMghxh8H1xlXEK7jD2JfgdbHyLCO2+o23+nkp
+m1yybG1E4RsEBIp8VKe1u5TEB7m8Vm8lPfbO5gJvpQjrGNoAsyBtp6B46Izd
+ZgZVuFva1/TcS4dJ7KhqKxMK9bRCLyr7Ev2j6dRxusoViXE2Rl8lWbAsXfF5
+KD0nOyQNjbvwW2h59Myg+js+AeIL8tuJmzTy5LkLZ2qPgrT+OE9WSrXR3Lmy
+cNgxqBgpGA1XWewxvFqLoYb8l8kkV9aqu1OOB7tA9mPiPhSdXBtZhGYvQL9K
+g32OiLTk63T7b6nc154w10UK95JUmFRQSv1qtqFfZJCNORDHnJRBxVpBgto5
+qexRty8390BsTod1mVEbC+xceZ1rw6adRidLaReZxXbVppAr30iTlkleJjRu
+8hr31nCQTqHa1WewHrZQXI6mtMfzdkanVQ9ZsHhPytxFml29uoRKxv9PwrGU
+SRrnd0dFaLdJibmj1emXWjANTWgm702hPNQuxhFdK16v1+IbDPKl0QTVg4f7
+0R0ErA8WsAVwMxfbnGVGBJNLCMRboYrOE0LJEj1zE8lHl4uLHF6LNvjq8j7g
+shMW7VpZKWfhGm1Wqj5Id2E1OaCvJyws7nPjqp1e070wBm610DTT+EIc6z2O
+ztmnLC6R7lV3Ny/td7Pyog93agDBWNkJZpn6fDdKY6Q0eO0dF4U5UwsUSCxq
+mpmIpUi4giiGlj2VC220aMj1hpDCBL4OagpjiEwJw9Y1gL4lxZ/lBZh2UsBC
+8tpWzfUUUr6BUn3JKCS5tDOrlpJVN0lXjWR0zEmRm7GvICHg+z3GvVLgPIbC
+8DKtJ7fMIL2JTxY3yu13Xl6+bnYNwnms4BIlSy4x7s9joKmja693oUCvkKlO
+F1poEkKG/Mk7Lpxulqy+MJkG8A/XVQHN/GRprdGO2NZCh0IEWJplpg0JXFSY
+kyw4WIOXFmleO0sp1tHSteGkE0kntVB976q8qk4URUHrDEsVL7fcWsJuLV/0
+z05QOQET8fNuChgXIsULC8mjxcqHhWl9A7Px0hOUZqjfBhB5AdvS9fc5dtm2
+a5YpcZGqFSTvRB5CLN7XyffCOOrI7GWXIr0hClho1IV4nbvfyucbw9E08bZZ
+o2ayF3EFaZpiMqdqKge24O6GER1v1Wnr6wM9r4UCQWaqGAkJRhaGgh/yMlu3
+VDb52Yz9kqdtk8FywsnHSdet+NqBIl9fEQs+erFRNUARP3UO9HFIU+LRz5ct
+ZwONfG+eI5SxiefIJeBKvYB6XFVZ9w4h5K/DalJzgAS+0KffzIL9PXWp+PYc
+OUjoPCRC0pg7wjTKZpdt6l1qBEuaouRKLbODG5g+5nO0VrD7c0lz4QHpY5Zd
+NR2641i4uIUbpXHmEaGlidBSMos+qtw93/nRZUf/6CLU4ldGMbOmOhmkMUnO
+kiR1u8ata7lpTyXhe7UAhTczdK/gHGNNj+Oui84BvUE5U3zixNqVhacAOjeI
+QATZ8cWZ9uEmhdYF+EJJG0Dsu/w0sv+YLD3GmijNGU6+LSfji/BuU6lfI5om
+ycKUT78uS+VKiJhpN7SQAy73darf1jn9uCH1sk7HK2W4MKOcDSKpjjvQ5YcS
+298VmLps1OASPAn5oN1kSxAFEgO5DtstK2RX/rqcTKVqbWtNHQTuqhzP6qpE
+RSCan7idqzfuzdXFblyDi9OG0PhC1qq5I2vVCCvoOW7i7mHar0e22izSqPxE
+PNVO3IpDMmIe8SYQ9fLtAYllTjnOLG1VuqtlLIqm10ShWAyHdEUnyfwFOuIs
+cRBB+sCGLF6xBgIoDaGNuDkKJrKWKIbb3q23jJ5yOVRViqSeA1/dqtVJ2Mcb
+SR5gAdRP/WdE4Xc1f8RsXGkvZYLsY5844YpjRSr2SsS4do3TGAmZECyRJFnn
+GMRJzXuptXBTFHyX71rZMFDcaFis2wSU61m343Ww4SWhXZLZkY0aslQsF3Rr
+CGDPhhu4FV2kUTiXgayl5vqgutwxqrcmaVMcAgYdl4hc4xo1XM3+iZJaeDhN
+VKdLAhCluhERRh+yxhcX3VbX5tBKNa04kUhtqMhmW6vihg/pnijJ4/XgluvQ
+cPpxgVQK3zNIDrNEIYrkY0vSAPSK49jQYTfPDnLQtAOZcLmePeNUOP5ar+aE
+330hZ7oTcm92o/wSXKDrc2jh7U4C+/3HuGsUNPHXxxGWhMwU2ZL486Ven4aJ
+6u1dytiOmuiTTZczWhcq4KBvKGWVW7l8Uaq75a0WD7ZXE9z1QCJ8IjxD9i2M
+nIpsuQxXhES9VPX1gntoLeWKHg6188UdF1ndOP1DMzK1giOk0OxcnJ3tBiR4
+nZdEU38LJVttmsyjZ5+3inl9K9OQQ5jBlfY5vNozSiWuo8xa8/fokpENPerW
+et7sdnrSQOxzHndaTpfsa4iRbK9fKc6ZeKDXnY2Ewx+jTaSw7SXxL8OKYSk6
+7WxJXC5hbwfgqkiC4HLG1CQhfhoTbgyf+JEWxt0FZUmhzDYSLTDZx45ZO+Hh
+zGbYqNdeUzJw3+EY2Tga7XDWoDeI49yL2GRO8VmiJgbf06etmw3CMyFdKWja
+rJ7UUE+468I2Xm1c7JpYMcgGxlsLhyq26ro6qrXdv0lctx1Zmhtr8Z6KieTu
+yvFdQZGHI77+TtLYi2XhKD50jhGS31m74YkxW0lccXnXrHkbXL1qsQqate5N
+rPDgZBVgGxfGGrLhOs4CZLnVD18SFCVaSNaEqIAIE5K9bZDr5cdzK435lqYl
+8WBaaoCGLxtEwWvmOvaKm1Jptxd/21R8k6C6tBpt5VS7phLdgJ0FD0OLK+Mq
+z8IEzcB9veqFyHhxxJKxCu7BwS1Ioht6jLlcjtr4x26WP1/h7BKPonbfnGNa
+kuXm7kbZ+OMpl6BDserAhl94Msrbp1FmUSptoF2BHMIeIe9cKyKM7dZEDDXf
+Dl/49B8C3FoVvJ4ddwXcUAjfKYG/3JyIwotm9sLL2ZLb4rNaXJtKd8Jsz7EU
+AtNSAb4+usDsYukiP70ObUe2gzXGHIdDVBejXPaBPrcOVXBt29qLIXK0fgVz
+0OTiW3V9lbrePRt6+UKnQO+AQIyRyOIFvE6nNIWYzzvNrm7V2hfcxtFz6/iX
+1zxLWxF9XvM7wE8+yPCOEYEsl1/PWa3xdz9Xkk2vLXSulzUEWm9NJ7Oau5IT
+Br7JypIz3vjuhKy9/o/S/XtvksnBIeS0ZGc7viTz7PwN04WErwBWyBR9QdZ3
+DPa+ZSqy5Ui+TjPrhQPePDu9egHOEXe9QP+KDgPh9hf4LYk5xud/ka90Wlw4
+zvJyxYoP7ktgFz+p8Yi0IJSxw6vb1XVxnyvfy2pgNvIeedPxl7V2AURzKDTh
+H2lWgg/w+7KXyumu8uwRwtD27t7t91LvQU50gv8nkNN8kryU9j+96yRk+i/x
+5d/kPYGj+8fzoGbxM0GVE48q9Oytv0foN/PbUZIkR/jf6K9HfA3VbT6hl52Z
+pjcUouriNyAb/R/rS6GD5GfcXuX0SfpZrIv7qAmHDLnzQ+Kt9ItWP0odeaR0
+3vmp0/H5LegQ0KFf6hP33eZ2dzKCMwvoRb3I/J8eghH+t+jSLGnQ1V34mnL5
+G7qEIFdaH7oOIVuwEBdv0RGhOpUViHfsckc/pU/3iIkn6K30mYYVnplN/m0A
+R7a/sMtJGpds1SA+HJpS3WS+RxO9MxevAuzdWXVrYm3wzlsIiatrX8tea0h/
+w65P5GSXzGjEFesQrpLazbo8xJ105JfLbEVys/8miveKQelznHGxsuG2oK5s
+sYMwGriAOyxOriKexK54di8T25rgcvZNMDyDW2jNm8ayTG5HUoJBVC8vb4gX
+gC+M0vLDV43xYQf0nHZpW52sS77nlfvvpj59cKwd3t3XLuMrL0Nblq4LywWj
+QsVvXO2rHhJ2Vfk7ciX9NHj1Utz6Kc45XGyBXr3xlrUbRmhfrFEqhkQUN9mT
+zjydC2EBDdd6h2S23g20T2ZwVbfEJfPKviXzbfcIOcrc5Rh4lDx4sC8FqzU3
+q5LKLu4x4ftyxQNrYy62AyUZ3HWFlQKDv2XvF26293ipt0g5gcYNFzJsd/2S
+n9GST+S83uLtDSt+ePeKe7O47mMYtL9snMl7+e29fNhf9GbIPqRl+sqLDWt8
+FNbo4Dz06/8H4RyVdnSXLTbTe+DF++itsLxH0dWSG1Z3sLa6R//gmmI9NF6S
+3kgpa+q2GQMb8I2aNjAKZQ9eNA4+u+u8GvaYS4MU7UflkXZnM8rxvY8eTXY2
+nS/j2i/xzv5sN/75pYdHAiD586fNn7g/96NX7c1db96ENz3i7Gw53t141O4O
+zPrI227fXJ/xwKVq6OndNc+Gg00m6fSOw6Wjw3my0OLdcfZee1upB11YYdSw
+ssN1h6YrL9elBHH3a6QhKQcO0NKUV39lB7ht3OuHGwRxga26TTkabIuKA4Iu
+IYF/Ha2M5/qaXOC9Hx2B8lWzfiX2W2nFDcTeLPz8/ddrF1dvUzj+qaux0X4g
+JEKZfzYTyismHGgJ93H6u7ot2ueL4e890aNlXrRytx4yi8hkIblmBpySnGuE
+FYfz7+pCRmVY3nbi/y7BnQBOr+GSAReHRMOqAZKG+Oq7MB6Bnt4ljX+aqdtU
+Lnridhh+9Qn3rUl6Hvxww6gkS7oyOLXIjdz8od7Ic7Ym7cO9B2pbnH4ci1Hg
+kkylMzh0zc2nGLUF7/Q93DqyPy/Ou3JNxptosm4bcjUcI43X2T3qo47c064m
+ppS6RthNLnrVvVPecPnJVAP0M8hGd6ac7Mh1YvFdN/TTfG/AGXp8dojZa5in
+WXJUOx8jPYS5fDZHGmgqw/qieVj0xcpwH6WUr7PhxkCydo1C+Ur9lNOmiPiY
+ZHUneHF3aKLGcJ08NRttJ/azd2/hGOKyLrnSj32N69o34hRRWYW3ZgxaI7tU
+W0Ac3XI0Xcevy4w4ZonrqnaYmdE4u1ayQ4h7TWFY7giX87c11NAMTcj8QXe5
+4+/3fApxXPfkLp6Vu9/GWjADJ0Acr9AueEZSV++HLv7rLX77bfBDBzo66ls4
+feQWYRRA1AT2qdzaLK87JRn4E/neGWeGgw2EzoUyEzpcXJ6BJ3CM7w0kaYHd
+IppwC8ppNtOd0Nf62zEbrHg5SRveSSQ94vNnru5YpMgG7CKS88dpb0J/m9RY
+iuAZQYXurj6WiVD2gKyr97eFI0JiR8v5stAbeThGnibBOcoNOrgSxg2sxkUo
+RtbgnUTysdrIG6sx8iZrtJtUJ9MUHjpaZyK46S+lJUTyyV5hsX10s5pWJhlZ
+oFoh1qMN25A7DvzNAQHrcXfanFBdElfids4uwzcNUCVKaNi9gGo1zahA1d8t
+KwpZOncSr5Gem6FDkM/N9hvyCQ3GagGRW5PUthOuE2fa85vj5AMxzo6krGfz
+kYgDwB2JcXexeMVhDQNd9lXcR0PX+NTY/ix62ZjkWeLzZSmCYuIDRHH131nb
+Z2CaCDyldXDoj5gVp56uJ0oNtXs9V8B27yuEIz1qso64tvqvfUdqsyOEtY2m
+uNOEdI1FTDKdqMQ1cZ5x1KyMg+I6yftx+3Gwi6zMeHEm1CzX3WoAxxnRgGqd
+A6Te8EaEr14xBnt6DaTfFyKO9ncG0EMcAuRNxNYQpJPei3/sykiCVG1/Jinl
+rlEq44umzNYMapoNPsBuWeFQq+lEFEvuhr3Yx5Yv5M6C49K4tlmyUK1q5La0
+oiJHu9ZkhWi7Rtt4oN8rJxb3nFThMhhW/AZtO3P9zUNT8i/qnBx3xS0TnBZP
+agcPhdSXcZW4XiV+jU/RqHeeExavp9ED8CIPu3UX2hfd+w81GTLqCnClsZWd
+c4LoFZrwkPq0u0WuxO/Q/s4vTt9cnb46fX169fZnp4brIuPWAxrAceql17ar
+EbMwr5yi8ne0nE5dsIdsIg6kCrSR0iIGlPivbhAzzTlVpE25UjldkVHv1fO1
+VrDuZmXCoyTc7bKl8O2pH8hIGUGS3eSStTarq+V0hmhhuLpW33cd6rrJXAY3
+wz11t4f3ElkiVZyzhPW2yqCpmSjvoAuS7nnIvSiNy/csViHQMzFaXUzMuoVY
+kzEZ76H2oXhnQzMF327Ed8NzgX3+rn/G2Ub+Ir+YzYcu/KDrHBawbHAM+/tz
+POfugQBTrfuMNadLagE1I7l2fk1NvTg5u7qyO5dLJLueQEnwDRaG2gWexcZ4
+NVTeSkbwFjphxiADbrNem3Hetkn8a2QipaZrp7V+8jbEQKXRrSw31mkcmJCD
+pmtYPxItJJQGt2ogpaVcsGZSUc48hOI2tDSPjHopp8RRtExvuiWV6AMaywjj
+jNO/pNF4vNo2gqguXTrJjLmZHidcYNTtABaGDQr50ISCKCgRzEBwTZjT9fM6
+subTAt0lcDtj/0ZU3qDcTynMqtMhRhV/r/STZFvzZ3hBW07Cjxd1Re+qyh75
+GuwXfA1rlycbFwvPG/U/mP8DO2hh6c+kAAA=
 
 -->