Files
Christian Nennemann 2506b6325a
Some checks failed
CI / test (3.11) (push) Failing after 1m37s
CI / test (3.12) (push) Failing after 57s
feat: add draft data, gap analysis report, and workspace config
2026-04-06 18:47:15 +02:00

3.7 KiB
Raw Permalink Blame History

Master Prompt: Minimal IETF I-D for Agent DAG Token + HITL Policy

You are an expert IETF editor and protocol designer.

Write a complete, technically coherent Internet-Draft (-00) in IETF style (RFC 7322 / RFC 7991 conventions, BCP 14 language), in clear Markdown suitable for kramdown-rfc.

Objective

Create a minimal base specification for safe agent context transfer with exactly two core contributions:

  1. Agent DAG Token: a lightweight token container that models agent/task delegation as a DAG.
  2. HITL Policy Mechanism: a built-in human-in-the-loop override policy for safety-critical decisions.

The draft should be inspired by:

  • draft-nennemann-wimse-ect-00 (concept lineage)
  • draft-richer-wimse-token-container-00 (base token container idea)

But this new draft MUST:

  • NOT require encryption overhead in the base spec.
  • NOT depend on broader WIMSE framework components.
  • stay small, sharp, and implementation-friendly.
  • focus on safety first, not regulated-environment complexity.

Design Constraints

  • Keep the draft intentionally narrow and deployable.
  • Base profile only; define extension points for future work.
  • Do not include advanced compliance features in the core.
  • Assume integrity/authenticity can be provided by existing token signing and transport protections; confidentiality/encryption is out of scope for base.
  • Avoid introducing mandatory new registries unless absolutely necessary.

Required Content

Produce a full I-D with these sections:

  1. Title, Abstract, Status, Copyright
  2. Introduction (problem statement and why safety needs DAG + HITL)
  3. Conventions and Terminology (BCP14 + terms)
  4. Use Cases (23 concise safety-centric examples)
  5. Requirements (minimal normative requirements)
  6. Token Model
    • Minimal claims set (base claims + DAG claims)
    • DAG representation (nodes, edges, constraints)
    • Processing semantics (validation, traversal, delegation checks)
  7. HITL Policy Model
    • Policy object structure (trigger, required human role, action)
    • Runtime behavior (pause/escalate/override/abort/continue)
    • Audit event requirements (minimal decision record)
  8. Interoperability and Deployment Considerations
  9. Security Considerations
    • Safety failure modes
    • Abuse/misuse
    • Why confidentiality is out of scope in base
  10. Privacy Considerations (minimal but explicit)
  11. IANA Considerations (likely none, or minimal if truly needed)
  12. References (normative + informative)
  13. Appendix A: Compact JSON examples
  • one DAG token example
  • one HITL policy example
  • one end-to-end processing example

Token/Profile Specific Guidance

  • Keep token structure aligned with a generic token container philosophy.
  • Define only fields that are necessary for interoperable DAG + HITL behavior.
  • Separate:
    • Token data model (what is carried)
    • Processing rules (how recipients act)
  • Include clear error handling outcomes for:
    • invalid DAG
    • missing node context
    • policy trigger without reachable human approver
    • conflicting policy actions
  • Include a strict “Out of Scope” subsection listing:
    • encryption envelope
    • regulated controls
    • remote attestation
    • trust framework onboarding
    • rich workflow orchestration

Style and Quality Bar

  • Be concise and normative where needed.
  • Avoid hand-wavy text; include precise behavior.
  • Keep -00 realistic: minimal yet complete.
  • Prefer clarity over completeness.
  • Include TODO markers only where absolutely unavoidable.

Output Format

Return:

  1. Suggested draft name (draft-<author>-<topic>-00)
  2. Final full draft Markdown
  3. A one-page delta note: “What this base draft intentionally does NOT include yet (and why)”