@raishin/vanguard-frontier-agentic 2.9.0 → 2.11.0

package/skills/cross-functional/erp-crm-cutover-protocol/references/workflow-and-output.md

@@ -0,0 +1,270 @@
+# ERP / CRM Cutover Protocol — Workflow and Output Contract
+
+## Detailed Workflow
+
+### Phase 1: Mock Cutover Review
+
+**Trigger**
+The Dynamics 365 implementation project has reached the Prepare phase. At least
+one mock cutover has been completed in a sandbox environment.
+
+**Step 1.1 — Mock cutover results intake**
+Review the mock cutover results:
+- Task completion status (each task in the cutover plan: completed / failed /
+  skipped)
+- Timing: actual duration vs. planned duration per task and total
+- Errors and issues: critical (blocks go-live), major (requires resolution),
+  minor (can be resolved post go-live)
+- Integration cutover steps: all external systems tested in the mock
+
+**Step 1.2 — Issue triage**
+For each critical or major issue identified in the mock:
+- Document the root cause
+- Assign an owner and resolution target date
+- Determine whether a second mock cutover is required
+
+If critical unresolved issues remain and a second mock is not planned: stop.
+Require the project lead to schedule a second mock before the real cutover
+is authorised.
+
+**Step 1.3 — Timing assessment**
+Confirm that the mock cutover completed within the planned cutover window (with
+buffer). If the mock exceeded the window: the real cutover plan must be revised
+before proceeding.
+
+---
+
+### Phase 2: Data Reconciliation
+
+**Step 2.1 — Reconciliation methodology**
+Confirm the data reconciliation methodology is documented:
+- What data sets are being validated (customers, vendors, items, open
+  transactions, balances, etc.)
+- What tolerance thresholds are accepted for each data set
+- Who is the data owner for each data set
+
+**Step 2.2 — Reconciliation execution (review)**
+Review the reconciliation results from the mock cutover:
+- Records migrated vs. records in source system (count)
+- Financial balances: trial balance match (if applicable)
+- Open transactions: all open orders, cases, or projects reconciled
+- Exceptions: document and classify (acceptable variance / data quality issue /
+  migration script error)
+
+**Step 2.3 — Exception resolution**
+For each exception beyond the tolerance threshold:
+- Require the data owner to either resolve the exception or formally accept
+  the variance with a documented rationale.
+
+---
+
+### Phase 3: Gate 1 — Reconciliation Sign-off
+
+**Required sign-off:**
+- Named data owner confirms that reconciliation thresholds are met for all
+  critical data sets, or formally accepts documented variances with rationale.
+- d365-data-migration-cutover-agent produces the reconciliation report.
+- Project lead countersigns.
+
+If sign-off cannot be obtained: stop. Do not proceed to rollback validation
+without reconciliation sign-off.
+
+---
+
+### Phase 4: Rollback Plan Validation
+
+**Step 4.1 — Rollback plan document review**
+Confirm the rollback plan is documented and includes:
+- Trigger criteria (what conditions invoke rollback)
+- Who has authority to invoke rollback (named individual, not just a role)
+- Step-by-step rollback sequence
+- Estimated rollback duration
+- Data integrity approach during rollback (snapshot, backup, point-in-time
+  restore)
+
+**Step 4.2 — Rollback rehearsal confirmation**
+Confirm that the rollback has been rehearsed in the sandbox. d365-data-migration-
+cutover-agent attests:
+- Rollback was executed in the sandbox
+- Rollback completed within the estimated duration
+- System was returned to a known good state after rollback
+
+If the rollback has not been rehearsed: stop. Require rehearsal before the real
+cutover is authorised.
+
+---
+
+### Phase 5: Gate 2 — Rollback Tested
+
+**Required confirmation:**
+- d365-data-migration-cutover-agent confirms rollback rehearsal completed
+  within the cutover window.
+- Project lead confirms rollback authority is assigned to a named individual
+  who is available during the cutover window.
+
+---
+
+### Phase 6: Separation of Duties Validation
+
+**Step 6.1 — Production security role review**
+d365-security-sod-governance-agent reviews all security role assignments planned
+for production go-live:
+- Identify any SoD conflicts (e.g. a user who can both create and approve
+  purchase orders, or both post and reconcile financial transactions)
+- Flag conflicts to the security and business owners
+- Require remediation or compensating controls before go-live
+
+**Step 6.2 — SoD sign-off**
+Security owner and business process owner confirm that SoD conflicts are
+remediated or compensating controls are documented and accepted.
+
+---
+
+### Phase 7: SbD Go-live Gate
+
+**Step 7.1 — Success by Design go-live readiness review**
+d365-success-by-design-governance-agent runs the SbD go-live readiness review
+against the full go-live checklist:
+
+| Checklist area | Status |
+|---|---|
+| Solution scope aligned with stakeholders | signed-off / not-signed-off |
+| UAT complete and signed off | signed-off / not-signed-off |
+| System integration testing complete | signed-off / not-signed-off |
+| Performance testing complete | signed-off / not-signed-off |
+| Data migration readiness (mock + reconciliation) | signed-off / not-signed-off |
+| External dependencies aligned | signed-off / not-signed-off |
+| Change management complete | signed-off / not-signed-off |
+| Production environment ready | signed-off / not-signed-off |
+| Cutover plan complete | signed-off / not-signed-off |
+| Rollback plan tested | signed-off / not-signed-off |
+| Operational support plan ready | signed-off / not-signed-off |
+| Security and SoD validated | signed-off / not-signed-off |
+
+**Step 7.2 — SbD verdict**
+- **Go**: all checklist items signed off.
+- **Conditional-go**: minor open items with owner-committed resolution dates
+  and business acceptance.
+- **No-go**: one or more blocking issues remain.
+
+---
+
+### Phase 8: Gate 3 — SbD Go-live Gate Sign-off
+
+**Required sign-off:**
+- d365-success-by-design-governance-agent issues the SbD verdict.
+- Project steering committee formally confirms the go/no-go decision.
+- Microsoft FastTrack (where applicable) confirms go-live readiness.
+
+This protocol never issues the final go/no-go decision. That decision belongs
+to the human project steering committee.
+
+---
+
+### Phase 9: Cutover Execution Readiness
+
+**Step 9.1 — People readiness**
+Confirm that all required personnel are available during the cutover window:
+- Data migration owner
+- Integration owner
+- Rollback authority
+- Production environment owner
+- Business process lead
+- Support team lead
+
+**Step 9.2 — Communication plan**
+Confirm the communication plan is active: stakeholders are notified, cutover
+start/stop messages are drafted, escalation contacts are confirmed.
+
+**Step 9.3 — Final production environment check**
+Confirm production environment version matches development/test. Confirm no
+in-flight platform updates are scheduled during the cutover window.
+
+---
+
+### Phase 10: Post-Cutover Validation
+
+After go-live:
+- Confirm data accuracy in production (spot-check reconciliation)
+- Confirm integration health (all integration endpoints responding)
+- Confirm user access is functional (security roles are assigned and working)
+- Invoke hypercare plan
+
+---
+
+## Decision Tree
+
+```
+Cutover requested
+  └── Mock cutover completed?
+        ├── No  → Stop; require mock cutover
+        └── Yes → Critical issues resolved?
+                    ├── No  → Require second mock; stop
+                    └── Yes → Mock completed within cutover window?
+                                ├── No  → Revise cutover plan; stop
+                                └── Yes → Reconciliation thresholds met?
+                                            ├── No  → Resolve exceptions; stop
+                                            └── Yes → Gate 1 sign-off obtained?
+                                                          ├── No  → Stop
+                                                          └── Yes → Rollback rehearsed?
+                                                                        ├── No  → Require rehearsal; stop
+                                                                        └── Yes → Gate 2 sign-off obtained?
+                                                                                      ├── No  → Stop
+                                                                                      └── Yes → SoD conflicts resolved?
+                                                                                                    ├── No  → Require remediation; stop
+                                                                                                    └── Yes → SbD checklist complete?
+                                                                                                                  ├── No  → Resolve blocking items; stop
+                                                                                                                  └── Yes → Gate 3 steering committee sign-off
+                                                                                                                                └── Human go/no-go decision
+```
+
+---
+
+## Output Contract
+
+### Cutover readiness record
+| Field | Type | Description |
+|---|---|---|
+| project_id | string | Dynamics 365 implementation project identifier |
+| skill_id | string | `erp-crm-cutover-protocol` |
+| skill_version | string | `0.1.0` |
+| invoked_by | string | Agent or human who invoked this protocol |
+| mock_cutover_status | enum | pass / fail / not-run |
+| mock_timing_within_window | boolean | Whether mock completed within planned window |
+| gate_1_reconciliation | enum | signed-off / not-signed-off |
+| gate_2_rollback_tested | enum | confirmed / not-confirmed |
+| sod_validation_status | enum | pass / conflicts-open / remediated |
+| sbd_verdict | enum | go / conditional-go / no-go |
+| gate_3_steering_committee | enum | signed-off / not-signed-off |
+| open_issues | array | Unresolved issues with owners and target dates |
+| do_not_do_list | array | Actions excluded from this protocol's scope |
+| rollback_status | enum | tested / not-tested / authority-assigned |
+| timestamp | ISO 8601 | Protocol execution timestamp |
+
+### Gate verdicts
+| Gate | Verdict options |
+|---|---|
+| Reconciliation sign-off (Gate 1) | signed-off / not-signed-off |
+| Rollback tested (Gate 2) | confirmed / not-confirmed |
+| SbD go-live gate (Gate 3) | signed-off / not-signed-off |
+
+### Refusal record (when triggered)
+| Field | Description |
+|---|---|
+| refusal_reason | Which refusal trigger was hit |
+| escalation_target | Data owner / security owner / project lead / FastTrack |
+| timestamp | ISO 8601 |
+
+---
+
+## Quality Assurance Notes
+- This protocol never executes migration scripts, production deployments, or
+  environment configurations. All execution steps require the infrastructure
+  or project owner.
+- The go/no-go decision is always made by the human project steering committee.
+  d365-success-by-design-governance-agent issues a recommendation, not a
+  decision.
+- All gate sign-offs must include the named decision-maker, the date, and a
+  statement of accepted residual risk.
+- Rollback plans that have not been rehearsed in a sandbox are a hard block
+  on the cutover recommendation with no exceptions.

