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

Complete the workbook in this sequence:

Topology assessment. Choose the data-plane pattern for your estate before completing the detailed inventory.
Inventory. Add one row per connected system, including systems you do not currently integrate with but that hold state an agent would need. Delete the yellow example row once you understand the format. Use coded fields where a code exists and free text elsewhere. Leave a cell blank only when you genuinely do not know: blank means unknown, and unknown is a finding. Record supporting sources in the Evidence link column and explanations in Notes; a claim without a document link is an assumption.
Agent registry. Record every agent permitted to reach the layer, under whose authority and at what scope. Use the registry to gate access from the first multi-agent deployment; listing agents without enforcing the register does not provide a control.
Tool registry. Record every tool an agent may invoke and the permission matrix across agents. Apply deny-by-default access with explicit grants.
Commercial constraints. Record the applicable commercial limits, their source and owner, and the checks required before a write.
Operational mode. Record property or brand operating conditions and the actions each permits, queues or refuses, including write blackout windows such as night audit.
Consistency test log. Maintain the standing question set used to check consistent authoritative answers across agents and channels under matching scope and freshness conditions.

Use the Code legend for SG, R, W, EV, DG, OG and SY grades. These describe interface capabilities, not vendors. SY0 to SY3 describe the synchronization mechanism.

Authority, synchronization and freshness

In the Inventory tab’s Data authority and freshness fields, state what each system is authoritative for, its synchronization mechanism using an SY code, and its expected staleness. Identify the source that owns each fact and the path by which a derived view receives updates. Record evidence for the update cadence and freshness assumptions; do not treat an unknown or stale copy as authoritative for an action.

How to read the result

Three patterns are worth acting on. W0 has no programmatic write capability and requires a human handoff. W1 separates submission from confirmation and needs independently verified outcome handling, alongside the existing authorization and retry controls, before it can support guarded writes. 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.

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

No programmatic read. A specifically authorized legacy adapter or manual handoff may be needed. Declare provenance, contractual access and staleness; do not create a competing system of record.

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 idempotency honored across retries. Multi-system workflows may still require compensation or reconciliation.

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

Push without a replay path. A consumer outage requires a documented reconciliation or backfill path; otherwise state can diverge.

EV3 · Webhook or stream with replay and versioned schema

Events are pushed, recoverable over a stated window, and carry a versioned schema. This is the target for check-in fan-out without standing manual reconciliation; delivery, processing and recovery must still be verified.

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

Event on change with replay. Supports low-latency updates and recovery over a declared window; freshness still depends on ingestion, processing and the served view.