Function wrap_jekt_message 

pub fn wrap_jekt_message(
    msg: &str,
    source_agent: Option<&str>,
    target_agent: &str,
    effective_tier: &str,
    delivery_tier: &str,
    sig_verified: Option<bool>,
    reagent_verified: Option<bool>,
    lan_verified: Option<bool>,
    channel_verified: Option<bool>,
    wan_instance: Option<&WanInstanceInfo>,
    requires_stop: bool,
    msg_id: &str,
    priority: &str,
    held_sent_at_ms: Option<i64>,
) -> String

Wrap an injected message with a structured [JEKT:...] marker block.

The marker is machine-parseable (first line) and human-readable (the rest). effective_tier should already account for keyword-based escalation.

sig_verified (SPEC_JEKT_TRUST_LAYER_COMPLETION_2026_08_13.md §2.2) is a genuine three-state signal, not a bool — collapsing “never checked” into “verified” would mislabel every caller that has no signing key at all (the Slack/Discord/Telegram/WhatsApp bridges, or an agent not yet respawned since this feature shipped) as cryptographically proven when nothing was actually checked:

• Some(true) — claimed source_agent has a key on file AND the signature verified. Renders TRUST=host-verified. This is the only case where sender identity is actually PROVEN, not merely assumed.
• Some(false) — claimed source_agent has a key on file but the signature was missing or didn’t match. Renders TRUST=unverified — a real red flag; the caller escalates this to TIER=sensitive.
• None — no signing key exists for the claimed source_agent at all, so nothing was checked (today’s pre-existing behavior for every host-tier caller, unaffected by this feature). Renders TRUST=self-declared — explicitly NOT the same as “verified.” Ignored (always renders TRUST=network-claimed) for any non-host delivery tier — network delivery is never treated as verified regardless of this signal, by design.

reagent_verified answers an orthogonal question, additively: not “how was this delivered” (that’s TRUST, unconditionally network-claimed for any non-host tier, unaffected by this parameter) but “is this specific message cryptographically proven to come from an AgentMux-operated WAN service sender” (currently only the GitHub review-notification consumer). Renders a new, independent SIG= marker field:

• Some(true) — the sender’s Ed25519 signature verified against the pinned public key. Renders SIG=verified.
• Some(false) — a signature was present but didn’t verify (wrong key, tampered content, or unrecognized key id). Renders SIG=invalid — a real red flag, same spirit as host-tier’s TRUST=unverified.
• None — no signature was attempted (the overwhelming majority of WAN traffic, and all host/lan traffic). No SIG= field is rendered at all, so existing marker parsing/tests are unaffected. Never changes TRUST — a verified reagent signature still delivers as TRUST=network-claimed; TRUST answers “did this cross a network boundary,” which stays true regardless of whether the sender could also be verified. This function itself never computes effective_tier either way — that’s a caller-supplied parameter, unchanged.

As of SPEC_JEKT_REAGENT_TRUST_RELAXATION_2026_08_14.md §1, though, the CALLER (Handler::inject_message) now does let reagent_verified == Some(true) change what effective_tier it passes in here — a WAN jekt verified against reagent’s pinned Ed25519 key is no longer forced to sensitive by delivery tier alone, mirroring how sig_verified == Some(true) (host-tier) already doesn’t force it. So SIG=verified and TIER=coord/info can now appear together on the SAME marker where they never could before — this is by design, not a bug: TRUST still tells you “crossed a network boundary” and SIG=verified still tells you “but cryptographically proven who sent it,” and it’s exactly that proof that now lets TIER relax. A declared-SENSITIVE tier or a keyword match still escalates a verified reagent message just as it would any other — verification only removes the blanket network-tier forcing, not the content-based escalation rules layered on top of it.

lan_verified (SPEC_JEKT_LAN_TIER_SIGNING_2026_08_15.md, §2.5) is the LAN analog, but folded into TRUST rather than a separate SIG= field: unlike WAN’s reagent scheme (one pinned service key, so “did THIS message verify” is independent of “who is this from”), LAN verification is inherently per-claimed-sender — a verified LAN signature IS proof of exactly who sent it, the same kind of claim TRUST=host-verified already makes for host tier. Some(true) renders TRUST=lan-verified (overriding the usual TRUST=network-claimed LAN/WAN get); Some(false) or None leave TRUST=network-claimed unchanged — the LAN-signature- failed red flag itself lives in TIER (handler.rs’s is_lan_sig_invalid), same as how SIG=invalid doesn’t get its own TRUST value either.

channel_verified (SPEC_JEKT_CROSS_CHANNEL_TRUST_2026_09_02.md §D3/§D4) is the same idea one tier over: DELIVERY=channel is a same-machine forward to a different AgentMux instance — until Phase B it rendered as host, the strongest-sounding label, with no verification behind it. On that tier Some(true) renders TRUST=channel-verified (its own label, like lan-verified, so a reader can tell how identity was proven). Otherwise the tier falls back to the host-tier labels off sig_verified: the receiving instance may still hold the sender’s HMAC key (a same-channel sibling instance) and have proven identity that way, and the two verifiers are mutually exclusive by construction (§D2 step 2), so there’s never a conflict to resolve. Some(false) renders nothing special here — same as lan_verified, the red flag (once Phase C enables it) lives in TIER.

wan_instance (SPEC_WAN_JEKT_VERIFICATION_2026_09_24.md §2.6) is the WAN analog, passed only when a same-account agent’s WAN signature verified (wan_verified == Some(true)). On the WAN tier it renders TRUST=wan-verified INSTANCE=<host_hint>~<id8> INSTANCE_STATUS=<status>: the label’s suffix comes from the id the certificate chain proved, never from the sender, and the status tells the reader whether a human approved that install (approved), nobody has yet (new), or its owner retired it (revoked: forced sensitive by the caller). Both approved and new count as a verified sender (ESCALATE=none) since 2026-09-26 (SPEC_WAN_JEKT_VERIFICATION_2026_09_24.md §2.6); only revoked does not.

requires_stop (SPEC_JEKT_SENSITIVE_TIER_VERIFIED_SENDER_NO_STOP_2026_08_17.md) is the caller’s already-computed answer to “does TIER=sensitive mean STOP, or just tag-for-visibility” — see Handler::inject_message_inner’s requires_stop doc comment for the full rule. Only rendered/consulted when effective_tier == "sensitive"; ignored otherwise (mirrors how sig_field is only rendered when reagent_verified.is_some()). Adds an ESCALATE= marker field so the receiving agent doesn’t have to infer stop-or-not by cross-referencing TRUST/SIG itself — an authoritative, server-computed field is harder to argue around via prompt injection than asking the reading LLM to do that inference live.