Introduction
I investigated camera plate-read events that Lambda had received but that were missing from Timestream, the database behind a downstream portal. The main finding was a configuration error: a fixed installation was marked as mobile. That flag sent its events through GPS resolution and geofence validation. They failed those checks and weren't saved.
I removed the mobile flag from the site record, and later reads from the same site saved correctly into Timestream. The repair corrected the configuration used by an existing ingestion rule. It did not introduce a new storage algorithm or change geofence behavior.
I kept a separate camera-identifier problem outside that verified result. Two related identifiers did not resolve to camera rows, and the evidence does not record whether either mismatch was repaired. Both problems appeared as missing database records, but they had different causes and different verification states.
The Rule That Shipped
A site's classification determines which checks its incoming events must pass before being written to Timestream. Mobile-site events must resolve GPS coordinates and pass a geofence check. Static-site events do not require that mobile GPS/geofence gate.
The affected installation was fixed, but its site record incorrectly marked it as mobile. Its events therefore followed a validation path intended for moving cameras. GPS resolution and geofence validation failed, so the events were not saved to the database behind the portal. Removing the mobile flag put the installation on the static branch of the existing rule.
I changed the metadata that selected the validation branch, not GPS processing, geofence geometry, or database write behavior. The static branch also does not remove every other ingestion requirement. An identifier that cannot resolve to a camera row is still a separate problem.
The evidence gives no GPS tolerance or geofence boundary value. I can identify the gate the events failed, but not its precise numerical condition. The correction did not require inventing or adjusting that unknown threshold.
Worked Example
The worked case starts with a batch of camera events captured one morning at the fixed installation. The site record still had the mobile flag. Lambda received the events, but they did not appear in Timestream.
Receipt by Lambda was only an intermediate step. With the site classified as mobile, the events still had to resolve GPS coordinates and pass geofence validation before storage. They failed that validation path, so the writes did not occur. The diagnosis was more specific than data going missing somewhere downstream: an incorrect site classification had routed a fixed installation through the mobile branch.
I then removed the mobile flag from the site record. Subsequent reads from that site saved correctly into Timestream. The site was now correctly classified as static, and those later reads persisted without requiring the mobile GPS/geofence gate.
The failed batch and the verification reads were different inputs. The morning batch shows the failure under the incorrect configuration; later reads show successful persistence after the correction. The evidence does not document replaying the morning batch or recovering its missing records. It also supplies neither the exact payload nor the coordinates, so the failed validation cannot be reconstructed numerically.
Challenges and Tradeoffs
Site metadata directly affected whether an event could be written. Lambda receipt showed that an event had reached the function, but not that it had passed the conditions for persistence. Checking receipt alone would not explain the classification-dependent failure.
The appropriate repair was to classify the fixed installation correctly, rather than weaken the mobile validation rule. Automatically treating failed mobile validation as static would change the behavior: a validation failure would select a branch that did not require the same gate. That is not the repair established here.
The identifier failures needed a separate investigation. One left-camera identifier produced “no camera found.” A related identifier with an additional trailing “_1” also failed to match a camera row. Those results establish unresolved camera-row mappings. They do not establish the lookup implementation's matching rules, explain why each lookup failed, or show that either mapping was later corrected.
Possible follow-up work includes checking site classification during setup and making location-validation failures easier to distinguish from identifier-resolution failures. These are proposals, not shipped changes. Classification checks could catch inconsistent metadata earlier, and clearer diagnostics could make it easier to see where an event stopped. Neither would replace checking that reads actually reached Timestream.
Verification Process
I treated receipt, camera resolution, validation, and persistence as separate checkpoints. An event can reach Lambda without resolving to a camera row, and receipt alone does not prove a successful database write. The investigation included both identifier-resolution problems and a classification-driven validation failure. Attributing every missing record to one cause would overstate the result.
For the fixed installation, the before-and-after sequence is explicit. While the site was marked mobile, its events failed GPS resolution and geofence validation and were not saved. After I removed the mobile flag, later reads from that site saved correctly. That verifies the observed result of the configuration correction, but it does not establish historical recovery or uninterrupted future operation.
I have not verified that either of the two left-camera identifier mismatches was resolved. A separate camera-name discrepancy also remains unconfirmed: records were missing under the searched name, while the closest stored identifier used a different spelling. The evidence does not establish whether this was a naming mismatch that was fixed or a separate unresolved ingestion gap.
The numerical validation condition is also unknown. Without the GPS tolerance or geofence boundary value, I cannot independently reconstruct the precise threshold the original events failed. These limits do not negate the successful post-change writes; they define what those writes do and do not prove.
Conclusion
The completed change was narrow: I removed an incorrect mobile flag from a fixed installation's site record, and subsequent camera reads saved into Timestream. The rule stayed intact. Mobile sites require GPS resolution and geofence validation before storage; static sites do not require that gate.
The investigation also separated two failure modes. Camera-row mismatches and classification-driven validation failures can both appear as missing records, but fixing one does not verify the other. Only the classification correction has a recorded successful post-change result here. The identifier repairs, separate naming discrepancy, historical recovery, and exact numerical validation threshold remain unverified.