The Bidirectional Email Automation Protocol (BEAP):
A Cryptographically Constrained Framework for Multi-Agent Automation and Semantic Interaction over Existing Communication Channels**
Abstract
WR Code establishes a transport-agnostic automation protocol that makes workflows verifiable, deterministic, and secure across untrusted systems and execution environments.
Modern digital workflows increasingly rely on AI systems, semantic retrieval, and structured human–machine interaction. Integrating these capabilities across organizational boundaries requires a mechanism for transmitting automation semantics independently of transport protocols while preserving verifiability, determinism, and cryptographic integrity.
This paper introduces the Bidirectional Email Automation Protocol (BEAP) and its core transport-agnostic construct, the BEAP Capsule. BEAP defines a cryptographically constrained application-layer framework for exchanging non-authoritative automation instructions, Mini-App descriptors, context schemas, interaction intents, and secure content representations across existing communication channels, including email, enterprise messaging platforms, peer-to-peer systems, and offline handovers.
BEAP enforces cryptographic integrity by design and mandates parallel hybrid cryptography—combining established classical algorithms with post-quantum–resistant methods—wherever confidentiality is required. Cryptographic primitives are exchangeable at the protocol level, ensuring long-term cryptographic agility without altering Capsule semantics. Public WR Codes are never encrypted; they are strictly tamper-proof and intentionally transparent to preserve auditability.
Emails, including attachments, may be converted into a secure Capsule representation, where textual content is normalized and embedded as structured text for automation and semantic processing. Original email bodies and attachments are preserved separately and attached in encrypted form within the envelope for secure transport, regulatory compliance, and automated archival purposes.
BEAP defines what is described and verified, not what is executed. Mini-App synthesis, context optimization, rasterized preview generation, Augmented Overlay synthesis, and execution are performed by an external WR Code Orchestrator, optionally operating under hardware attestation. Identity validation and admission control are performed exclusively at the envelope level, outside the Capsule.
1. Introduction
Email, messaging platforms, peer-to-peer channels, and file-based exchanges remain among the most widely deployed communication systems. Organizations routinely use these transports to exchange structured data, documents, notifications, and machine-readable content.
Modern workflows increasingly require safe interaction with email content, semantic automation, deterministic user interaction, and secure long-term retention. Integrating these capabilities across organizational and administrative boundaries requires an application-layer structure capable of expressing automation semantics in a verifiable, deterministic, and transport-independent manner.
BEAP provides such a structure.
Rather than modifying SMTP, JMAP, or proprietary messaging APIs, BEAP operates entirely at the application layer and strictly separates semantic description, identity admission, content preservation, and execution authority.
2. Architectural Overview
The WR Code architecture consists of three strictly separated layers:
BEAP Protocol — defines transport-agnostic, non-authoritative automation semantics and content representation
Cryptographic Envelope — handles identity validation, admission, and encrypted original content retention
WR Code Orchestrator — performs synthesis, optimization, preview generation, and execution
BEAP itself is declarative and non-executing by design.
3. The BEAP Capsule: Transport-Agnostic Semantic Unit
The BEAP Capsule is a compact, schema-constrained, deterministic semantic container. It describes automation intent, interaction structure, and normalized content semantics without mandating execution behavior.
3.1 Scope and Responsibility
The Capsule defines:
automation intent descriptors
structured payload and context type schemas
response and continuation instructions (non-authoritative)
Mini-App descriptors and capability requirements
normalized textual representations of email bodies and attachments
references to rasterized previews for safe human interaction
Augmented Overlay intent descriptors
cryptographic integrity over all semantic fields
The Capsule contains no original binary content, no identity claims, and no execution authority.
3.2 Transport Independence
Capsules may be transmitted via:
email bodies or attachments
enterprise messaging systems
consumer peer-to-peer platforms
shared storage or file exchange
QR-based offline transfer
local IPC channels
Transport characteristics do not influence Capsule meaning, integrity, or validity.
4. Cryptographic Envelope and Identity Admission
The cryptographic envelope surrounds the Capsule and is evaluated prior to Capsule acceptance.
4.1 Envelope Responsibilities
The envelope provides:
sender and recipient account identifiers
cryptographic authentication material
replay protection and timestamping
optional origin, handshake and other signaling metadata
admission-relevant attributes
encrypted original email bodies and attachments for secure transport and archival
Identity validation, trust admission, and original-content confidentiality occur exclusively at the envelope level.
4.2 Cryptographic Model
Where confidentiality is required, BEAP mandates parallel hybrid cryptography combining classical and post-quantum–resistant algorithms. Cryptographic primitives are protocol-negotiable and exchangeable without modifying Capsule structure.
Public WR Codes SHALL NOT be encrypted. They rely solely on cryptographic integrity and verification.
Verification is non-interactive and does not introduce protocol-level latency.
5. Capsule Validation
Upon receipt, a BEAP-compliant system performs:
Envelope authentication and admission
Optional decryption of envelope-protected originals
Non-rendered Capsule extraction
Canonicalization
Integrity and signature verification
Schema validation
Successful validation confirms semantic integrity only.
6. Content Handling and Safe Representation
Email content and attachments may be processed as follows:
textual content is normalized and embedded into the Capsule for automation
attachments are represented via extracted text and metadata where applicable
rasterized previews are referenced for safe human review only from hardware attested senders
original binaries remain encrypted within the envelope for archival and compliance
Original content is never implicitly rendered or executed.
7. Separation from Orchestration Authority
BEAP does not define or enforce execution, orchestration, or synthesis behavior. Mini-App synthesis, Augmented Overlay synthesis, rasterization, and execution are performed exclusively by an external WR Code Orchestrator, optionally operating under hardware attestation.
8. Conclusion
BEAP defines a transport-agnostic, cryptographically verifiable application-layer protocol for exchanging non-authoritative automation semantics, Mini-App descriptors, context schemas, and secure content representations. By separating semantic description, identity admission, content preservation, and execution authority, BEAP enables safe, auditable automation across untrusted transports while supporting secure email conversion, encrypted archival of originals, and deterministic downstream processing.
