Cross-system Data Linkage for Events, Finance, and Assets

Local implementation status and release boundary

This guide is the operator contract for cross-system linkage. The paired implementation is complete locally, with release gates pending. Local source, disposable-database, API-contract, dashboard-fixture, and EMS LAN runtime evidence now covers shared identities and crosswalks, Finance coding proposals, EPS procurement, Finance goods-receipt intake, logistics and maintenance cost handoffs, first-party AssetManage-to-FinManage journal posting and receipts, durable-asset deployments, offline commands, measured double-entry reduction, and the actionable integrity queue.

The migrations, private API, dashboard, and EMS LAN package are not deployed by this work. Hosted multi-role authentication, real production/provider data, physical devices and venue LAN, an authorized canary, deployed rollback/restore, and operator, security, and Finance sign-off remain release gates.

Do not retire an existing manual control or represent a linked workflow as production-ready until its database, API, dashboard, offline, reconciliation, and recovery evidence reaches the required certification level. Fixture values and local screenshots prove only the named local scenario.

Source and paired delivery work

• Cross-system data-entry and linkage audit — source findings and recommended boundaries.
• Dashboard TASK060 — Cross-System Operations Data Linkage — linked-record surfaces and operator actions.
• API TASK041 — Cross-System Data Linkage API and Projections — typed relationships, commands, receipts, and tenant controls.
• EMS LAN TASK026 — EMS–AMS Durable Asset Deployment Sync — offline manifest, scan, command, receipt, and reconciliation behavior.
• docs.furries.ph TASK023 — this documentation program, its evidence gates, and final claim sweep.

Current local implementation surfaces

• Dashboard: /operations-linkage, with queue, links, deployments, finance, shared, and timeline tabs.
• Embedded context: LinkedWorkPanel appears on EMS event, EPS planning, FinManage, and AssetManage layouts. It names the owning system, relationship, lifecycle/version, live-versus-snapshot rule, owner deep link, and a route back to Linked Operations.
• Private API root: /api/partners/{partnerId}/operations-linkage.
• Read families: access, metrics, coverage, links, links/candidates, parties, places, dimensions, finance/dimension-policies, deployments, deployments/{deploymentId}/substitutions, finance/coding-proposals, finance/ems-sources, finance/ems-reconciliation, procurement, intakes, finance/cost-handoffs, finance/asset-mappings, finance/asset-batches, finance/postings, exceptions, exceptions/{exceptionId}/retry-preview, exceptions/{exceptionId}/fix-preview, receipts, search, and timeline.
• Command families: reviewed link actions; effective-dated shared party/place/dimension creation, transition, crosswalk creation, and review; Finance dimension-policy review; deployment creation, lifecycle actions, governed exception approval, and independently reviewed substitution proposals; digest-bound EMS annotation review and Finance coding proposals; EPS procurement creation/cancellation; Finance goods-receipt intake and immutable inspection/correction disposition; shipment, maintenance, damage, agreement/rental, and consumable-allocation cost handoffs; AssetManage mapping, posting, reversal/replacement, and reconciliation; and typed exception creation, retry, immutable bound fix, and completion actions.

All API routes require an authenticated active partner and capability checks. Every current mutating family delegates to an atomic database command RPC that commits mutable domain state and its immutable action receipt in one transaction. This includes shared-identity maker-checker transitions through partner_cross_system_transition_identity, reviewed crosswalks, deployments, substitution review and durable-asset movements, coding proposals, procurement, intakes, cost handoffs, first-party journal posting/reconciliation, and exception creation/transitions/bound fixes. The local certification also rejects direct service-table writes for these workflows.

Final dashboard and API request/response contracts

The dashboard and Worker use the following mounted DTOs. These field names are the local source contract; do not restore the older generic record, disposition, or nested source.reference response shapes.

Workflow	Final request fields	Final read/write response and operator check
EPS procurement	sourceType, sourceId, partner-owned planningProjectId, objective, positive quantity, non-empty unitOfMeasure, non-negative estimatedAmount, three-letter currency, optional neededBy, matching optional eventId, and active Finance dimensionIds	A write returns procurement, financeRecord, link, actionReceipt, and replayed. A read item exposes item.procurement, item.financeRecord, item.downstream, and item.readiness; the dashboard renders item.procurement.objective and the Finance-owned amount from item.financeRecord.grossAmount.
Finance receipt to AMS intake	financeGoodsReceiptId, the selected financeGoodsReceiptLineId (goodsReceiptLineId is the accepted API alias), and classification of controlled or capitalizable	A write returns intake, goodsReceipt, acquisition, link, actionReceipt, and replayed. Read the operational state from item.intake.status; do not infer it from the acquisition or receipt status. Inspection actions carry expected version, accepted/quarantined/rejected quantities, reason, and a new idempotency key.
AMS cost handoff to Finance	flowType, sourceType, partner-owned sourceId, allowed handoffType, title, non-negative amount, three-letter currency, optional dueOn, optional matching eventId, optional Finance counterpartyId, and active dimensionIds	A write returns handoff, financeRecord, link, actionReceipt, and replayed. Read status and source detail from item.handoff.*, including item.handoff.handoffType, item.handoff.amount, settledAmount, currency, status, sourceSnapshot, and version; the linked Finance amount remains item.financeRecord.grossAmount.

All three writes require the active partner, the route-specific capabilities, and an idempotency key. The API validates partner/event/project ownership, effective Finance dimensions, source digest, dates, currency, and numeric bounds before the atomic command runs. Retrying the same key with the same payload returns the original receipt; reusing it for changed content conflicts. The decimal request values are proposals or source amounts until Finance accepts them; a rendered number does not replace the Finance record.

Typed relationship envelope and verification

Every relationship uses an allowlisted sourceSystem/sourceType to targetSystem/targetType plus relationshipType combination. The API resolves both UUID endpoints inside the active partner before it accepts a proposed link. The returned envelope carries schemaVersion, endpoint IDs, optional event/project scope, lifecycle state, targetDisposition, source and expected-target versions, sourceDigest, payload digest, idempotency key, correlation ID, immutable sourceSnapshot and targetSnapshot, a display snapshot, approver data, lastVerifiedAt, and link version.

The endpoint snapshots freeze what was linked; they are not editable mirrors of the current owner records. Use the linked-record detail’s live source and target panels plus freshness timestamps for current values. Approval rechecks maker-checker separation, expected link version, same-partner ownership, and recent authentication for Finance or AssetManage endpoints. Lifecycle transitions derive the target disposition: active/resolved means accepted, rejected means rejected, superseded means replaced, stale means stale, and revoked means unavailable. An active or resolved transition records lastVerifiedAt; later owner changes require revalidation, staleness, replacement, or a new linked correction rather than snapshot editing.

Measured double-entry reduction

