WORKGROUP 2 OUTPUT

Integration inventory instructions

How to document your stack, choose a data-plane pattern and record enforceable controls.

Overview

Complete the workbook using the systems and contracts you actually have. Blank means unknown. Demonstrate claims with evidence; do not treat example values as real vendor ratings.

XLSXReusable download

Integration and control-point inventory

What it is: A nine-tab workbook for interfaces, topology, tools, agents, commercial constraints, operating mode and consistency tests.
When to use it: Before selecting an architecture or evaluating integration claims.
What you enter or decide: Your systems, source authority, permissions, evidence and workflow constraints.
What it produces: An evidence-backed inventory and explicit unknowns.

Illustrative rows are examples. Incomplete answers must not be read as a cleared architecture decision.

Download XLSX ↓

What this is for

The blueprint requires that every connected system meet a minimum interface standard, that every action be attributable, and that an incident be reconstructable across vendors. None of that is testable until an operator can state, system by system, what their stack actually exposes today.

This workbook is that statement. One row per connected system. It is designed to be filled in by a hotel company or its integrator, and to be handed to a vendor as the evidence request in a procurement conversation.

How to use it

Open the Inventory tab. Delete the yellow example row once you understand the format.
Add one row per connected system, including systems you do not currently integrate with but that hold state an agent would need.
Use the coded fields where a code exists. The Code legend tab defines every code. Free text is fine everywhere else.
Leave a cell blank only where you genuinely do not know. Blank means unknown, and unknown is a finding, not an omission.
Record evidence in the last two columns. A claim without a document link is an assumption.

How to read the result

Three patterns are worth acting on. Any system at write tier W0 or W1 cannot support the guarded write pattern without a human in the loop, so workflows that assume it must be redesigned. Any system at event tier EV0 or EV1 imposes a staleness budget on every workflow that depends on it. Any system where scope granularity is admin-only breaks the principle that no component holds more authority than its task requires.

Readiness summary

Counts update as you fill in the Inventory tab. They exclude the example row.

Systems recorded
Systems with a documented API
Systems with a non-admin credential
Systems at write tier W3 (transactional, idempotent)
Systems at write tier W0 (no write capability)
Systems at event tier EV3 (replay and versioned schema)
Systems at event tier EV0 (no event support)
Systems with an operator-accessible audit log
Systems with a documented exit path

Contribution note: this template is deliberately vendor-neutral. It records what a system exposes, not how any named product performs. Per-vendor capability ratings are out of scope and should stay out of scope.

What changed in the framework

Three tabs were added, so the workbook now covers the whole blueprint rather than the systems inventory alone. Complete them in tab order: Topology assessment, then Inventory, then Tool registry, then Consistency test log.

Topology assessment decides which data-plane pattern applies to you. It is short, and it determines which of the other tabs matter most.
Tool registry records every tool an agent may invoke, with the permission matrix across agents. It is the deny-by-default position made operable.
Consistency test log is the standing question set for the one-answer-per-question position.
Three columns were added to the end of the Inventory tab, under Data authority and freshness: what the system is authoritative for, its sync mechanism as an SY code, and its expected staleness. Existing the framework columns A to AF are unchanged and in the same order, so data captured against the framework can be pasted straight across.
One code set was added to the Code legend: SY0 to SY3 for sync mechanism.

What changed in the framework

Two register tabs were added. Both were named as gaps in the review of the Workgroup 3 platform reference architecture: an architecture can hold per-agent scope and still have no list of which agents exist, and a write path can be fully audited and still attempt a folio posting during the night audit.

Agent registry records every agent permitted to reach the layer, under whose authority and at what scope. It is a day-one artifact rather than a later phase, because it is the answer to the first governance question anyone will ask. A registry that does not gate anything is a diagram of a control, not a control.

Suggested order: Topology assessment, Inventory, Agent registry, Tool registry, Commercial constraints, Operational mode, Consistency test log. The code legend defines SG, R, W, EV, DG, OG and SY grades. These measure interface capabilities, not vendors.

