Build a useful investigation brief
Define an explicit token matrix
List the documented true and false representations, supported normalization, blank behavior, and invalid-token response. Include a nonempty false string and a word that is not accepted. Keep expected outcomes independent of implementation so the test does not repeat the same truthiness rule that may be causing the defect.
Inspect normalization and fallback order
Trace the source token, trimmed or case-normalized text, parser result, default selection, and saved boolean. Locate the first divergence. Check whether an unrecognized value returns an explicit failure or falls through to a default, and whether that default differs between new-record creation and an update operation.
Compare the bounded parser change
Evaluate a change at the implicated conversion boundary and repeat the entire matrix. Include ordinary accepted tokens and invalid controls. Keep field semantics unchanged unless a separate contract decision supports it; accepting more spellings is not automatically a correction if users cannot predict how ambiguous or missing values will be assigned.
What to carry forward
Produce the token matrix, conversion trace, and outcome of the bounded comparison. State where contract decisions remain unresolved. A supported fix preserves documented true and false meanings and handles invalid input explicitly, rather than making every source string parse by silently assigning whichever boolean default is convenient.
Technical background: Google Cloud documentation.
Keep the decision with the work.
Use a Work Item in Aglet to record the problem, the evidence you have, and the next decision. Add an owner and priority, then keep updates in the discussion so the next person can follow the reasoning.
Create an account See the product workflow