The Finance handoffs tab reads permission-trimmed /metrics results with an asOf cutoff generated by the database at query time. The current source exposes these point-in-time definitions:

Metric	Current calculation	Safe interpretation
generatedRecords	Partner-scoped counts of procurement rows, asset-intake rows, Finance-handoff rows, and AssetManage batch links that already name a Finance journal	Records created through the linked contract, not proof that every downstream lifecycle is complete
estimatedFieldsAvoided	7 × procurementRequests + 12 × assetIntakes + 5 × financeHandoffs	A documented proxy for fields carried forward by the current DTOs, not observed keystrokes, labor savings, or audited money saved
unmatched.emsFinanceSources	EMS accounting source entries with no same-partner Finance source link	Source coverage gap at asOf
unmatched.assetBatches, openIntakes, openHandoffs, openExceptions	Exported/accepted batches without accepted or reconciled Finance links, plus rows outside each source-defined final-state allowlist	Actionable backlog; inspect owner state before deciding materiality
duplicates.partyCandidates and duplicates.placeCandidates	Same-partner shared identity rows still in candidate state under the source rules	Review candidates, not confirmed duplicates
coverage.assetBatchAcceptancePercent	Accepted or reconciled AssetManage batch links divided by all partner batch links	Acceptance coverage, with zero returned for an empty denominator
coverage.deploymentReturnPercent	Reconciled event deployments divided by all partner deployments	Return/reconciliation coverage, with zero returned for an empty denominator

Permission trimming returns null, not zero, when the actor cannot view every contributing system. The current endpoint does not measure cycle time, actual manual keystrokes, or realized financial savings; do not infer those values from the proxy. Investigate the underlying queue before interpreting a count as a completed or failed business process.

Structured operational telemetry

/coverage is the source-backed operational telemetry view, separate from the baseline proxy above. It returns a permission-trimmed asOf envelope with link totals, open/material/assigned/overdue exception counts, per-flow linked/stale/missing counts, open/in-transit/missing-return/reconciled deployment counts, and projection coverage. Its observability object reports projectionLagSeconds, retryAttempts, digestDriftCount, quarantineOpen, oldestQuarantineAgeSeconds, duplicateCandidates, reconciliationCoveragePercent, and queueResolutionPercent; projections reports EMS-to-Finance coverage, AssetManage batch acceptance, and last successful/failed timestamps. These are bounded operational counters from current partner-visible rows, not a tracing backend, SLA proof, or production health claim.

The operating rule: enter once, link everywhere else

The target is not one oversized record shared by every product. Each fact has one owner. Other systems keep a stable typed link and show the current authoritative value or an immutable snapshot when an accounting or audit record must preserve history.

A linked panel must tell the operator:

• which system owns the record;
• whether the value is live, a local planning target, an approval snapshot, or an offline projection;
• the partner and event scope;
• the linked record type, status, owner, due date, amount or quantity when authorized;
• the source version/digest and latest command or receipt state;
• the last accepted projection and latest safe error;
• where to open the owning record; and
• which correction or exception action is allowed.

The default action is search and link. Create a new party, place, purchase, asset intake, or deployment only when no valid same-partner record exists.

Authoritative ownership matrix

Record or decision	Authoritative owner	Other systems may do	Other systems must not do
Event identity, public/internal name, schedule, timezone	EMS	EPS links planning work; Finance and AMS use event scope	Create a second event identity or silently overwrite EMS
Attendee configuration, tiers, inclusions, add-ons, shop and event sales sources	EMS	EPS attaches work or proposes reviewed changes; Finance consumes source evidence	Maintain a duplicate attendee catalog
Plans, requirements, assignments, risks, readiness, gates and handoff	EPS	EMS, Finance, and AMS expose linked status/evidence	Treat a completed plan item as proof that owner-system work completed
Partner general ledger, accounts, dimensions, budgets, commitments, procurement, payables, receivables and close	Finance Management, also called FinManage	EMS and AMS submit controlled sources; EPS reads approved financial state	Directly edit posted journal truth or copy a payable into another ledger
Durable assets, tags, custody, condition, persistent locations, containers, shipments, maintenance and asset subledger	Asset Management, also called AssetManage or AMS	EPS reads readiness; EMS renders event deployment; Finance accepts controlled postings	Recreate a durable asset as EMS inclusion/add-on stock
Event sellable, entitlement and event-day stock movements	EMS	Finance consumes accounting effects; AMS may supply a linked reusable item	Synchronize all event stock into AMS
Offline event operation	EMS LAN as a temporary event-scoped projection	Capture approved commands and later apply canonical receipts	Become an independent authority or double-post stock/finance effects
Uploaded evidence bytes	API-owned Sanity media boundary	Systems link opaque artifact IDs and retain their own evidence purpose	Expose direct Sanity API/CDN URLs or upload the same file repeatedly

Display labels

Use these labels consistently:

Label	Meaning
Managed in EMS	The current attendee/event operational record is edited in EMS.
Managed in EPS	The plan, requirement, assignment, readiness or approval is edited in EPS.
Managed in Finance	The accounting, procurement, settlement or close record is edited in Finance Management.
Managed in Asset Management	The durable asset, custody, shipment, location, condition or subledger record is edited in AMS.
Snapshot at approval	The value is intentionally frozen for audit and does not replace the live source.
Local planning target	The value is an EPS target or estimate, not a published EMS or posted Finance result.
Offline pending	EMS LAN has captured intent but the authoritative online system has not accepted it.

Shared identities and crosswalks

Event and planning identity

EMS owns the event. EPS links one planning project to that event and keeps planning-only overlays. Editing an EMS-owned value through EPS uses the canonical command/change-set path; it does not synchronize two copies.

Party identity

A shared party or reviewed crosswalk connects the same supplier, carrier, service provider, lender, insurer, borrower, staff member, sponsor, customer, or payee to its Finance and AMS profiles. Matching must use reviewed identifiers and context. A similar name alone is not proof of identity.

Before merging or replacing a crosswalk:

1. Scope check — Confirm both records belong to the active partner.
2. Identity check — Compare approved identifiers, contact/evidence, role and existing transactions.
3. Impact check — Review purchases, invoices, shipments, custody, agreements, journals and audit snapshots.
4. Independent review — Require the configured reviewer for a high-impact merge.
5. Correction — Replace the crosswalk through a versioned command; never rewrite immutable historical snapshots.

Place identity

A shared physical place identifies a warehouse, venue, office, yard, loading dock, vehicle, or external site. AMS keeps persistent capacity, security and environmental overlays. EMS keeps event/LAN location behavior. A temporary event-only desk may remain EMS-only; it is not forced into the persistent place registry.

Accounting dimensions

Finance owns cost center, fund, program/department, activity, project/event, grant and other posting dimensions. EPS and AMS select stable dimension IDs and may preserve the approved code/name snapshot. Free-text codes cannot become a second dimension authority.

