Diff: services/template-ledger.es
From 5f17aa1 to 5f17aa1
+0 / −0 lines
| Before | After |
|---|---|
| --- | --- |
| schema: foundry-doc-v1 | schema: foundry-doc-v1 |
| title: "Template Ledger (service-email-template)" | title: "Template Ledger (service-email-template)" |
| slug: template-ledger | slug: template-ledger |
| category: services | category: services |
| type: topic | type: topic |
| quality: complete | quality: complete |
| short_description: "The Template Ledger is the distribution mechanism within service-email-template that synchronises a single authoritative copy of every approved template to the operator's mail environment — eliminating version drift between template design and operator execution and removing every drafting step from routine corporate correspondence." | short_description: "The Template Ledger is the distribution mechanism within service-email-template that synchronises a single authoritative copy of every approved template to the operator's mail environment — eliminating version drift between template design and operator execution and removing every drafting step from routine corporate correspondence." |
| status: active | status: active |
| bcsc_class: public-disclosure-safe | bcsc_class: public-disclosure-safe |
| last_edited: 2026-05-08 | last_edited: 2026-05-08 |
| editor: pointsav-engineering | editor: pointsav-engineering |
| paired_with: template-ledger.es.md | paired_with: template-ledger.es.md |
| cites: [] | cites: [] |
| --- | --- |
| The Template Ledger is the distribution mechanism within `service-email-template` that synchronises a single authoritative copy of every approved template to the operator's mail environment automatically. It eliminates version drift between template design and operator execution by maintaining one canonical copy per template identifier; the operator retrieves the current version by key and sends it directly. The distinction between drafting and deploying becomes structural rather than procedural — the operator is not authoring routine corporate correspondence, only selecting which approved template to dispatch. | The Template Ledger is the distribution mechanism within `service-email-template` that synchronises a single authoritative copy of every approved template to the operator's mail environment automatically. It eliminates version drift between template design and operator execution by maintaining one canonical copy per template identifier; the operator retrieves the current version by key and sends it directly. The distinction between drafting and deploying becomes structural rather than procedural — the operator is not authoring routine corporate correspondence, only selecting which approved template to dispatch. |
| ## Design intent | ## Design intent |
| Operators at Woodfine Management Corp. do not draft routine corporate emails from scratch. Each template type — compliance notices, financial disclosures, client correspondence — exists as a versioned record in the Template Ledger. Operators retrieve the current version by key and send it directly. The distinction between drafting and deploying is structural, not procedural. | Operators at Woodfine Management Corp. do not draft routine corporate emails from scratch. Each template type — compliance notices, financial disclosures, client correspondence — exists as a versioned record in the Template Ledger. Operators retrieve the current version by key and send it directly. The distinction between drafting and deploying is structural, not procedural. |
| ## Operator workflow | ## Operator workflow |
| 1. The operator opens their `Template Ledger` folder in Microsoft 365. | 1. The operator opens their `Template Ledger` folder in Microsoft 365. |
| 2. The root folder contains a single email (`[TMPL-000]`) with an attached offline `.html` catalog. | 2. The root folder contains a single email (`[TMPL-000]`) with an attached offline `.html` catalog. |
| 3. The operator opens the catalog, filters by category (for example, *Compliance* or *Finance*), and copies the key for the desired template. | 3. The operator opens the catalog, filters by category (for example, *Compliance* or *Finance*), and copies the key for the desired template. |
| 4. The operator pastes the key (for example, `[TMPL-042]`) into the M365 search bar. The current version of that template appears immediately. | 4. The operator pastes the key (for example, `[TMPL-042]`) into the M365 search bar. The current version of that template appears immediately. |
| 5. The operator clicks **Forward**, updates the recipient, removes the routing metadata block at the top of the email body, and sends. | 5. The operator clicks **Forward**, updates the recipient, removes the routing metadata block at the top of the email body, and sends. |
| The key is the only input the operator supplies. The template content is sourced from the ledger, not typed or pasted. | The key is the only input the operator supplies. The template content is sourced from the ledger, not typed or pasted. |
| ## Silent synchronization via Microsoft Graph | ## Silent synchronization via Microsoft Graph |
| When a PointSav engineer updates a template — for example, adding a revised Direct-Hold Solutions rider — the synchronization service uses the Microsoft Graph API to: | When a PointSav engineer updates a template — for example, adding a revised Direct-Hold Solutions rider — the synchronization service uses the Microsoft Graph API to: |
| 1. Remove the previous version of the template from the operator's sub-folder. | 1. Remove the previous version of the template from the operator's sub-folder. |
| 2. Insert the updated version in its place. | 2. Insert the updated version in its place. |
| No push notification is sent to the operator. The current template is always present in the folder; no operator action is required to receive an update. The absence of notifications is deliberate: unnecessary alerts reduce the operator's ability to recognize a genuinely significant event. | No push notification is sent to the operator. The current template is always present in the folder; no operator action is required to receive an update. The absence of notifications is deliberate: unnecessary alerts reduce the operator's ability to recognize a genuinely significant event. |
| ## See also | ## See also |
| - [[service-email]] — the Ring 1 email ingest service that handles inbound messages | - [[service-email]] — the Ring 1 email ingest service that handles inbound messages |
| - [[style-guide-guide]] — operational register conventions for deployment runbooks | - [[style-guide-guide]] — operational register conventions for deployment runbooks |
| - [[disclosure-substrate]] — the disclosure architecture that governs outbound communications | - [[disclosure-substrate]] — the disclosure architecture that governs outbound communications |