Diff: services/message-courier.es

From 26f79e1 to 26f79e1

+0 / −0 lines

Before	After
---	---
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: pre-build	status: pre-build
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
---	---

# Message Courier Service	# Message Courier Service

> 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.