Dimension identities are partner-scoped, versioned, and effective-dated with effectiveFrom and optional effectiveTo. A candidate identity requires an independent maker-checker transition before it becomes active; the maker cannot approve their own candidate. Superseding an active dimension records the replacement and preserves prior usage and snapshots.

Finance dimension policies separately bind an optional event and one operation (procurement, asset_handoff, asset_batch, or ems_coding) to a named policyVersion, up to eight required axes, and effective dates. The policy maker cannot review their own proposal. Approval, rejection, or supersession requires expected version, reason, idempotency, and an immutable receipt. Procurement, cost handoff, asset-batch, and EMS-coding commands must submit active/effective dimension IDs and the applicable policy version; a stale, missing, out-of-window, or cross-partner dimension blocks the write.

Required axes are governed slugs, not a closed list. Finance may use the common axes above or define a custom axis whose name begins with a lowercase letter, continues only with lowercase letters, digits, or underscores, and is 2–80 characters long. A policy may require at most eight unique axes. Each submitted map key must exactly match the active dimension identity’s dimensionType and its value must be that same-partner dimension’s UUID; arbitrary free-text dimension values are never accepted. cost_center maps to the dashboard’s costCenter request field, while every other custom key remains its named policy axis.

Evidence identity

One opaque artifact can be linked to a Finance receipt, AMS intake or work order, EPS gate and EMS operation. Each link retains its purpose, access policy, retention class and audit history. Posted financial evidence may retain an immutable snapshot even if the source artifact is later superseded.

Cross-system lifecycle

flowchart LR
  EMS["<b>EMS</b><br/>Event and operational sources"] -->|canonical event ID| EPS["<b>EPS</b><br/>Plan, requirements and readiness"]
  EPS -->|request or typed link| FIN["<b>Finance</b><br/>Budget, procurement and GL"]
  FIN -->|accepted receipt line| AMS["<b>Asset Management</b><br/>Intake, custody and subledger"]
  AMS -->|event deployment manifest| LAN["<b>EMS LAN</b><br/>Offline event projection"]
  LAN -->|immutable commands| API["<b>Partner API</b><br/>Validate and apply"]
  API -->|canonical receipts| AMS
  AMS -->|approved balanced batch| FIN
  FIN -->|status and exceptions| EPS
  AMS -->|readiness and return state| EPS
  AMS -->|deployment projection| EMS

Operator runbook coverage

Every runbook below starts with the active partner and, when applicable, event/project scope; confirms the source owner and required role/capability; uses search-before-create; records the exact command decision; verifies authoritative state plus the immutable action receipt/correlation; looks up a receipt before retrying an unknown result; stops on cross-partner IDs, unauthorized access, stale versions/digests, unexplained amount/quantity differences, unsafe evidence, or maker-checker failure; and opens the named owner record for correction. Examples use opaque artifact IDs and sanitized scope only.

Required workflow	Exact local action and decision	Success evidence and correction boundary
1. Link EMS event to EPS	From the EMS/EPS LinkedWorkPanel, search the partner’s planning candidates, select the EMS-owned event and EPS project, then submit the reviewed canonical_plan link	One active typed link and receipt; stop if the EPS project points to another event or partner
2. Resolve EMS accounting projection	Work the source exception against EMS source ID/version/digest, payment account, event, amount, currency, mapping, and Finance receipt	One balanced Finance result or evidenced exclusion; use replay/correction rather than a second journal
3. Review EMS annotation	Independently approve/reject/mark stale using event, annotation, expected version, Finance policyVersion, current source digest, reason, and idempotency; use a coding proposal/replacement journal for posted effects	Reviewed annotation, digest-bound receipt, and explicit proposal disposition; the annotation maker cannot approve it
4. Close event-day cash	Close the EMS operational session, then reconcile counted/expected evidence per EMS payment account to the linked Finance cash account at the same currency and cutoff	Per-payment-account source/linked totals plus accepted Finance reconciliation receipt; EMS close alone is not Finance close
5. Request EPS procurement	Use planningProjectId, objective, quantity/unitOfMeasure, estimatedAmount, currency, due date, event, Finance dimension IDs and dimensionPolicyVersion; read the live Finance projection or cancel with expected version/reason	procurement, financeRecord, link, projection/readiness, and action receipt; cancellation revokes the request and rolls readiness back unless settled work blocks it
6. Create/link AMS intake	Select the Finance goods receipt and exact financeGoodsReceiptLineId, then classify it controlled or capitalizable; corrections name the immutable prior event in correctionOfEventId	intake, current Finance goodsReceipt header, acquisition, link, lineage, and receipt; one line cannot create duplicate active intake
7. Inspect and capitalize equipment	Record accepted, quarantined, and rejected quantities plus condition/evidence; tag and locate only accepted controlled assets; send approved subledger work to Finance	item.intake.status, inspection actor/reason, AMS records, and Finance posting receipt; three-way-match evidence does not approve payment by itself
8. Deploy durable assets	Reserve, approve, pack, dispatch, receive, activate, audit, return, and reconcile the AMS-owned deployment; propose any asset/model/container substitution and have a different authorized administrator approve or reject it	Versioned manifest, reviewed substitution and immutable receipt when used, custody/condition/movement receipts, and reconciled return or governed exception
9. Operate EMS LAN offline	Import the event-scoped manifest, capture immutable supported commands, restart safely, and replay the outbox when online	Accepted/already-applied canonical receipt exactly once; rejected/conflicted/quarantined work remains actionable
10. Link maintenance/shipment cost	Submit an eligible shipment, work order, damaged asset, rental/agreement, or consumable movement with allowed handoffType, amount, currency, due date, counterparty, event, active dimensions, and policy version	item.handoff.*, linked financeRecord, lifecycle cost when returned, and receipt; Finance failure never erases accepted physical work
11. Post AMS subledger batch	Prepare and independently approve one balanced digest-bound batch, then post/reconcile through the first-party finmanage adapter; a correction names reversalOfBatchLinkId	One Finance journal, AssetManage receipt, batch link, action receipt, and independent reconciliation; original and replacement lineage remain visible
12. Resolve party/place/dimension identity	Search first, compare approved identifiers/effective dates/downstream impact, then review merge, crosswalk, replacement, policy approval, or rejection	Versioned maker-checker receipt; immutable historical snapshots remain unchanged and policy/version remains attributable
13. Complete integrity exceptions	Claim/assign, inspect both owners, attach safe evidence, then either preview and execute a typed retry or preview and execute the immutable creation-time bound fix	A retry resolves only when healed; a successful bound fix atomically mutates the named owner record, writes the fixed event, resolves the exception, and returns its action receipt; comments alone do not complete work
14. Correct lifecycle changes	Use cancellation disposition, refund/credit, reversal, reclassification, return, linked correction, or source replay according to owner policy	New linked correction and surviving original history; locked-period changes follow Finance policy
15. Verify readiness and close	Read live procurement, shipment, deployment, serviceability, intake, Finance, and exception state before accepting an EPS/EMS/AMS/Finance gate	All material owner states reconciled or independently exception-approved; EPS completion never hides an owner-system blocker
16. Roll out and recover	Follow schema → API → read-only views → canary writes → dashboard/LAN → reconciliation order; pause or disable new commands on stop conditions	Preserved receipts/history, reconciled canary, restore evidence, and named sign-off before retiring duplicate entry

