# Hermes: an adapter boundary, not a company identity

> In progress · 20 October 2026 · Wiki version 2026.10.20.2

Hermes is an adapter in the operating architecture. It does not replace the company Official Account, employee operations bot, provider authority, or a reviewed record boundary.

## Purpose
Make it clear what Hermes may connect and what it must not be assumed to authorise or complete.

## Diagram text alternative
An approved source record reaches Hermes, which proposes or carries a defined mapping to a reviewed company record. The responsible identity and reviewer determine any accepted outcome.

## Current / proposed status
- Current: In progress — Hermes-related final ownership and end-to-end LINE acceptance are not confirmed.
- Proposed: Verify the intended identity, approved input/output record, failure handling, and owner before accepting a live adapter flow.

## Safe example
### A safe adapter proposal
Describe a Hermes change as “propose a mapping from an approved input record to a reviewed output record, with duplicate and failure handling.” Do not frame it as permission to send a message, change a provider record, or accept a business outcome.

## Responsibilities
- Hermes adapts between defined systems or identities only through approved boundaries.
- The source provider retains authority for its transactions.
- The company identity and authorised reviewer retain responsibility for a communication or decision.
- A contributor tests the adapter’s failure, duplicate, identity, and freshness behavior before PR review.

## Checklist
- Name input record, output record, identity, and owner before proposing an adapter change.
- Keep credentials, message payloads, and private logs out of docs and prompts.
- Test duplicate, missing, stale, and failed cases—not only a happy path.
- Do not claim accepted LINE behavior until an approved real case is verified.

<a id="identity-boundary"></a>

## An adapter does not inherit the identity on either side

**Status:** In progress

Hermes can be useful for connecting defined inputs and outputs, but it is not automatically the company Official Account, the employee operations bot, a provider, or an authorised reviewer. Those identities and responsibilities remain distinct even when an integration makes a flow appear seamless.
This boundary protects both operations and communications. It stops a technically reachable route from being mistaken for permission to act, send, accept, or change a source record.

**Current / proposed status**
- Current: In progress — final identity ownership and end-to-end acceptance are not confirmed.
- Proposed: Capture the named approved identity and reviewer for every live adapter flow before release.

**Expected outcome**
The adapter has a constrained, reviewable role instead of implicit authority.

**Meaningful tests**
- Check adapter prompt context repeats the identity boundary and no-execution rule.
- Check no wording conflates Hermes with the company Official Account.

<a id="mapping-boundary"></a>

## A mapping needs source, destination, failure behavior, and a reviewer

**Status:** Checked

Describe an adapter mapping in terms of its approved input record, output record, identity boundary, duplicate behavior, failure behavior, freshness expectation, and reviewer. That description is more useful than an implementation detail alone because it remains valid if the transport changes.
Where the mapping affects property, task, or message context, preserve confirmed identity rather than relying on a display-name heuristic.

**Current / proposed status**
- Current: Checked — this is a safe contribution standard derived from the source and system boundaries.
- Proposed: Add targeted fixtures and a review owner before a mapping enters a PR.

**Expected outcome**
An integration proposal can be tested for the cases most likely to create misleading operational state.

**Meaningful tests**
- Run duplicate, missing-source, failure, freshness, and identity-mismatch fixtures.
- Check the generated context scope is one selected mapping section plus direct related summaries.

<a id="acceptance"></a>

## Connectivity is not an accepted business outcome

**Status:** In progress

A connection can be technically present while the business outcome is still unaccepted. The current information does not confirm final Hermes ownership or LINE end-to-end acceptance. Use the honest status: pending.
A future accepted case needs an authorised identity, a confirmed record, a defined result, evidence that the flow behaved correctly, and an exception path. This wiki prepares that conversation; it does not run it.

**Current / proposed status**
- Current: In progress — no final operational acceptance is asserted.
- Proposed: Close the item only after an owner verifies an approved real case and retains the evidence in the appropriate authorised record.

**Expected outcome**
Technical success and business acceptance remain separately visible.

**Meaningful tests**
- Check all published content retains “pending” for LINE/Hermes acceptance.
- Check Open Codex draft performs no action and long prompts have copy/download fallback.

## Related pages
- [LINE boundaries: separate identities, accepted records, clear limits](/workflows/line-boundaries/) — LINE employee operations bot, Hermes adapter, and company Official Account are separate identities. A message flow only becomes operational evidence when the right record and acceptance boundary are confirmed.
- [Provider → data → replica: one writer, protected projections](/systems/data-replicas/) — Providers remain authoritative for their own transactions. The main mini writes internal company state; Cloudflare protected replicas and the Vercel staff PWA consume projections rather than replacing the master record.
- [Contribution: isolated workspaces, meaningful tests, reviewed release](/contribution/workspace-and-pr/) — A safe change begins by verifying the remote target, then uses an isolated worktree outside the installed project. It is tested, submitted as a pull request, and reviewed before a person releases it.

## Source pointers
- Handoff / pages/infrastructure.html
- Handoff / START-HERE.html
- Handoff / pages/workflows.html

## Context export
- Page context: ./exports/systems--hermes.context.json