A Fast Feature Lookup Still Has to Mean the Right Thing

Botie’s fault model expects temperature followed by vibration. A fast key lookup returns the fields in a different order, using an older feature definition. The storage request succeeded, but the input no longer means what the model was trained to interpret.

The database choice follows the task. We will assemble a serving record only when its identity, definition and freshness match the model request, and retain an explicit fallback when they do not.

Match the entity and feature definition, check decision-time availability and age, then assemble the names in the model’s required order.

{
  "route": "predict",
  "vector": [
    30,
    0.8
  ]
}

A keyed serving record can be useful when the request already knows the tenant and asset and needs a small fixed set of inputs quickly. A document can keep related feature values and their metadata together. A relational table can also serve keyed reads; measure the existing system before introducing another database.

A fleet-wide historical training join has a different access pattern. Keep the source of truth, derived feature view and serving copy distinct in the design so each has an owner and a rebuild path.

The exercise does not rank database brands. It exposes the contract that any chosen serving path must meet.

A feature name can remain the same while its meaning changes. Vibration might move from a raw reading to an average over a different time window. Units, missing-value rules and preprocessing can also change. Record a version or digest for the definition expected by the deployed model.

The feature definition version is separate from the document schema and source record revision. Compatible field shapes do not prove compatible model inputs. Reject or adapt a mismatch under an explicit policy instead of treating every readable dictionary as usable.

Our request requires bearing-v2 exactly. The fixture does not implement semantic version negotiation.

Event time tells us when the measurement describes the asset. Availability time tells us when that value became usable by this serving path. An old event can arrive after the decision it is meant to support.

The earlier SQL lesson showed historical point-in-time selection. This lesson checks one retrieved document against a decision time and a maximum measurement age. It cannot reconstruct an overwritten historical value; if the current record fails, the route stays fallback unless another authorised source supplies suitable evidence.

A lookup of today’s latest document is not a historical training query.

event_time = 100
available_time = 115
decision_time = 110
print(event_time <= decision_time)
print(available_time <= decision_time)

True
False

The model supplies an ordered feature-name list. Read each required name from the document in that order. Check for absent, nonnumeric and nonfinite values before constructing the vector. Extra document fields should not silently become model inputs.

A missing value policy belongs to the model’s definition. If training used a particular imputation rule, serving must use the compatible rule. Our exercise has no trained imputer, so it falls back rather than inventing a zero.

The vector’s positions are part of its meaning, even when all its entries are valid numbers.

The authenticated service establishes tenant scope and builds the permitted key. It should use credentials limited to the needed records and operations. A browser should call the application boundary rather than receive broad storage credentials.

The read mode must suit the operation. A stronger table read can reduce one kind of staleness, but it cannot refresh a feature pipeline that has not produced a new document. Check the measurement metadata even when the storage read succeeds.

This external reference obtains a document. It deliberately leaves the application’s feature checks as a separate step.

import boto3

table = boto3.resource("dynamodb", region_name="us-east-1").Table("maintenance_features_dev")
response = table.get_item(
    Key={"pk":"tenant:north:asset:P7"},
    ConsistentRead=True,
)
item = response.get("Item")
print(item is not None)

A missing document, wrong feature version or stale measurement should not silently proceed to prediction. Decide whether the application can use a documented baseline, request a fresh measurement, or ask for human inspection. That decision depends on the task’s consequences.

Our function returns fallback with an empty vector. A production interface should record the reason without leaking another tenant’s data, and should make clear when it is showing a baseline rather than the requested model result.

A fallback is an application outcome. It is not evidence that the asset is healthy.

A compact serving record often keeps only the latest state. Retain an appropriate prediction log or immutable references that identify the model, feature definition and input data used, subject to privacy and retention requirements. An offline store can support historical reconstruction if its time and revision semantics are understood.

Compare training and serving transformations with shared cases. A correct training query cannot compensate for a serving adapter that changes units or feature order. Monitor missing inputs, age and version mismatches alongside model performance.

The record checks test input compatibility, not the accuracy or fairness of the trained model.

A new feature definition may require a new serving namespace or an explicit versioned rollout. Backfill the required entities, compare representative predictions, and switch the model and feature contract together. Keep the earlier version long enough for the agreed rollback and audit needs.

If another database is added, account for its projection lag, rebuild process and access boundary. A smaller inference lookup can be worth that work, but a second current copy also creates another place whose freshness must be explained.

Botie now has a concrete boundary between finding a document and using it as model input.