Staff Software Engineer @ Navan, ML Flow & Cypress Ambassador, Docker Captain and creator of agent-inspect, writing about production AI agents, TypeScript, observability, testing, and developer tools.
@stratcorealpha, preserving false as recorded evidence instead of collapsing it into absence is a small schema choice with a large debugging payoff. I’d extend the production form to an observation envelope such as observed | unavailable | invalid, with source event ID and observation time, because a missing stored key could mean producer absence or ingestion loss, and a correctly typed boolean can still be stale. Keeping the decision, order request, and fill as separate joined facts is equally important. Would you require a reason code whenever an observation is unavailable so that state never falls back to ambiguous null?
I test one trading strategy on 12 months of historical MT5 data and check three agreed rule cases. I share editable source, assumptions and limits. Know before you risk.
Yes. I would require a reason code for unavailable and invalid observations, and reject an unavailable record that has neither a reason nor an explicit unknown_reason value. Unknown is honest evidence; an invented cause is not.
For example: status=unavailable, reason=source_timeout, sourceEventId=E17, observedAt=..., receivedAt=.... Keep the last good value separately so it cannot silently become the current observation.
Freshness needs its own rule too. A valid boolean can be too old for this decision. I would record the freshness limit and decision time, then test four cases: observed false, unavailable with a reason, unavailable without a reason, and a correctly typed but stale value. The last two should produce an explicit validation or decision result, never default to false.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
@stratcorealpha, preserving
falseas recorded evidence instead of collapsing it into absence is a small schema choice with a large debugging payoff. I’d extend the production form to an observation envelope such asobserved | unavailable | invalid, with source event ID and observation time, because a missing stored key could mean producer absence or ingestion loss, and a correctly typed boolean can still be stale. Keeping the decision, order request, and fill as separate joined facts is equally important. Would you require a reason code whenever an observation is unavailable so that state never falls back to ambiguousnull?Yes. I would require a reason code for unavailable and invalid observations, and reject an unavailable record that has neither a reason nor an explicit unknown_reason value. Unknown is honest evidence; an invented cause is not.
For example: status=unavailable, reason=source_timeout, sourceEventId=E17, observedAt=..., receivedAt=.... Keep the last good value separately so it cannot silently become the current observation.
Freshness needs its own rule too. A valid boolean can be too old for this decision. I would record the freshness limit and decision time, then test four cases: observed false, unavailable with a reason, unavailable without a reason, and a correctly typed but stale value. The last two should produce an explicit validation or decision result, never default to false.