Complete code legend

SG0 · Administrator only

The only credential available carries full administrative authority. Every workflow inherits maximum blast radius. Incompatible with the principle that no component holds more authority than its task requires.

SG1 · Role-scoped

Credentials map to coarse roles. Better than SG0, but a workflow needing one field inherits everything that role can reach.

SG2 · Resource-scoped

Authority can be limited to specific resource types and operations. Sufficient for most guarded write designs.

SG3 · Field-scoped or tier-scoped

Authority can be limited to specific fields or disclosure tiers. Required where guarded disclosure must exclude access credentials or payment detail from model context.

R0 · No programmatic read

Data is reachable only through a user interface. Any integration means scraping or duplication, both of which violate the integration-boundary principle.

R1 · Batch or file extract

Scheduled export only. Imposes a staleness budget equal to the export interval on every dependent workflow.

R2 · On-demand API, current state

Current state readable on request. Sufficient for most conversational reads, insufficient for reconstruction after an incident.

R3 · On-demand API with history

Current state plus historical or point-in-time reads. Required where the reliability checklist calls for reconstructing what a workflow saw at decision time.

W0 · No write capability

The guarded write pattern cannot execute. Any workflow reaching this system must terminate in a human queue with an authoritative handoff record.

W1 · Constrained or queued write

Writes accepted for a narrow set of operations, or accepted asynchronously without a synchronous authoritative receipt. Workflow must treat submission and confirmation as separate events.

W2 · Transactional write, no idempotency

Synchronous writes with a receipt, but a retried request may duplicate. The orchestration layer must supply de-duplication using a natural key, and must define behavior on ambiguous timeout.

W3 · Transactional write, idempotent

Synchronous writes with a receipt and a client-supplied idempotency key honoured across retries. The only tier where the guarded write pattern executes safely without compensating logic.

EV0 · No event support

State change is invisible until something asks. Every dependent workflow carries a staleness budget that must be declared.

EV1 · Polling only

Change is discoverable by repeated read. Cost and latency scale with property count. Declare the interval and the resulting staleness.

EV2 · Webhook or stream, no replay

Events are pushed but cannot be re-requested. A consumer outage produces permanent divergence that only a human reconciliation will find. This is the most common and most underestimated gap.

EV3 · Webhook or stream with replay and versioned schema

Events are pushed, recoverable over a stated window, and carry a versioned schema. The only tier at which the check-in fan-out pattern is operable without manual reconciliation.

DG0 · None stated or best effort

Treat as lossy. Any workflow depending on it needs a periodic reconciliation read.

DG1 · At-most-once

Events may be lost but never duplicated. Requires reconciliation. Rarely the right choice for hospitality state changes.

DG2 · At-least-once

Events may repeat but are not lost. The correct target. Requires that every consumer be idempotent. Exactly-once should not be claimed or relied on across a vendor boundary.

OG0 · None

Events for the same reservation may arrive out of order. Consumers must use event time rather than receipt time and must tolerate a later event arriving first.

OG1 · Per resource key

Order preserved within a reservation, stay, or unit. Sufficient for hospitality workflows and the realistic target.

OG2 · Global

Total order across all events. Rarely offered, rarely needed, and usually a scalability liability.

SY0 · Manual or unscheduled

A person exports or re-enters the data. Staleness is unbounded and unknowable, so no answer built on it can state its own age.

SY1 · Scheduled batch or crawl

Refreshed on a stated interval. Staleness is bounded by the interval, which must be declared alongside it. Acceptable for policy and procedure content, not for availability or rates.

SY2 · On-request read, cached

Read when asked, behind a short cache. Staleness is bounded by the cache lifetime. The default for structured facts in a uniform estate.

SY3 · Event on change, with replay

The source pushes a change and the change is recoverable over a stated window. The only mechanism that supports an answer knowing it is current.