Check that an imported status is actually in the approved lookup

A status importer accepts a value that nobody configured. The problem is not a missing translation or an unrecognised piece of equipment: the code has mistaken an inherited object property for an entry in its own approved status table.

This fictional investigation concerns an operations tool that imports staff-observation states. It keeps the submitted value intact, isolates the membership check and verifies that unknown input cannot move the work into an approved state.

Follow one unexpected value

The approved map contains two incoming status codes: recorded, meaning that an observation has been captured, and awaiting_review, meaning that a responsible colleague must assess it. Neither code establishes that equipment may be returned to use.

Imported record W-61 instead carries the literal value toString. The application's map is a normal JavaScript object. Its validation uses a truthy property lookup as proof that the code is supported:

if (statusMap[incomingStatus]) {
  acceptMappedStatus(incomingStatus);
}

For a plain object, that lookup can find a property inherited from its prototype. In the inspected example, toString resolves to an inherited function, so the condition passes despite the absence of an approved entry with that name. The later display is unhelpful, but the membership error has already occurred.

The reviewer preserves W-61's original input and records the map's own configured keys. There is no reason to rename the incoming value to recorded or discard its spelling to make it fit. It is unknown under this contract.

Define what counts as an entry

The bridge's documented rule is exact membership in its approved map. The supported correction checks for an own property, using Object.hasOwn(statusMap, incomingStatus) before obtaining the mapped value. The ECMAScript definition of Object.hasOwn delegates that question to an own-property check.

An appropriately constructed Map could express the same intended membership boundary. The implementation chooses one consistent structure and checks the supported runtime rather than scattering different tests through the importer.

This is not permission to accept every own property as a valid business instruction. The map itself is controlled configuration whose entries and values are reviewed. Input type, permissions, record identity and the allowed transition still require their normal checks. Membership establishes only that the code belongs to the configured vocabulary.

Put the unknown record into a useful review path

With the corrected check, W-61 is retained for investigation without applying a status transition. The operator sees the original received value and the reason it was not mapped. The existing observation state remains intact.

The source owner then supplies a separately identified corrected test record W-62 with the intended supported code awaiting_review. The importer validates that record and applies the corresponding state under the normal rules. The history distinguishes the rejected input from the corrected submission; the system does not silently rewrite W-61 as if it had always contained the supported value.

The receiving colleague can now explain both results: one input did not belong to the vocabulary, while the new authorised input did. That explanation is more useful than a generic successful-import count.

Test the boundary from several directions

The exercise also includes an independent observation W-70. It keeps its existing state while W-61 is rejected and W-62 is processed. A user without the required import authority cannot apply even a known code. These controls show that the fix is specific to vocabulary membership and does not bypass the surrounding permission model.

In the fictional acceptance record, both inherited-name inputs stop, both configured codes follow their proper path and the unknown record remains available for an authorised investigation. No equipment-release decision is inferred from any of those statuses.

Leave the map maintainable

The handover identifies who can add a source code, how its target meaning is reviewed and which contrary inputs belong in regression checks. A future integration change should not restore the shorthand truthy lookup merely because the map usually contains ordinary words.

The lesson is to inspect the boundary where data becomes a business state. A syntactically valid string, a successful object lookup and an approved vocabulary entry are different observations. Following them separately can reveal a defect that ordinary demonstration records never exercise.

For operations application work, bring the original import value, the configured mapping and the resulting record. The project brief helps identify the receiving decision without exposing private operational data.