No unknown fields¶
noUnknownFields enforces that only explicitly allowed fields may appear in the boundary input.
Any field not listed in the allowed set is treated as an unknown key and produces a boundary‑level error. This rule is ideal for strict schemas, locked‑down shapes, and any boundary where additional or unexpected fields must be rejected.
Signature¶
export function noUnknownFields(...allowed: string[]): BoundaryRule
Parameters¶
| Parameter | Data type | Description |
|---|---|---|
allowed |
string[] |
The complete set of field names permitted in the boundary input. |
Events¶
| Event code | Description |
|---|---|
boundary.cannot.allow-unknown |
A field appeared that is not part of the allowed set. |
Design rationale¶
- Enforces strict structural control over boundary input.
- Flags every unknown key individually, ensuring precise contributor feedback.
- Evaluates only the keys present in fields, not the original input shape.
- Emits a boundary‑level error per unknown field.
- Does not modify field values or decisions — it only adds boundary‑level issues.
- Ideal for APIs where unrecognized fields must be rejected rather than ignored.
Invoke¶
noUnknownFields runs during the boundary decision phase. It is not affected by normalization mode or parsing rules.
The rule activates when a field key exists in fields that is not included in the allowed list.
Examples¶
Valid: all fields allowed¶
noUnknownFields("id", "name", "email");
// fields = { id, name } → OK
// fields = { id, email } → OK
Invalid: unknown fields present¶
noUnknownFields("id", "name");
// fields = { id, name, age }
// → boundary.cannot.allow-unknown at $.age
Multiple unknown fields¶
noUnknownFields("a", "b");
// fields = { a, x, y }
// → boundary.cannot.allow-unknown at $.x
// → boundary.cannot.allow-unknown at $.y