Co.PropertyTeam wikiCo.Property20 October 2026
Press slash to search. Arrow keys select a result.
Internal knowledge
Browse the wiki

Systems

Hermes

In progress

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.

Download page Markdown
Interactive mapSelect a node to read its explanation. Use Work on this beside the section to prepare a change.
Hermes: an adapter boundary, not a company identity diagramAn 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.Approved input — Hermes: an adapter boundary, not a company identityApproved inputHermes adapter — Hermes: an adapter boundary, not a company identityHermes adapterReviewed record — LINE boundaries: separate identities, accepted records, clear limitsReviewed recordAuthorised owner — Hermes: an adapter boundary, not a company identityAuthorised owner
Hermes connects defined records across a review boundary; it does not own the decision.Solid · information flow
Read the diagram as text

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.

  • Approved input → Hermes: an adapter boundary, not a company identity
  • Hermes adapter → Hermes: an adapter boundary, not a company identity
  • Reviewed record → LINE boundaries: separate identities, accepted records, clear limits
  • Authorised owner → Hermes: an adapter boundary, not a company identity
What it does

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

Responsibility

Hermes adapts between defined systems or identities only through approved boundaries.

Next step

Name input record, output record, identity, and owner before proposing an adapter change.

An adapter does not inherit the identity on either side

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.

Read the details

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
In progress — final identity ownership and end-to-end acceptance are not confirmed.
Proposed next state
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.
Checks to include when changing this section
  • Check adapter prompt context repeats the identity boundary and no-execution rule.
  • Check no wording conflates Hermes with the company Official Account.

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

Checked

Describe an adapter mapping in terms of its approved input record, output record, identity boundary, duplicate behavior, failure behavior, freshness expectation, and reviewer.

Read the details

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
Checked — this is a safe contribution standard derived from the source and system boundaries.
Proposed next state
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.
Checks to include when changing this section
  • Run duplicate, missing-source, failure, freshness, and identity-mismatch fixtures.
  • Check the generated context scope is one selected mapping section plus direct related summaries.

Connectivity is not an accepted business outcome

In progress

A connection can be technically present while the business outcome is still unaccepted.

Read the details

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
In progress — no final operational acceptance is asserted.
Proposed next state
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.
Checks to include when changing this section
  • Check all published content retains “pending” for LINE/Hermes acceptance.
  • Check Open Codex draft performs no action and long prompts have copy/download fallback.

Apply with care

A concrete safe example

Example, responsibilities & checklist

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

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

A technical or operational reviewer can separate adapter connectivity from authority, identity, and accepted outcomes.

Traceability without sensitive material

Source pointers and exports

This page expands the approved handoff into plain-language guidance. It does not include runtime logs, credentials, databases, private evidence, internal QA artifacts, or developer planning history.

Documentation references
  • Handoff / pages/infrastructure.html
  • Handoff / START-HERE.html
  • Handoff / pages/workflows.html
Page MarkdownPage context JSON