Type Alias: FeatureInputValueDto

@kortexya/reasoninglayer

---

@kortexya/reasoninglayer / Homoiconic / FeatureInputValueDto

Type Alias: FeatureInputValueDto

FeatureInputValueDto = FeatureInputTermRef | FeatureInputConstrainedVariable | FeatureInputVariable | FeatureInputInlineTerm | FeatureInputInlineTermByName | FeatureInputValueDto[] | string | number | boolean

Defined in: src/types/homoiconic.ts:94

Input value type for features in homoiconic inference requests.

A structural (untagged) union with 10 variants. The variant ordering matches the Rust #[serde(untagged)] deserialization order — this ordering is critical because Rust tries each variant in definition order.

Variants (in Rust deserialization order):

1. TermRef — { term_id: string } — reference an existing term
2. ConstrainedVariable — { name: string, constraint: TermInputDto } — variable with constraint
3. Variable — { name: string } — unconstrained variable (e.g., "?X")
4. InlineTerm — { sort_id: string, features?: ... } — inline term by sort UUID
5. InlineTermByName — { sort_name: string, features?: ... } — inline term by sort name
6. List — FeatureInputValueDto[] — list of feature input values
7. String — string — string primitive
8. Integer — number (integer) — integer primitive
9. Real — number (float) — real primitive
10. Boolean — boolean — boolean primitive

Remarks

Serialization format: Untagged (structural discrimination).

Critical ordering constraint: ConstrainedVariable (variant 2) MUST come before Variable (variant 3) — both have name, but the constrained version also has constraint. Rust’s serde(untagged) tries them in definition order.

Use FeatureInput.* builders to construct these values safely. Do NOT use with term CRUD endpoints — use import(’./values.js’).ValueDto instead.