<?xml version="1.0" encoding="UTF-8"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
     version="3"
     category="exp"
     docName="draft-lohmann-qikvrt-effect-ack-00"
     ipr="trust200902"
     submissionType="independent"
     xml:lang="en">
  <front>
    <title abbrev="QIK-VRT EFFECT_ACK">The QIK-VRT Effect Acknowledgement Protocol</title>
    <seriesInfo name="Internet-Draft" value="draft-lohmann-qikvrt-effect-ack-00"/>
    <author fullname="Ingolf Lohmann" initials="I." surname="Lohmann">
      <organization>Independent Researcher</organization>
      <address>
        <postal>
          <country>Germany</country>
        </postal>
        <email>ingolf.lohmann@web.de</email>
        <uri>https://github.com/ingolf-lohmann</uri>
      </address>
    </author>
    <date year="2026" month="June" day="18"/>
    <area>General</area>
    <workgroup>Independent Submission</workgroup>
    <keyword>QIK-VRT</keyword>
    <keyword>Effect Acknowledgement</keyword>
    <keyword>Information Effect</keyword>
    <keyword>Audit</keyword>
    <keyword>AI Governance</keyword>
    <abstract>
      <t>This document defines the QIK-VRT Effect Acknowledgement Protocol (EFFECT_ACK), a protocol layer between technical transport acknowledgement and responsible semantic release. TCP acknowledgement confirms technical arrival. EFFECT_ACK confirms whether received information may responsibly continue as an effect. The protocol distinguishes TRANSPORT_ACK from EFFECT_ACK, defines five effect states, introduces a versioned and hash-linked Responsibility Protocol, and specifies deterministic hashing and canonical JSON requirements for reproducible audit.</t>
    </abstract>
  </front>
  <middle>
    <section numbered="true" anchor="intro">
      <name>Introduction</name>
      <t>Modern information systems increasingly transmit not only data, but effects. Texts, code, decisions, model outputs, recommendations, warnings, legal assessments, financial signals, governance actions, machine-to-machine messages, and AI-generated content can change behavior, trigger downstream processes, influence decisions, or cause harm.</t>
      <t>Traditional network layers answer whether information arrived. QIK-VRT adds the required next question: may this information responsibly continue to have effect?</t>
      <sourcecode type="text">TRANSPORT_ACK != EFFECT_ACK</sourcecode>
      <t>A transport acknowledgement confirms arrival. An effect acknowledgement confirms responsible permission for further effect.</t>
    </section>
    <section numbered="true" anchor="terms">
      <name>Terminology</name>
      <t>The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as normative requirement levels.</t>
      <t>A TRANSPORT_ACK confirms technical arrival but not semantic validity, contextual correctness, safety, responsibility, or release permission.</t>
      <t>An EFFECT_ACK confirms that a received information unit has passed a QIK-VRT effect gate and has been classified into one of the defined release states.</t>
      <t>A Responsibility Protocol, abbreviated as P, is a versioned, hash-linked, audit-capable record of checks, evidence, risks, open questions, reasons, and responsibility assignments that support an EFFECT_ACK decision.</t>
    </section>
    <section numbered="true" anchor="layering">
      <name>Layering Model</name>
      <sourcecode type="text">Layer 3: IP
  Addressing, routing, reachability

Layer 4: TCP
  Sequencing, acknowledgement, retransmission, timeout

Layer 4.5: QIK-VRT EFFECT_ACK_GATE
  Effect checking, responsibility, release gating

Layer 7+: Application / cognitive / governance layer
  Meaning, action, decision, publication, storage, execution</sourcecode>
      <t>Transport confirmation is not release confirmation.</t>
    </section>
    <section numbered="true" anchor="principle">
      <name>Core Principle</name>
      <t>A QIK-VRT-compliant system MUST NOT treat received information as released effect merely because it has been technically received.</t>
      <sourcecode type="text">received != released
received -&gt; effect-checked -&gt; classified -&gt; released-or-not-released</sourcecode>
      <sourcecode type="text">TRANSPORT_ACK + RESPONSIBILITY_PROTOCOL = EFFECT_ACK</sourcecode>
      <t>This yields EFFECT_ACK_DONE only if the responsibility protocol is sufficiently complete and release policy permits further effect.</t>
    </section>
    <section numbered="true" anchor="states">
      <name>Effect ACK States</name>
      <sourcecode type="text">EFFECT_NACK
