Loaded is not verified

Loaded is the loader claim: a code was entered into the chain. Verified is the engine proof: the negotiated rate actually returns to an agent, in the correct field, under an authorized identity, at the negotiated value, and is bookable on the dates it should be.

Most loading errors are silent. The code looks entered, but it returns under the wrong field, or a different value, or a squatter property answers, or it is closed on a peak night it was supposed to protect. Each of those is lost revenue or a corporate-audit failure. This platform turns every one into a named, evidenced catch.

Every instruction today is Type: Rate Load: a negotiated rate to load and prove. The type field is built to grow, but Rate Load is the only one for now.

It reaches the platform one of two ways. A received instruction is an RLI a client or program sent in, normalized from whatever format it arrived in. An Audit is a self-initiated sweep: a manager runs it, and the engine generates the expected states straight from the client registry to check what is already loaded against the program on file. Audits carry a distinct AUDIT badge wherever they appear.

A loader opens the verify panel, picks a property and GDS, and pastes the real screen an agent would see. The engine canonicalizes each returned row, matches it against the expected state, and records a discrepancy for anything that does not line up. It checks the code, the field it sits in, the value, the room type, the identity (name, pseudo city, office ID, chain code), and whether anything is bookable. Re-running recomputes the whole RLI, so the result is always current.

Verification (after the load)

Two dimensions are kept separate on purpose. Load correctness (is the right code in the right place at the right value) always fails when wrong. Bookability (is it open or closed, and why) only grades a load that is otherwise correct. A closed rate never hides a wrong code, and a correct rate that is merely yield-closed is not called a failure.

Blackout dates are the peak nights a program negotiated to exclude. They are applied as close-outs in the reservation system, separately from the rate-code load, which is exactly where revenue quietly leaks. The platform verifies them two ways:

• Not applied: the negotiated rate is bookable on a contracted blackout date. The close-out is missing. This is a failure (BLACKOUT_NOT_APPLIED) and the Fix button can stage the close-out.
• Correctly closed: a rate closed on a blackout date is expected. The engine never reads that as a failure.

One honest guard: if nothing returns for a window that sits entirely inside a blackout, that is consistent with the close-out, but silence cannot confirm the load was ever done correctly. The task stays PENDING (load-unconfirmed), never falsely VERIFIED and never falsely failed. Verify it from a non-blackout date.

A rate can be loaded at the right value and still be wrong on dates: live for the wrong window, or expired with no renewal behind it. The platform checks the effective period two ways.

• Coverage gap (WRONG_EFFECTIVE_DATE): a loader probes a few stay windows. If the negotiated rate returns for one window but is empty for another window that sits inside the contracted period, the dates it is live for do not match the negotiated period. To avoid a false catch, the proof window must actually contain the negotiated code, and the proof and the empty window must come from the same pseudo city, so a rate released to one office but not another reads as a release gap, not a date gap.
• Expired (EXPIRED): the negotiated period has ended and no renewal supersedes it (a later or open-ended window for the same program would). This is a soft review (NEEDS_RENEWAL), not a hard fail: the rate needs renewing or removing, but it may be loaded perfectly otherwise, so it never reads as a broken load and never as VERIFIED.

Last Room Availability and rate parity are real program requirements, but neither prints on the agent-view screen a loader pastes. LRA is an inventory and sell control; parity is a cross-channel comparison. So the platform does not guess them from the paste. A named person, or a CRS record, attests whether a required restriction was carried onto the load, and only a required restriction attested as dropped produces a finding (DROPPED_RESTRICTION).

The authority of that attestation is graded honestly. A CRS record showing an LRA drop is machine-grade and fails the load. A human attestation of an LRA drop caps the task at UNVERIFIABLE_LRA until a CRS record confirms it, rather than overclaiming a failure. A parity drop always caps at UNVERIFIABLE_PARITY, because true parity can only be proven by cross-channel shopping. The engine records the attested fact; it never invents one, so an attestation can never manufacture a false failure.

Separately, when the negotiated rate is present but closed while other inventory still sells on an LRA program, that confirmed breach is its own catch (LRA_FAIL), read directly from the paste.