SystemOne Go DTO: one-sided Noul criteria compatibility and required numeric field presence

[CodeyCoo]

Using github.com/OpenRouterTeam/go-sdk v0.8.31 with SystemOne.Create, I found two DTO/contract questions for Jev.

1. One-sided Noul criteria

The TypeSafe System One API permits criteria descriptions for true and false to be omitted independently. Is OpenRouter's /api/v1/systemone intended to accept a criteria object containing only one side? The Go SDK's DecisionsNoulQuestionCriteria has non-pointer True and False union fields, and its generated docs mark both required. If a caller sets only True, json.Marshal(components.DecisionsRequest{...}) fails with:

json: error calling MarshalJSON for type *components.DecisionsNoulQuestionCriteria: json: error calling MarshalJSON for type *components.False: could not marshal union type False: all fields are null

If the endpoint accepts one-sided criteria, could the Go DTO represent the absent side? If the endpoint intentionally requires both, could the System One compatibility documentation state that difference from TypeSafe?

2. Required numeric response fields lose presence information

DecisionsNoulAnswer.Noul and DecisionsScoreAnswer.Score are float64 fields. The generated UnmarshalJSON methods accept responses missing these fields and leave them as 0. For example, unmarshalling both {"type":"noul"} and {"type":"noul","noul":0} into components.DecisionsNoulAnswer produces identical values; likewise for score. The adapter cannot distinguish a malformed response from a legitimate zero.

Could the decoder reject missing required fields or expose presence information (for example, pointers or required-field validation)?

This was reproduced against v0.8.31 with Go 1.27.0; no API key or live request is involved.

[CodeyCoo]

Additional v0.8.31 finding: DecisionsResponse.Usage is a non-pointer struct and its required InputTokens/OutputTokens are non-pointer int64 fields. A local SystemOne.Create test with a valid Noul answer but no usage field returned success with all usage counters zero. Missing usage and valid zero usage are indistinguishable, like the Noul/Score answer values described above. Please include usage-field presence in the required-response validation discussion.

[CodeyCoo]

Additional v0.8.31 finding (local SystemOne.Create + httptest): a valid Score answer with legend: {"0":{"rank":9007199254740993},"1":"high"} is decoded into a DecisionsScoreAnswer.Legend["0"].MapOfAny whose rank is float64(9007199254740992). The request criteria can preserve the original as json.Number, but structured response legends use map[string]any / []any and lose integer precision. Please consider lossless number decoding for Score legend object/array values. Downstream can detect and reject a legend that no longer matches request criteria, but cannot recover the original value from the SDK DTO.

[CodeyCoo]

Correction after checking the published System One OpenAPI at https://openrouter.ai/docs/api/api-reference/systemone/submit-a-system-one-request: DecisionsNoulQuestion.criteria.required lists both true and false. The one-sided criteria case is therefore an OpenRouter API compatibility difference from our portable/TypeSafe contract, not a Go SDK serialization defect. Please treat that part of the issue as API clarification only. The required Noul/Score/usage response-field presence and structured Score legend number precision findings remain SDK DTO issues.