EMS accounting and event-day cash to Finance

Existing foundation

Current source and schema evidence shows these foundations:

• EMS accounting source entries can project idempotently into a Finance journal/source link.
• EMS event payment accounts can link to Finance cash accounts.
• Finance can identify source coverage and mapping exceptions by event/source context and reconcile each payment account independently.

These are local/source-backed facts, not authenticated hosted certification. Preserve them rather than introducing a second manual journal-entry path.

Annotation-to-coding workflow

EMS may receive tax, counterparty, document, VAT, withholding, account-code or note enrichment after the original source projected. That later change must create a Finance coding proposal for the linked source. The direct annotation-review command is also governed: an independent Finance approver submits the EMS event, annotation ID, expected annotation version, approve, reject, or mark_stale, a reason, idempotency key, and the required Finance policyVersion for approval. The API recomputes a digest from the current source entry plus annotation; approval freezes that digest and policy version in the reviewed state and receipt. The annotation maker cannot approve their own change.

Finance disposition	Operator meaning
Accepted	Finance applied an allowed metadata/coding result under current policy.
Replaced	Finance used different authoritative coding and recorded why.
Rejected	The proposal is not suitable; EMS keeps its operational evidence and shows the rejection.
Stale	EMS source version/digest changed; refresh and review the current proposal.
Correction required	A posted effect needs reclassification, reversal or another controlled correction.

Never silently mutate a posted journal because an EMS annotation changed. EMS remains the operational evidence owner; Finance remains the accounting authority.

EMS-to-Finance decision path

flowchart LR
  SOURCE["EMS accounting source"] --> PROJECT["Idempotent Finance projection"]
  PROJECT --> RECEIPT["Finance source link or journal receipt"]
  SOURCE -->|later enrichment| PROPOSAL["Finance coding proposal"]
  PROPOSAL --> ACCEPTED["Accepted"]
  PROPOSAL --> REPLACED["Replaced"]
  PROPOSAL --> REJECTED["Rejected"]
  PROPOSAL --> STALE["Stale source digest"]
  ACCEPTED --> VERIFY["Verify one Finance result"]
  REPLACED --> VERIFY
  REJECTED --> EXCEPTION["Actionable exception"]
  STALE --> EXCEPTION
  RECEIPT --> VERIFY

Runbook — resolve an EMS-to-Finance source exception

1. Confirm scope — Open the exception with the active partner, event, payment account, source type, source ID and currency visible.
2. Compare source — Check amount, date, status, source digest/version and cancellation/refund state against EMS.
3. Inspect mapping — Review target account, category, counterparty and dimensions at the same cutoff.
4. Choose action — Link/replay when the source is valid, submit corrected coding when enrichment changed, or reject/approve an exception with reason and evidence.
5. Use safe retry — Reuse the same idempotency key only for the identical request. A changed payload requires a new linked correction command.
6. Verify receipt — Confirm exactly one Finance source link/journal result, balanced currency totals and an audit/correlation receipt.
7. Reconcile — Read finance/ems-reconciliation for the event. Compare overall source and linked totals, then each paymentAccounts row’s EMS source total/count against linked Finance total/count. Resolve stale/replacement proposals and unmatched account mappings before close.

Stop for cross-partner identifiers, unexplained amount/currency difference, duplicate journal, stale digest, locked period, missing maker-checker separation or an unknown timeout with no receipt lookup.

Event-day cash boundary

EMS owns event-day cash sessions and operational movements. Finance owns the posted/reconciled result and period close. Closing an EMS cash session is not the same as reconciling a Finance cash account. The handoff must retain the source session, counted/expected evidence, actor, event, currency, cutoff and accepted Finance receipt.

AssetManage subledger to Finance general ledger

AssetManage records asset acquisition, depreciation, impairment, revaluation, lifecycle cost, disposal and related detail in its subledger. Finance is the partner GL. Operators must not manually enter the same debit and credit in both systems.

First-party posting flow

1. Prepare — AMS creates a balanced batch only from approved subledger entries and freezes its source IDs, versions and digest.
2. Approve — An authorized checker confirms account/dimension mappings, period, currency, evidence and maker-checker separation.
3. Submit — The typed finmanage adapter sends one canonical payload with an idempotency key.
4. Validate — Finance rechecks partner, open period, exact-money totals, balanced lines, account/dimension ownership, duplicate sources and digest.
5. Post or reject — The atomic first-party command creates one Finance journal and its balanced lines, or returns one actionable rejection. No partial hidden result is allowed.
6. Receipt — The same transaction creates the AssetManage journal receipt, Finance batch-link record, typed cross-system relationship, and immutable action receipt containing both authoritative identities.
7. Reconcile — AMS records the receipt; an independent reconciler compares source entries, digest, lines and totals before closing the batch.

Retrying the identical accepted submission returns the original receipt. Changing the batch after rejection creates a new version linked to the rejected attempt. Reversing an accepted batch submits the new AssetManage batch with the prior same-partner reversalOfBatchLinkId; the result retains reversalOfBatchLinkId on the replacement and replacedByBatchLinkId on the original while posting the linked Finance reversal/replacement journal and receipt. A locked period or mapping change follows Finance correction policy; it does not rewrite an accepted AMS batch.

Asset logistics, rental, consumable, and maintenance costs

AssetManage remains the source owner for the physical or contractual activity; Finance owns the commitment, expense, receivable, settlement, and GL result. The allowlisted cost-handoff sources are:

AssetManage source	Normal flow	Finance handoff examples
Shipment	Logistics	Freight commitment, supplier invoice, or expense
Work order	Maintenance	Maintenance/repair/replacement commitment or supplier invoice
Asset	Damage/loss	Repair/replacement commitment, insurance receivable, write-off proposal, or recovery
Agreement	Rental/custody	Rental expense, supplier invoice, or commitment without copying the agreement
Consumable movement	Consumable allocation	Expense/allocation from an AssetManage consumable issue; durable asset movement remains excluded

The request carries the AssetManage source ID/type, flow and handoff type, title, amount/currency, optional due date/event/counterparty, effective Finance dimensions and dimensionPolicyVersion, plus the digest of a frozen source snapshot. The API verifies that a consumable_movement belongs to an asset whose identity mode is consumable. A later settlement may return a lifecycle-cost record, but a Finance rejection or retry remains a separate exception and never reverses an accepted shipment, rental/custody fact, work order, damage observation, or consumable issue.

