Skip to content

Diff: services/message-courier.es

From ef58b39 to ef58b39

+0 / −0 lines
BeforeAfter
--- ---
schema: foundry-doc-v1 schema: foundry-doc-v1
title: "Message Courier Service" title: "Message Courier Service"
slug: message-courier slug: message-courier
category: services category: services
type: topic type: topic
quality: stub quality: stub
short_description: "The message courier service is a headless web-automation engine that bridges internal identity ledgers with external web portals using runtime-injected adapters, keeping proprietary operational logic out of the open-source monorepo." short_description: "The message courier service is a headless web-automation engine that bridges internal identity ledgers with external web portals using runtime-injected adapters, keeping proprietary operational logic out of the open-source monorepo."
status: active status: active
bcsc_class: public-disclosure-safe bcsc_class: public-disclosure-safe
last_edited: 2026-04-30 last_edited: 2026-04-30
editor: pointsav-engineering editor: pointsav-engineering
cites: [] cites: []
paired_with: message-courier.es.md paired_with: message-courier.es.md
--- ---
> The message courier service is a headless automation engine that reads pending dispatch records from an internal ledger, executes portal interactions via private runtime adapters, and writes completion timestamps back without embedding any client-specific logic in the open-source codebase. > The message courier service is a headless automation engine that reads pending dispatch records from an internal ledger, executes portal interactions via private runtime adapters, and writes completion timestamps back without embedding any client-specific logic in the open-source codebase.
**`service-message-courier`** is a headless web-automation and **`service-message-courier`** is a headless web-automation and
messaging component designed to bridge `service-people`, the messaging component designed to bridge `service-people`, the
internal identity ledger, with external web portals. The service internal identity ledger, with external web portals. The service
operates as a generic execution engine: all portal-specific logic operates as a generic execution engine: all portal-specific logic
is supplied at runtime through the adapter pattern, so the core is supplied at runtime through the adapter pattern, so the core
engine remains free of hard-coded selectors, credentials, or engine remains free of hard-coded selectors, credentials, or
target URLs. The adapter directory (`private-adapters/`) is target URLs. The adapter directory (`private-adapters/`) is
excluded from version control so proprietary client operational excluded from version control so proprietary client operational
data never enters the public Git history. data never enters the public Git history.
## Adapter pattern ## Adapter pattern
The core engine contains no knowledge of any specific portal or The core engine contains no knowledge of any specific portal or
site. Operational logic — CSS selectors, URL shapes, authentication site. Operational logic — CSS selectors, URL shapes, authentication
flows — is injected at runtime via scripts placed in flows — is injected at runtime via scripts placed in
`private-adapters/`. This directory is explicitly excluded by `private-adapters/`. This directory is explicitly excluded by
`.gitignore`. The separation means the open-source monorepo `.gitignore`. The separation means the open-source monorepo
remains tenant-agnostic while each deployment instance carries its remains tenant-agnostic while each deployment instance carries its
own private adapter set. own private adapter set.
## Operational flow ## Operational flow
The courier follows a three-step cycle per dispatch: The courier follows a three-step cycle per dispatch:
1. **Query.** The engine polls the local ledger for pending 1. **Query.** The engine polls the local ledger for pending
dispatch records. dispatch records.
2. **Execution.** It mounts the specified private adapter and runs 2. **Execution.** It mounts the specified private adapter and runs
the headless browser routine against the target portal. the headless browser routine against the target portal.
3. **Write-back.** On success, the engine logs the completion 3. **Write-back.** On success, the engine logs the completion
timestamp to the ledger and unloads the adapter. timestamp to the ledger and unloads the adapter.
Each step is isolated. A failure at execution does not corrupt the Each step is isolated. A failure at execution does not corrupt the
ledger record; the dispatch remains pending until a successful ledger record; the dispatch remains pending until a successful
write-back closes it. write-back closes it.
## See Also ## See Also
- [[ontological-governance|Ontological Governance]] - [[ontological-governance|Ontological Governance]]
- [[verification-surveyor|Verification Surveyor]] - [[verification-surveyor|Verification Surveyor]]
- [[sovereign-telemetry|Zero-State Telemetry Architecture]] - [[sovereign-telemetry|Zero-State Telemetry Architecture]]
## References ## References
--- ---
*Copyright © 2026 Woodfine Capital Projects Inc. Licensed under [Creative Commons Attribution 4.0 International](https://creativecommons.org/licenses/by/4.0/).* *Copyright © 2026 Woodfine Capital Projects Inc. Licensed under [Creative Commons Attribution 4.0 International](https://creativecommons.org/licenses/by/4.0/).*
*Woodfine Capital Projects™, Woodfine Management Corp™, PointSav Digital Systems™, Totebox Orchestration™, and Totebox Archive™ are trademarks of Woodfine Capital Projects Inc., used in Canada, the United States, Latin America, and Europe. All other trademarks are the property of their respective owners.* *Woodfine Capital Projects™, Woodfine Management Corp™, PointSav Digital Systems™, Totebox Orchestration™, and Totebox Archive™ are trademarks of Woodfine Capital Projects Inc., used in Canada, the United States, Latin America, and Europe. All other trademarks are the property of their respective owners.*