EFFECT_ACK_CONTINUE
EFFECT_ACK_DONE
EFFECT_ACK_ISOLATE
EFFECT_ACK_BLOCK</sourcecode>
      <t>EFFECT_NACK means no effect-checkable reception exists.</t>
      <t>EFFECT_ACK_CONTINUE means effect checking may continue, but effect is not released.</t>
      <t>EFFECT_ACK_DONE means effect has been checked sufficiently for responsible release.</t>
      <t>EFFECT_ACK_ISOLATE means effect must be separated from ordinary flow and examined in containment.</t>
      <t>EFFECT_ACK_BLOCK means effect must not continue.</t>
    </section>
    <section numbered="true" anchor="p">
      <name>Responsibility Protocol</name>
      <t>Every EFFECT_ACK result MUST include a versioned and immutable Responsibility Protocol P. New evidence MUST create a new protocol version.</t>
      <t>A minimal protocol contains protocol_root_id, protocol_version, protocol_id, previous_protocol_id, previous_protocol_hash, protocol_hash, input_id, input_hash, state, transport_ack, origin_checked, context_checked, semantics_reconstructed, effect_anticipated, risk_classified, risk_level, responsibility_assigned, responsibility_owner, connection_decided, reasons, evidence_refs, open_questions, next_required_checks, and created_utc.</t>
    </section>
    <section numbered="true" anchor="hash">
      <name>Hashing Rule</name>
      <t>The protocol_hash MUST be computed over deterministic content only. Timestamps and volatile runtime metadata MUST NOT be included in protocol_hash.</t>
      <sourcecode type="text">same content -&gt; same hash
different evidence -&gt; different hash
different timestamp only -&gt; same hash</sourcecode>
    </section>
    <section numbered="true" anchor="json">
      <name>Canonical JSON</name>
      <t>canonical_json() MUST serialize the hash projection deterministically using UTF-8 without BOM, sorted keys, no whitespace outside strings, normalized Unicode, and removal of volatile fields.</t>
      <sourcecode type="text">protocol_hash =
  "sha256:" + SHA256(UTF8(canonical_json(protocol_hash_projection)))</sourcecode>
    </section>
    <section numbered="true" anchor="op">
      <name>Synchronous and Asynchronous Operation</name>
      <t>The protocol defines a synchronous haltpoint and asynchronous evidence continuation. effectAckSync() MUST return a deterministic state without unbounded waiting.</t>
    </section>
    <section numbered="true" anchor="compliance">
      <name>Compliance Requirements</name>
      <t>A system claiming QIK-VRT EFFECT_ACK compliance MUST distinguish TRANSPORT_ACK from EFFECT_ACK, include Responsibility Protocol P in every result, hash deterministic content only, version every evidence change, treat CONTINUE as unreleased effect, and treat DONE as the only ordinary release state.</t>
      <t>A system MUST NOT claim EFFECT_ACK_DONE if origin is unchecked, context is unchecked, semantics are unreconstructed, risk is unknown, responsibility is unassigned, connection decision is missing, required evidence is absent, or policy does not allow release.</t>
    </section>
    <section numbered="true" anchor="security">
      <name>Security Considerations</name>
      <t>EFFECT_ACK is designed to prevent received-equals-released fallacy, hallucination propagation, context loss, false certainty, ungated downstream effect, silent evidence mutation, unowned responsibility, unbounded waiting, unsafe asynchronous release, and false DONE claims.</t>
    </section>
    <section numbered="true" anchor="privacy">
      <name>Privacy Considerations</name>
      <t>Responsibility protocols may contain sensitive contextual, evidential, or ownership information. Implementations SHOULD support evidence minimization, hash-only evidence references, redacted protocol views, and access-controlled audit logs.</t>
    </section>
    <section numbered="true" anchor="summary">
      <name>Canonical Summary</name>
      <sourcecode type="text">TCP ACK confirms arrival.
EFFECT ACK confirms responsible permission to continue effect.

Transport_ACK != Effect_ACK.

CONTINUE means:
  continue checking,
  do not release effect.

DONE means:
  responsible effect release.</sourcecode>
    </section>
  </middle>
  <back>
    <section numbered="false" anchor="ack">
      <name>Acknowledgements</name>
      <t>q.e.d. Ingolf Lohmann.</t>
    </section>
  </back>
</rfc>