EPS procurement to Finance and AssetManage intake

Purchase-to-asset runbook

1. Define the need in EPS — Record objective, quantity, needed-by date, event, estimated amount and approved Finance dimension IDs.
2. Search before create — Link an existing budget, commitment or procurement record when it already represents the need.
3. Request procurement — Create one idempotent Finance purchase request carrying the EPS requirement/work-item source link.
4. Work in Finance — Finance owns supplier selection, approval, PO, invoice, tax, goods receipt, settlement and accounting. EPS reads a live projection over linked budget, commitment, purchase request/order, goods receipt, invoice/credit, payment and forecast records. It displays Finance-owned approved, committed, received, invoiced, settled and remaining totals plus downstream statuses, exceptions, and AssetManage readiness read-only.
5. Classify the receipt — A controlled or capitalizable accepted receipt line offers Create asset intake or Link existing intake.
6. Complete AMS intake — AMS adds model/category, serial/tag, condition, inspection, custody, location, components and capitalization policy without retyping the Finance commercial fields.
7. Return acceptance evidence — Accepted, partial, quarantined and rejected quantities update the Finance matching/evidence state but do not automatically approve payment. Every intake transition returns the current Finance goodsReceipt header for authoritative amount/status readback.
8. Post and pay — AMS posts its approved subledger result through the Finance adapter; Finance owns payment and GL close.
9. Verify readiness — EPS reads live procurement, shipment, intake, serviceability and exception state before a gate is accepted.

The shared references are vendor/counterparty, PO, invoice, receipt, amount, currency, tax, event, cost center, fund, evidence and source line. Immutable snapshots are allowed for audit; duplicate editable fields are not.

flowchart LR
  NEED["EPS requirement"] --> REQUEST["Finance purchase request"]
  REQUEST --> PO["Finance PO, invoice and receipt"]
  PO --> CLASSIFY{"Durable or controlled item?"}
  CLASSIFY -->|No| FINISH["Finance-owned completion"]
  CLASSIFY -->|Yes| INTAKE["AMS intake or existing-intake link"]
  INTAKE --> READY["EPS readiness projection"]
  INTAKE --> BATCH["AMS approved subledger batch"]
  BATCH --> GL["Finance acceptance receipt"]
  GL --> READY

Partial and correction states

Condition	Required handling
Partial receipt	Keep Finance receipt and AMS intake quantities partial; do not mark the EPS need complete automatically.
Rejected/quarantined equipment	Record AMS inspection evidence and a Finance matching exception; do not approve the rejected quantity for payment.
Return to vendor or credit	Link the physical AMS return to the Finance credit/payable correction.
Price or quantity variance	Finance owns accounting disposition; AMS preserves receipt/condition facts.
Cancellation	Use the procurement cancel action with expected version, reason, and a fresh idempotency key. It cancels the EPS procurement and linked Finance request, refreshes the live projection, and rolls readiness back; final/settled work blocks cancellation.
Intake correction	Intake events are immutable. Use correct only with correctionOfEventId naming the prior same-intake event; non-correction actions must not send this field. Verify returned lineage and the current Finance goods-receipt header.
Capitalization or batch correction	Use a new AMS subledger correction and Finance receipt. A posted batch reversal names reversalOfBatchLinkId and preserves original/replacement lineage; never edit historical events or journals.

EMS inventory versus AssetManage durable assets

Keep the two inventory domains separate

Category	Owner	Examples	Event behavior
Sellable or entitlement stock	EMS	Event merchandise allocation, attendee inclusions, add-ons and redemption stock	Continue using EMS inventory/POS/claim movements.
Reusable operational equipment	AMS	Radios, scanners, laptops, networking gear, printers, power equipment and storage cases	Use an event asset deployment; never create a new EMS inclusion/add-on identity.
Partner consumables	Policy-selected owner	Labels, batteries, cable ties, cleaning supplies and paper rolls	Centrally stocked supplies may be issued by AMS; event-only purchases may remain EMS/Finance-local.

A movement of EMS event stock is not an AMS asset movement. A durable-asset scan must not change EMS inclusion/add-on totals or create an EMS accounting source automatically.

Event asset deployment

The event deployment links one EMS event and optional EPS need to AMS assets, quantity-managed equipment, kits or containers. It carries origin/destination places, EMS event-location overlay, shipment, custody, dispatch/arrival/setup/teardown/return targets, condition, version, status and exception receipts.

AMS owns selection, reservation, packing, shipment, custody, movement, condition, damage/loss, audit and return. EMS displays the event-oriented manifest and receiving/staging/return state. EPS reads readiness. Finance reads freight, rental, repair, insurance, replacement or write-off handoffs when authorized.

sequenceDiagram
  participant AMS as Asset Management
  participant LAN as EMS LAN
  participant API as Partner API
  participant EMS as EMS dashboard
  AMS->>LAN: Versioned event deployment manifest
  LAN->>LAN: Capture immutable offline command
  LAN->>API: Replay command with version, digest and idempotency key
  API->>AMS: Validate and apply canonical asset operation
  AMS-->>API: Accepted, already applied, rejected, conflict or quarantine receipt
  API-->>LAN: Apply one event-bound canonical receipt
  API-->>EMS: Read-only deployment and reconciliation projection
  Note over AMS,EMS: EMS sellable and entitlement stock stays a separate lane

Runbook — deploy and reconcile durable assets

1. Request — Link the EPS equipment need to an existing AMS deployment or submit one reservation request.
2. Approve and reserve — AMS verifies availability, condition, serviceability, conflicting reservations and responsible custodian.
3. Pack and dispatch — AMS records assets/containers, seal/manifest, shipment, carrier, origin, destination and custody handoff once.
4. Import for LAN — EMS LAN receives a versioned, event-scoped, minimal deployment manifest before disconnection.
5. Open reconciliation — Compare expected, received, substituted, damaged, quarantined and missing items. Keep unresolved material items actionable.
6. Operate — Record approved receive, move, custody, condition, missing/found and return commands against the imported identities.
7. Replay — After connectivity returns, submit immutable commands through the existing outbox. Apply canonical receipts once.
8. Resolve — Keep rejected, conflicted or quarantined commands with reason, safe current state, evidence and permitted correction/escalation actions.
9. Close reconciliation — Compare expected, on-site, issued, returned, missing and damaged items. Block close or record an authorized evidenced exception.
10. Verify downstream work — Confirm AMS movement/custody/condition results and any separate Finance freight, repair or loss exception receipts.

Runbook — propose and review a deployment substitution