package/skills/cross-functional/field-service-to-cash-protocol/SKILL.md

@@ -0,0 +1,99 @@
+---
+name: field-service-to-cash-protocol
+description: Use this skill to orchestrate the field service to cash process (service to deliver) across Dynamics 365 Field Service and Dynamics 365 Finance, covering work order creation through service delivery, parts and inventory consumption, invoicing, and accounts receivable settlement. The skill defines stage gates, agent handoff rules, and escalation triggers so that service work is verified before invoicing, inventory is accurately consumed, and revenue is recognized correctly. It does not create or modify work orders, post invoices, approve service completions, or access field engineer credentials; all production-impacting steps are escalated to the relevant specialist or human owner.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-16"
+  category: operational
+  lifecycle: experimental
+---
+
+# Field Service to Cash Protocol
+
+## Purpose
+This skill orchestrates the field service to cash process (referred to as "service to deliver" in the Microsoft Dynamics 365 business process catalog) in Dynamics 365 environments. It coordinates Dynamics 365 Field Service (work order management, scheduling, service delivery, and inventory consumption) with Dynamics 365 Finance (invoicing, accounts receivable, and cash application). The protocol ensures that service is verified as delivered before invoicing, that parts consumed are accurately recorded against inventory, and that revenue is recognized in the correct period. It does not give field service configuration or financial accounting advice; all recommendations are subject to human owner confirmation.
+
+## When to use
+- A field service work order must progress from creation through scheduling, delivery, parts consumption, invoicing, and payment.
+- Inventory consumed during field service must be reconciled with accounts in Dynamics 365 Finance.
+- A service agreement with recurring invoicing requires coordination between Field Service and Finance.
+- A work order completion must be verified before an invoice is generated or posted.
+- A cross-module discrepancy between field service actuals and financial postings needs investigation.
+
+## When NOT to use
+- The matter is confined entirely to work order scheduling with no financial impact — route to the Field Service specialist.
+- The matter involves project-based billing from Dynamics 365 Project Operations — use the appropriate project-to-profit process.
+- The matter is a warranty claim or service contract renewal without an active work order — escalate to the Field Service and finance owners.
+- Direct Field Service or Finance configuration is required — route to the relevant specialist agent.
+
+## Participating agents
+- d365-field-service-to-cash-agent — owns work order creation, scheduling, service delivery confirmation, and inventory consumption in Dynamics 365 Field Service
+- d365-finance-close-to-report-agent — owns invoicing, accounts receivable, revenue recognition, and cash application in Dynamics 365 Finance
+
+## Inputs required
+- Work order number and customer account
+- Service type and scope of work
+- Assigned field technician and scheduled date
+- Parts and inventory items required for the work order
+- Applicable service agreement or contract reference
+- Billing method (time and materials, fixed price, or agreement invoice)
+
+## Evidence required
+- Work order completion confirmation from the field technician in Dynamics 365 Field Service
+- Parts consumed and labor time recorded on the work order
+- Customer sign-off or work order closure approval (if required by contract)
+- Inventory adjustment confirmation for parts consumed
+- Invoice draft validated against work order actuals before posting
+
+## Workflow
+1. Receive work order creation trigger; validate that customer account, service scope, and billing method are defined.
+2. Confirm that required parts are available in the assigned inventory location (warehouse or technician's truck stock).
+3. Schedule and dispatch field technician via Dynamics 365 Field Service scheduling board; record assignment.
+4. Monitor work order progress; flag overdue work orders to the field service owner.
+5. Upon service completion, verify that the technician has recorded all labor time and parts consumed on the work order.
+6. Work order verification gate: confirm the work order is marked as "Complete" in Dynamics 365 Field Service; if customer sign-off is required, confirm it is recorded.
+7. Trigger inventory adjustment for consumed parts; confirm inventory levels are updated in the system.
+8. Hand work order actuals (labor, parts, travel) to d365-finance-close-to-report-agent for invoice creation.
+9. Create invoice draft in Dynamics 365 Finance; validate against work order actuals and applicable service contract pricing.
+10. Invoice accuracy gate: surface discrepancies between invoice draft and work order actuals for human resolution before posting.
+11. Post the invoice; open an accounts receivable entry with the correct payment terms.
+12. Monitor payment due date; surface collection activities to the finance owner as needed.
+13. Apply cash receipt to the open invoice; close accounts receivable entry.
+
+## Decision gates
+| Gate | Condition | Action if not met |
+|---|---|---|
+| Parts availability | Required parts in stock at assigned location | Notify d365-field-service-to-cash-agent; arrange parts transfer or order |
+| Work order completion | Work order marked complete in Dynamics 365 Field Service | Do not proceed to invoicing; return to field service agent |
+| Customer sign-off | Sign-off recorded if required by contract | Hold invoice; await confirmation |
+| Inventory adjustment | Consumed parts reflected in inventory system | Hold invoice; resolve inventory discrepancy first |
+| Invoice accuracy | Invoice matches work order actuals and contract pricing | Hold posting; flag for human resolution |
+| Cash application | Payment matched to invoice | Do not auto-close AR entry on partial payment without finance owner approval |
+
+## Refusal triggers
+- Invoice is requested for a work order that is not yet marked as "Complete" — refuse.
+- Inventory adjustment is requested without a corresponding work order consumption record — refuse.
+- Customer PII, field technician credentials, or service agreement financial terms are included in any input — stop; redact and escalate.
+- A live invoice or AR entry modification is requested without human authorization — refuse.
+- A backdated work order completion or invoice date is requested — refuse; escalate to the field service and finance owners.
+
+## Handoff rules
+- d365-field-service-to-cash-agent provides a work order actuals summary (labor, parts, travel) to d365-finance-close-to-report-agent before any invoice is created.
+- Every handoff carries a capsule: matter_id, work_order_id, current_stage, gate_outcomes, open_questions, do_not_do_list.
+- No invoice is posted without a verified work order completion record.
+- All escalations are logged with trigger, timestamp, and receiving owner.
+
+## KPIs
+- Work order to invoice cycle time
+- First-time fix rate (work orders completed without return visits)
+- Invoice accuracy rate (first-pass match to work order actuals)
+- Days sales outstanding for field service invoices
+- Inventory accuracy rate for field service consumption
+
+## References
+- [Service to deliver end-to-end overview — Dynamics 365](https://learn.microsoft.com/dynamics365/guidance/business-processes/service-to-cash-areas-overview)
+- [Overview of Dynamics 365 Field Service](https://learn.microsoft.com/dynamics365/field-service/overview)
+- [Set up agreements to automatically generate invoices — Dynamics 365 Field Service](https://learn.microsoft.com/dynamics365/field-service/set-up-agreements-invoices)
+- [Streamline service delivery and invoicing — service to deliver end-to-end](https://learn.microsoft.com/dynamics365/guidance/business-processes/service-to-cash-introduction)

package/skills/cross-functional/field-service-to-cash-protocol/metadata.json

@@ -0,0 +1,19 @@
+{
+  "id": "field-service-to-cash-protocol",
+  "name": "Field Service to Cash Protocol",
+  "type": "skill",
+  "provider": "generic",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Orchestration protocol for the field service to cash (service to deliver) process in Dynamics 365 environments, coordinating Field Service (work order management, scheduling, service delivery, and inventory consumption) with Finance (invoicing, accounts receivable, and cash application). Defines stage gates for work order completion, inventory adjustment, and invoice accuracy, with structured handoffs between d365-field-service-to-cash-agent and d365-finance-close-to-report-agent. Ensures service is verified complete before invoicing and that parts consumed are accurately reflected in inventory and financial records.",
+  "source_type": "original",
+  "official_docs": [
+    "https://learn.microsoft.com/dynamics365/guidance/business-processes/service-to-cash-areas-overview",
+    "https://learn.microsoft.com/dynamics365/field-service/overview",
+    "https://learn.microsoft.com/dynamics365/field-service/set-up-agreements-invoices"
+  ],
+  "security_notes": "This protocol is a recommendation and orchestration guide only — it is never an authorization to create or close work orders, post invoices, approve service completions, modify inventory records, or execute live financial transactions. All production-impacting steps require confirmation by the relevant human owner or specialist agent. The protocol never requests customer PII, field technician credentials, service contract financial terms with customer-specific pricing, or Dynamics 365 tenant IDs. Invoicing for incomplete work orders and backdated work order completions are explicitly refused. Inventory adjustments without corresponding work order consumption records are refused.",
+  "last_verified": "2026-06-16",
+  "path": "skills/cross-functional/field-service-to-cash-protocol",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/cross-functional/field-service-to-cash-protocol/references/workflow-and-output.md

@@ -0,0 +1,206 @@
+# Field Service to Cash Protocol — Workflow and Output Contract
+
+## Overview
+This document provides the detailed step-by-step workflow, decision tree, and output contract for the field-service-to-cash-protocol skill. It covers the complete service-to-deliver cycle from work order creation through cash application in Dynamics 365 Field Service and Finance.
+
+---
+
+## Detailed Step-by-Step Workflow
+
+### Phase 1 — Work Order Initialization (d365-field-service-to-cash-agent)
+
+**Step 1.1 — Work order creation and validation**
+- Receive the service request and create a work order in Dynamics 365 Field Service.
+- Confirm that the following are populated: customer account, service type, scope of work, billing method (time and materials, fixed price, or agreement invoice), and applicable service agreement reference.
+- If any required field is missing, surface the gap to the human owner before proceeding.
+
+**Step 1.2 — Parts and resource requirements**
+- Identify required parts, materials, and specialist skills for the work order.
+- Check inventory availability at the nearest warehouse or the technician's truck stock.
+- If required parts are not available, trigger a parts transfer or purchase order request; do not schedule the work order for a date when parts will not be available.
+
+**Step 1.3 — Service agreement check**
+- If the work order is covered by a service agreement or maintenance plan, validate that the agreement is active and the work type is within scope.
+- For agreement-based billing, confirm the invoice generation schedule and pricing from the agreement record.
+
+---
+
+### Phase 2 — Scheduling and Dispatch (d365-field-service-to-cash-agent)
+
+**Step 2.1 — Technician scheduling**
+- Use the Dynamics 365 Field Service scheduling board to assign a qualified technician with the required skills.
+- Confirm the scheduled date, estimated duration, and travel requirements.
+- Record the assignment in the work order.
+
+**Step 2.2 — Work order communication**
+- The scheduling details are available to the technician via the Field Service mobile application.
+- Do not communicate customer site addresses or personal contact details outside of the configured Field Service channel.
+
+---
+
+### Phase 3 — Service Delivery (d365-field-service-to-cash-agent)
+
+**Step 3.1 — Service execution monitoring**
+- Monitor work order status as the technician performs the service.
+- Flag work orders that exceed the estimated duration or have not been updated past the scheduled completion time.
+
+**Step 3.2 — Labor and parts recording**
+- Technician records all labor time (including travel if billable), parts consumed, and any additional work performed on the work order in Dynamics 365 Field Service.
+- Parts consumed are posted as inventory usage; inventory levels in the assigned location are updated automatically.
+
+**Step 3.3 — Work order completion**
+- Technician marks the work order as "Complete" in Dynamics 365 Field Service.
+- If customer sign-off is required by the service contract, confirm that the customer signature or approval is recorded before closing the work order.
+
+**Work order verification gate:**
+- d365-field-service-to-cash-agent confirms the work order is in "Complete" status with all labor, parts, and customer sign-off (if required) recorded.
+- If any item is missing, the work order remains open; invoicing does not proceed.
+
+---
+
+### Phase 4 — Inventory Reconciliation (d365-field-service-to-cash-agent)
+
+**Step 4.1 — Inventory adjustment confirmation**
+- Confirm that parts consumed on the work order have been reflected as inventory usage transactions in the system.
+- Reconcile the parts list on the work order against the inventory adjustment records.
+- Any discrepancy between work order parts and inventory records must be resolved before invoicing.
+
+**Step 4.2 — Return of unused parts**
+- If parts were issued for the work order but not consumed, confirm that return-to-warehouse transactions are posted.
+- Unused parts must not remain on the work order as consumed.
+
+---
+
+### Phase 5 — Invoice Creation and Posting (d365-finance-close-to-report-agent)
+
+**Step 5.1 — Work order actuals handoff**
+- d365-field-service-to-cash-agent provides a structured work order actuals summary to d365-finance-close-to-report-agent:
+  - Labor hours (regular, overtime, travel)
+  - Parts consumed with unit prices
+  - Any additional charges
+  - Customer and work order references
+
+**Step 5.2 — Invoice draft creation**
+- d365-finance-close-to-report-agent creates a draft invoice in Dynamics 365 Finance.
+- Invoice lines are validated against the work order actuals and the applicable service contract pricing.
+- Tax codes, payment terms, and customer billing address are confirmed.
+
+**Invoice accuracy gate:**
+- Any discrepancy between the invoice draft and work order actuals, or between invoice pricing and contract rates, triggers a hold.
+- The discrepancy is surfaced to d365-field-service-to-cash-agent and the human owner for resolution.
+- Do not post the invoice until the accuracy gate is passed.
+
+**Step 5.3 — Invoice posting**
+- Human owner confirms the invoice for amounts above the configured materiality threshold.
+- Invoice is posted in Dynamics 365 Finance; accounts receivable entry is opened.
+- Invoice is delivered to the customer via the configured channel (email, portal, or printed copy).
+
+---
+
+### Phase 6 — Collections and Cash Application (d365-finance-close-to-report-agent)
+
+**Step 6.1 — Payment monitoring**
+- Monitor the accounts receivable aging for the field service invoice.
+- At configured intervals, surface recommended collection activities to the finance owner.
+- Do not contact the customer directly.
+
+**Step 6.2 — Cash application**
+- Upon payment receipt, apply cash to the matching invoice in Dynamics 365 Finance.
+- Partial payments are flagged to the finance owner; do not auto-close the AR entry.
+
+**Step 6.3 — Settlement and close**
+- Fully settled invoices are closed; work order revenue is recorded.
+- Update the field service performance metrics in d365-field-service-to-cash-agent.
+
+---
+
+## Decision Tree
+
+```
+START: Service request received
+│
+├─ Work order fields complete (account, scope, billing method)?
+│   └─ NO → SURFACE to human owner; do not proceed
+│
+├─ Required parts available at assignment location?
+│   └─ NO → TRIGGER parts transfer or PO; do not schedule before parts confirmed
+│
+├─ Service agreement active and work type in scope?
+│   └─ NO → ESCALATE to field service and finance owners
+│
+├─ Work order marked "Complete" in Field Service?
+│   └─ NO → DO NOT proceed to invoicing
+│
+├─ Customer sign-off recorded (if required)?
+│   └─ NO → HOLD; await sign-off
+│
+├─ Inventory adjustment confirmed for consumed parts?
+│   └─ NO → RESOLVE discrepancy before invoicing
+│
+├─ Invoice accurate (matches actuals and contract pricing)?
+│   └─ NO → HOLD; route to field service agent and human owner
+│
+├─ Invoice above materiality threshold?
+│   └─ YES → REQUIRE human approval before posting
+│
+├─ Payment received in full?
+│   └─ NO (partial) → FLAG to finance owner; do not auto-close AR
+│
+└─ Invoice settled?
+    └─ YES → CLOSE AR; update field service performance metrics
+```
+
+---
+
+## Output Contract
+
+Every execution of this protocol produces a structured output capsule:
+
+| Field | Type | Description |
+|---|---|---|
+| matter_id | string | Unique identifier for this field service to cash instance |
+| work_order_id | string | Dynamics 365 Field Service work order number |
+| current_stage | enum | One of: work_order_created, scheduled, in_progress, completed, inventory_reconciled, invoice_created, invoiced, collections, closed |
+| gate_outcomes | object | Pass/fail/escalated: parts_availability, work_order_completion, customer_signoff, inventory_adjustment, invoice_accuracy, cash_application |
+| agents_involved | array | Agent IDs that participated |
+| escalations | array | Each escalation: {trigger, timestamp, escalated_to, reason} |
+| open_questions | array | Unresolved items requiring human input |
+| do_not_do_list | array | Actions explicitly prohibited in the current state |
+| evidence_quality | enum | high / medium / low |
+| privilege_sensitivity | boolean | True if service contract contains commercially sensitive pricing |
+| last_updated | ISO8601 timestamp | When the capsule was last updated |
+
+### Example output capsule (partial)
+```json
+{
+  "matter_id": "FSC-2026-005678",
+  "work_order_id": "WO-20260345",
+  "current_stage": "invoiced",
+  "gate_outcomes": {
+    "parts_availability": "pass",
+    "work_order_completion": "pass",
+    "customer_signoff": "pass",
+    "inventory_adjustment": "pass",
+    "invoice_accuracy": "pass",
+    "cash_application": "pending"
+  },
+  "agents_involved": [
+    "d365-field-service-to-cash-agent",
+    "d365-finance-close-to-report-agent"
+  ],
+  "escalations": [],
+  "open_questions": ["Payment due 2026-06-30; monitoring AR aging"],
+  "do_not_do_list": [
+    "Do not auto-close AR entry on partial payment",
+    "Do not modify posted invoice without human authorization"
+  ],
+  "evidence_quality": "high",
+  "privilege_sensitivity": false,
+  "last_updated": "2026-06-16T14:45:00Z"
+}
+```
+
+---
+
+## Audit Log Fields
+- matter_id, skill_id, skill_version, invoked_by, work_order_id, input_hash, evidence_quality, output_verdict, escalation_fired, timestamp