# LINE boundaries: separate identities, accepted records, clear limits

> In progress · 20 October 2026 · Wiki version 2026.10.20.2

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.

## Purpose
Keep messaging concepts useful while preventing unconfirmed end-to-end acceptance or identity ownership from being represented as finished.

## Diagram text alternative
The company Official Account, employee operations bot, and Hermes adapter are distinct. A reviewed record boundary determines whether an interaction can support an operational outcome.

## Current / proposed status
- Current: In progress — company-owned LINE acceptance, end-to-end confirmation, and final ownership are not confirmed.
- Proposed: Verify approved identity, record linkage, consent/authority, accepted conversation, and exception handling before claiming operational readiness.

## Safe example
### A safe message-to-record question
Instead of copying a conversation into a general note, ask whether the company Official Account, employee operations bot, or Hermes adapter is the approved identity for this step; then link only the approved record reference after acceptance is confirmed.

## Responsibilities
- The company Official Account represents the company-facing identity.
- The employee operations bot is a separate operational identity.
- Hermes is an adapter boundary, not a substitute for company identity or approval.
- A responsible reviewer confirms what conversation, record, and outcome can be accepted.

## Checklist
- Name the intended identity before designing or investigating a message flow.
- Keep message payloads, customer details, and tokens out of the wiki and prompt exports.
- Do not treat an available console or adapter as proof of end-to-end acceptance.
- Link an approved conversation to the relevant record only after authority and outcome are confirmed.

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

## Separate identities prevent a message from gaining accidental authority

**Status:** In progress

The employee operations bot, Hermes adapter, and company Official Account are different identities. Their names may appear near one another in a system diagram, but that does not grant them the same role, audience, permissions, or acceptance authority.
Before a messaging workflow is changed, identify which identity is intended to speak, which record will carry the result, and who can authorise the next step. Avoid using an adapter or console login as evidence that this boundary is settled.

**Current / proposed status**
- Current: In progress — final ownership and end-to-end acceptance are explicitly not confirmed.
- Proposed: Document approved identity, authorised operator, record linkage, and handoff conditions after an owner verifies them.

**Expected outcome**
A message workflow can be assessed without conflating technical connectivity with organisational authority.

**Meaningful tests**
- Check all three identities are separately named in the diagram and text equivalent.
- Check no exported prompt includes a credential request or suggests sending a test message automatically.

<a id="conversation-evidence"></a>

## A conversation is not evidence until its record boundary is accepted

**Status:** In progress

A message can provide context, but an operational result needs an approved record link, known identity, and a reviewer who can accept the stated outcome. This is particularly important when a message could affect a guest, owner, or task state.
Use a safe placeholder in documentation. Do not place private message text, phone numbers, tokens, or screenshots of live conversations into the wiki, llms.txt, or contextual work draft.

**Current / proposed status**
- Current: In progress — company-owned LINE access and an approved conversation linked to a record remain an open rollout item.
- Proposed: Verify a controlled, approved conversation with the intended record and review boundary before marking this path checked.

**Expected outcome**
The team can distinguish useful message context from a confirmed operational record.

**Meaningful tests**
- Search generated exports for token-like or message-payload content; none should be present.
- Check a selected context section contains only its own prose and source pointers.

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

## Mark acceptance pending until a real, authorised case closes

**Status:** In progress

The available information does not confirm end-to-end LINE acceptance or final ownership. The safe status is pending, not “nearly done” or “live”. A future accepted case should describe its actor, approved identity, record, decision, evidence, and exception path.
The wiki can help someone prepare a careful investigation or plan. It cannot send a test, alter an Official Account, change credentials, or claim the result.

**Current / proposed status**
- Current: In progress — no final acceptance is asserted.
- Proposed: Close only when an approved owner verifies a real case and records the acceptance evidence and exceptions.

**Expected outcome**
Open uncertainty stays visible to the people responsible for resolving it.

**Meaningful tests**
- Check “acceptance pending” is present in the page, Markdown export, and context export.
- Check Open Codex draft disables rather than truncates a long complete prompt.

## Related pages
- [Hermes: an adapter boundary, not a company identity](/systems/hermes/) — 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.
- [Turnover readiness: evidence before a ready decision](/workflows/turnover-evidence/) — A turnover prepares a property between stays. Assignment, cleaning completion, evidence, verification, and readiness are separate states that must refer to the same confirmed property.
- [Service directory: approved destinations, not shared access](/reference/service-directory/) — This directory names the approved service destinations used around Co.Property. Every destination requires an existing authorised account or approved auth; the wiki never stores tokens, credentials, or private logs.

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

## Context export
- Page context: ./exports/workflows--line-boundaries.context.json