1. Select the exact item — Open the current same-partner deployment and item, refresh its version, and confirm that the deployment is in a state that permits substitution.
2. Propose one replacement — Choose substitute and provide exactly one different replacement assetId, modelId, or containerId, plus the item ID, current deployment version, reason, an evidence object, and a fresh idempotency key. Every replacement identity must belong to the active partner.
3. Preserve the manifest pending review — A successful proposal returns the pending substitution and deployment with an approval-required receipt. It does not replace the deployment item or create a movement while review is pending.
4. Review independently — A different AssetManage administrator opens deployments/{deploymentId}/substitutions, selects the pending proposal, verifies the exact replacement, evidence, ownership, expected substitution version, and expected deployment version, then chooses approve_substitution or reject_substitution with a reason and fresh key. The proposal maker cannot review their own work.
5. Verify the atomic result — Approval applies the selected replacement to the deployment item/manifest through the canonical substitute transition and returns the reviewed substitution, current deployment/items, and immutable action receipt together. Rejection finalizes the proposal without replacing the original item.
6. Stop on conflict — Refresh instead of bypassing a stale/final proposal, stale deployment, cross-partner identity, multiple replacement IDs, same-as-current identity, missing evidence, maker self-review, or unauthorized review. A changed replacement requires a new proposal; do not edit a reviewed record.

Runbook — approve a deployment exception

1. Use an independent approver — The operator who created the exception cannot approve it. Confirm the approver has the deployment-exception capability and the active partner scope.
2. Match the governed record — Enter the Exception ID for a non-final exception belonging to the same partner and deployment. When the exception names a deployment item, the action must name that same item.
3. Attach safe evidence — Enter a non-empty opaque Evidence artifact ID and an approval reason. Direct URLs, blank evidence, and unrelated artifacts are not accepted.
4. Submit once — Choose approve_exception with the deployment’s current expected version and a fresh idempotency key for this exact payload.
5. Verify the atomic result — Confirm the exception moved to approved_exception, one immutable exception_approved event recorded its prior state, reason, item and evidence, and the deployment action returned one immutable receipt.
6. Stop on rejection — Do not bypass a maker self-approval, already-final exception, cross-partner record, deployment mismatch, item mismatch, missing evidence or stale deployment version. Refresh the owning records and escalate or submit a corrected linked action.

Approval does not erase missing, damaged or substituted history and does not create an EMS inventory movement. Inactive Linked Operations tabs remain hidden; use the visible deployment dialog’s Exception ID and Evidence artifact ID fields rather than attempting to act from a stale hidden panel.

EMS LAN command and receipt model

An offline deployment manifest contains only the selected event’s authorized operational projection. It must not include online credentials, unrestricted locations, unrelated assets, private Finance details or direct evidence URLs.

EMS LAN sends durable work through the existing generic POST /api/events/{eventId}/lan-sync/operations route; there is no second durable-asset sync endpoint. Each signed operation uses domain asset_deployment, entity type durable_asset_command, and the same command ID in operationId, entityId, payload commandId, and its idempotency identity. The schema-version-1 payload binds the deployment/item plus optional asset/container and positive quantity; receive, stage, issue, handoff, move, return, missing, or damaged; source digest and expected manifest version; fromPlaceId/toPlaceId; custodianPartyId; condition; occurrence time; device ID; up to 100 opaque evidence artifact IDs; and optional correctsCommandId naming another immutable command. Damage requires evidence. The outer signed actor is authoritative; the payload cannot supply a second actor.

The server rechecks the event, partner, EMS and AssetManage capabilities, envelope/payload digests, time/version bounds, place/custody/evidence ownership, and correction lineage before the atomic projection. It returns { eventId, results }; each result is applied, already_applied, conflict, rejected, or quarantined with safe canonical receipt/state data. If the server applied a command but the acknowledgement was lost, replay the exact stored operation. The server returns already_applied for the original effect, and EMS LAN stores one immutable receipt and applies the canonical movement/custody/condition projection exactly once.

Local state	Meaning	Operator action
Pending online validation	The command is durable locally but not authoritative online	Keep evidence and await replay; do not report canonical completion.
Applied	AssetManage accepted one canonical result	Verify movement/custody/condition and receipt digest.
Already applied	The same operation was previously accepted	Use the returned original receipt; do not create another command.
Rejected	The command is invalid under current authority/state	Review reason and correct through a new linked command.
Conflict	Online version/state makes the local intent ambiguous	Compare safe current state; choose an authorized resolution.
Quarantined	Evidence, identifier or policy requires review	Assign the exception and preserve the original command.

Commands are immutable. Correction or resubmission creates a linked operation with a new ID. Receipt application is event-bound, digest-checked, transactional and idempotent. A Finance handoff failure after AMS accepts the physical operation becomes a separate retriable Finance exception; it must not roll back the accepted physical movement.

Actionable integrity queue

The queue is a workspace for completing work. A record is not resolved because somebody viewed it.

Every row must show partner/event scope, source and target owners, affected records, safe reason, severity/materiality, assignee, required capability, versions/digests, last receipt, evidence, deep links and permitted actions. Operators must be able to assign/claim, submit evidence, retry, correct, reject, approve an exception or escalate according to policy.

Retries are typed commands, not arbitrary stored JSON. On exception creation the API accepts only revalidate_link, revalidate_identity, refresh_procurement, revalidate_intake, reconcile_asset_batch, revalidate_deployment, revalidate_coding, revalidate_source, or revalidate_generic. Its bounded payload may contain only the matching partner-owned link, identity/type, procurement, intake, batch-link, deployment/item, or proposal IDs. Unsupported keys, oversized payloads, malformed UUIDs, cross-partner references, and mismatched identity/deployment-item pairs are rejected before storage.

Open the retry-preview first and confirm operation, sanitized payload, expected version, retry count, current state, owner deep link, and canExecute. The atomic retry re-evaluates current owner state; it returns a structured retry result with operation, healed, incremented retryCount, and checkedAt, writes an immutable event and action receipt, and sets the exception to resolved only when healed. A non-healing retry remains in_progress; do not close it from the existence of a retry receipt alone.

Immutable exception-bound fixes

A retry only revalidates current state and may leave the exception in_progress. A typed fix is different: its owner-system mutation is bound to the exception when the exception is created. The stored fixOperation and sanitized fixPayload are immutable, so an executor cannot replace the target, action, expected owner version, or correction lineage at execution time.

The allowlist is link_transition, identity_crosswalk_review, coding_proposal_transition, asset_intake_transition, and deployment_substitution_review. Open exceptions/{exceptionId}/fix-preview and verify the exception ID/version, bound operation, sanitized target/action payload, current state, canExecute, and owner deep link. Then execute the fix with only the exception’s current expected version, a reason, and a fresh idempotency key; the request never supplies a replacement fixOperation or fixPayload.

The API rechecks the active partner, operation-specific capability, recent step-up authentication, final state, bound target, versions, and operation-specific lineage before calling the exact domain command. Success is atomic: the owner record changes, the exception moves to resolved, one immutable fixed exception event records the bound operation and domain result, and one exception action receipt is returned. A stale version, already-final exception, target mismatch, cross-partner reference, unauthorized actor, invalid bound action, or stale substitution/deployment review fails without partial completion. If the intended fix has changed, create a new governed exception rather than editing the bound envelope.

Required exception families

Exception	Normal owner	Completion evidence
EMS source lacks a Finance link/journal	Finance operations	One accepted source link/journal receipt or an approved evidenced exclusion
EMS annotation is newer than Finance coding	Finance coding reviewer	Accepted/replaced/rejected proposal and audit receipt
AMS batch exported but not accepted/reconciled	Asset accountant and Finance checker	Finance receipt plus independent AMS reconciliation
Finance receipt requires intake but none is linked	Procurement/asset receiving	Linked AMS intake or evidenced non-asset classification
AMS intake has unresolved PO/invoice/receipt	Procurement/asset receiving	Correct same-partner Finance links or approved exception
Shipment received while goods receipt remains open	Receiving and Finance	Matched accepted quantities or documented variance
Work order/shipment actual cost lacks Finance work	Asset operator and Finance maker	Linked commitment/payable/expense or approved non-financial disposition
EPS work is complete but linked readiness is unresolved	Planning owner	Owner-system completion evidence or authorized gate exception
Party/place/dimension crosswalk missing or invalid	Master-data steward	Reviewed crosswalk/merge/correction receipt
Duplicate source, invoice, asset ID, journal or receipt suspected	Owning-system reviewer	Deduplication decision preserving one authority and audit chain
LAN command is pending, rejected, conflicted or quarantined	EMS LAN operator and AMS owner	Canonical receipt, linked correction or authorized exception

Runbook — complete an exception

1. Claim — Assign the row to a named authorized owner.
2. Verify scope — Confirm active partner/event and both record owners before reading or mutating target data.
3. Read evidence — Compare source/target IDs, version, digest, amount/quantity, lifecycle and last receipt.
4. Choose the narrow action — Link, replay, submit a coding proposal, correct, reject, approve an exception or escalate.
5. Preview and submit once — For retry, inspect the typed retry-preview. For an owner-system mutation, inspect the immutable fix-preview and execute only its bound action. Preserve idempotency and expected version; on timeout, look up the receipt before retrying.
6. Verify both sides — Confirm authoritative owner state, linked read projection, the structured retry healed result or bound-fix domain result, immutable exception event, and audit/correlation receipt.
7. Complete — Record resolution category, evidence and downstream effect. A comment alone is not completion.

flowchart LR
  DETECT["Integrity check detects mismatch"] --> QUEUE["Queue with safe reason and owner"]
  QUEUE --> CLAIM["Assign or claim"]
  CLAIM --> INSPECT["Compare source, target, version, digest and receipt"]
  INSPECT --> ACTION{"Permitted action"}
  ACTION -->|retry or correct| VERIFY["Verify both owners and receipt"]
  ACTION -->|reject or approve exception| VERIFY
  ACTION -->|cannot decide safely| ESCALATE["Escalate with evidence"]
  VERIFY --> COMPLETE["Record resolution and downstream effect"]
  ESCALATE --> QUEUE

Correction, replay and reconciliation rules

• Posted Finance truth is immutable. Use metadata proposal, reclassification, reversal or correction under period policy.
• Accepted AMS and EMS LAN operations are immutable. An intake correction names its prior immutable event; an asset batch names the reversed batch link; a LAN command names correctsCommandId. Each correction is a linked new operation, not an edit.
• Same idempotency key plus same payload returns the original result. A changed payload conflicts or requires a new linked key.
• Cancellation has a target disposition. Procurement cancellation atomically cancels its Finance request and refreshes EPS readiness. Other flows define cancel, reverse, close, retain, detach or exception behavior; do not orphan the target.
• Source digest changes are reviewed. Never replay changed content as if it were the accepted version.
• Frozen link snapshots remain frozen. Read current values from the owning source and use version/digest verification, staleness, replacement, or a linked correction; never overwrite the original endpoint snapshot.
• Exception-bound fix envelopes remain frozen. Execute only the creation-time fixOperation and sanitized fixPayload. If the intended owner mutation changes, create a new exception; never replace the bound target/action at execution time.
• Partial states remain partial. Do not collapse partial receipt/payment/return into complete.
• Physical and financial acceptance are separate. A Finance-link failure does not erase an accepted AMS physical result.
• Close uses reconciled material state. EMS event close, EPS gates, AMS deployment close and Finance period close surface unresolved material links or approved exceptions.

Roles and security

Role	Typical linked work	Must not do alone
EMS operator	Review source and event logistics state	Change Finance coding or AMS custody authority
EPS planner/requester	Link needs, request procurement/assets, read readiness	Approve own Finance/AMS result or copy authoritative amounts
Finance maker	Create mapping, coding, procurement and correction proposals	Approve own material proposal or mutate posted journals
Finance checker/reconciler	Approve/reject and reconcile sources/batches	Replace operational evidence without source-owner action
AMS operator/custodian	Intake, move, hand off, inspect and return assets	Post directly to GL or acknowledge both sides of custody
AMS asset accountant	Prepare asset subledger batch	Act as independent Finance checker/reconciler for the same batch when policy prohibits it
EMS LAN operator	Capture event-scoped offline commands and exceptions	Treat pending local state as canonical or access unrelated event assets
Support/platform administrator	Diagnose correlations and controlled recovery	Impersonate an accountable business actor or bypass ownership controls
Auditor	Read permitted histories, receipts and exports	Perform ordinary operational mutations

The API and database recheck every command. Hidden controls are not authorization. Every link validates the same partner on both ends and, where required, the event/project scope. High-risk actions retain maker-checker, recent authentication, version checks, exact-money validation, period locks, device identity, audit and least privilege.

Never place service keys, provider secrets, raw tokens, personal details, real bank identifiers, private facility details, direct Sanity URLs or unrestricted evidence URLs in browser responses, fixtures, screenshots, logs or support notes.

Rollout and recovery

Safe rollout sequence

1. Freeze contracts — Approve ownership, relationship allowlist, roles, materiality, correction rules and evidence classes.
2. Measure read-only coverage — Count duplicates, missing links, stale projections, unmatched purchases/receipts/intakes and unaccepted batches without changing write paths.
3. Prepare crosswalks — Review parties, places and dimensions; do not auto-merge by name.
4. Deploy additive schema — Apply reviewed RLS-protected changes before dependent commands.
5. Deploy backward-compatible API — Introduce reads, validation, idempotent commands and receipts before clients depend on them.
6. Enable read-only linked views — Compare live values and coverage with existing controls.
7. Canary controlled writes — Use one synthetic/disposable or authorized canary partner/event with named operators and rollback criteria.
8. Enable dashboard and LAN clients — Retain compatibility with older snapshots and events without AMS.
9. Reconcile and review — Prove totals, asset states, receipts, retry/correction and tenant isolation.
10. Retire duplicate entry deliberately — Remove a manual path only after parity, recovery and rollback evidence passes.

Pause the rollout for cross-tenant exposure, duplicate journals/movements, digest mismatch, unbalanced Finance batch, unsafe replay, missing custody, lost evidence, corrupted manifest, unexplained material variance or an unresolved restore mismatch.

Rollback disables new commands or projections while retaining accepted receipts, journals, asset movements, evidence and audit history. Recovery uses linked compensation, reversal, reclassification, crosswalk replacement or replay from the immutable source. Never delete accepted business history to make a count match.

Local implementation certification evidence — 2026-08-18

The following checks passed against the local working copies. They are reproducible development evidence only; they do not certify hosted authentication, a deployed Worker, provider connectivity, a supported event device, production data, restore operations or operator sign-off.

Area	Command	Local evidence
Dashboard and database contracts	pnpm cross-system-linkage:certify in partners.furries.ph	Disposable database and source-contract checks passed for tenant isolation; maker-checker/effective-dated identities and policies; typed retry; live procurement/cancellation; EMS annotation/reconciliation; intake and asset-batch correction lineage; first-party GL posting; agreement/consumable and other logistics handoffs; durable LAN movement/custody replay; structured telemetry; metrics; receipts; and browser-role denial.
Partner API	npm run cross-system-linkage:certify in partners-api	558 route, capability, DTO, idempotency, digest, typed-envelope, atomic-command, posting, procurement/intake, handoff, LAN, reviewed substitution, immutable exception-fix, telemetry, metric, and boundary checks passed, followed by tsc --noEmit.
EMS LAN	pnpm task026:certify and pnpm cross-system-linkage:certify in fph-lan-ems	The focused certificate passes 65/65 and the cross-system regression passes 26/26 for manifest compatibility, full movement/custody/evidence commands, lost-ack already_applied replay, scanning, restart/replay, immutable correction lineage, conflict/quarantine, event/capability isolation, signed recovery, guarded switching, and inventory/finance non-duplication boundaries.
Operator documentation	pnpm check, pnpm build, then node scripts/certify-cross-system-linkage-docs.mjs in docs.furries.ph	Astro diagnostics, static rendering, guide contracts, internal links, navigation, search and sitemap coverage.

The local visual/runtime evidence inventory is deliberately environment-labelled: dashboard TASK060 records authenticated local-fixture desktop and narrow rendering; EMS LAN TASK026 records its timestamped synthetic desktop, tablet, and Android-size report under reports/task026/2026-08-18T15-38-06-691Z/; and this docs certificate inspects the rendered guide, diagrams, navigation, search index, sitemap, and clean internal links. Those artifacts are not hosted multi-role, physical-device, venue-LAN, provider, or production evidence.

The local implementation covers effective-dated identities and custom-axis Finance policies, typed relationship envelopes, live procurement and cancellation, intake/batch correction lineage, EMS Finance review and reconciliation, first-party GL posting and receipts, agreement/rental and consumable cost handoffs, reviewed durable-asset substitutions, generic LAN durable commands, typed exception retry and immutable bound fixes, and structured metrics/telemetry through atomic command paths. Do not use the passing local checks to claim that migrations, API routes, dashboard code, or LAN packages are deployed. Hosted multi-role authentication, real production/provider data, physical device and venue-LAN evidence, canary activation, deployed rollback/restore, production reconciliation, and operator/security/Finance sign-off remain open.

Certification levels

Level	What it proves	What it does not prove
Design/Preview	Ownership, workflows and controls are specified	Running implementation
Static/source review	Current source contains the inspected contract	Successful runtime or deployment
Fixture/local UI	One synthetic UI state renders and behaves locally	Real database, hosted auth, provider or production behavior
Disposable real stack	Schema, API, RLS, commands and receipts work against an isolated database/Worker	Hosted deployment or production data readiness
EMS LAN runtime/device	Offline restart, scan, replay, recovery and supported device paths work	Hosted API or real event approval
Authenticated hosted canary	Deployed multi-role path works for an authorized canary scope	General production approval
Provider/restore evidence	External integration or native recovery works in the named environment	Unrelated providers or every failure mode
Independent sign-off	Named Finance, Asset, Event Operations and security reviewers accept the evidence	Permanent certification without change control

The final evidence set must include success, partial, rejected, cancelled, damaged/lost, stale-version, duplicate retry, offline restart, replay, conflict, tenant-isolation, maker-checker, locked-period, rollback and restore scenarios. Record date, environment, build/commit, role, sanitized scope, expected result, observed result, receipt/correlation IDs and evidence location.

Completion checks

• One event identity is reused by EPS, Finance and AMS links without copying the EMS record.
• One EMS accounting source produces one balanced Finance result; later enrichment has an explicit Finance disposition.
• One approved AMS batch has one Finance receipt and independent reconciliation.
• One reversed AMS batch preserves both reversalOfBatchLinkId and replacedByBatchLinkId lineage instead of rewriting the accepted posting.
• One EPS procurement need reaches purchase, receipt, AMS intake, capitalization and payment without retyping shared commercial fields.
• One cancelled EPS procurement revokes its Finance request and rolls readiness back; one corrected intake names its immutable prior event and returns the current Finance goods-receipt header.
• One reusable asset/container reaches EMS receiving, event use and return without becoming EMS inclusion/add-on stock.
• One proposed deployment substitution changes no manifest item until a different authorized administrator approves it; approval preserves the reviewed replacement and immutable receipt, while rejection preserves the original item.
• One deployment exception approval proves same-partner/deployment/item scope, independent approval, opaque evidence, an immutable exception_approved event, and one deployment receipt.
• One offline durable-asset command produces exactly one authoritative AMS result after replay.
• One lost-ack durable command replay returns the original already_applied result and produces one local immutable receipt.
• Every exception is assignable and can be resolved, rejected, evidenced, exception-approved or escalated from the queue; typed retry resolves it only when the structured result says healed, and a typed fix can execute only its immutable creation-time bound owner action.
• Cross-partner IDs and unauthorized roles are rejected before protected data is disclosed.
• Accepted journals, movements, commands, receipts and evidence survive correction, rollback and restore.
• The evidence label matches the environment actually tested; no Preview or fixture is presented as hosted/production release.

Related operator guides

• Link Planning and EMS Without Double Entry
• Finance Operator Runbooks and Recovery
• Finance Data, API, Roles, and Controls
• Event Finance Comparison
• Asset Logistics Hub
• Asset Finance and Depreciation
• EMS LAN Inventory, POS, and Money Reconciliation
• EMS LAN Import and Reconcile
• Platform API Finance and Payments
• Platform API EMS LAN Support