Interface: TermInputDesignator
@kortexya/reasoninglayer / TermInputDesignator
Interface: TermInputDesignator
Section titled “Interface: TermInputDesignator”Defined in: src/types/homoiconic.ts:110
An existing term, addressed through its sort’s @key.
Remarks
Section titled “Remarks”The one variant that neither creates a term nor describes a pattern: it NAMES a term that already exists, the way TermInputRef does, but by the key a caller actually holds rather than by a UUID it does not.
⚠️ Its features are TAGGED, inside an otherwise untagged union. The
backend field is a ReferenceDesignatorDto, whose features are
HashMap<String, ValueDto> — the term-CRUD format. Measured 2026-09-19:
{"designator":{"sort_name":"invoice","features":{"number":{"type":"String","value":"INV-1"}}}}
resolves, while the untagged {"number":"INV-1"} is refused with
422 data did not match any variant of untagged enum TermInputDto. This is
the one place the two serialization formats meet, and the reason
ReferenceDesignator is reused here rather than restated.
What it does, all measured:
- resolves to the term that already exists and mints nothing —
200, and the sort’s extent is unchanged; - a key matching nothing is refused:
no term of sort 'invoice' carries @key 'number' = "NOPE"; a reference designator names an existing term, it never creates one; - a NON-key feature is refused:
feature 'status' of sort 'invoice' is not a @key feature; a designator addresses a term only through its @key. A designator is an address, not a filter.
⚠️ A PATTERN door refuses it. A rule antecedent answers rule rejected: body antecedent 0 could not be resolved (a \designator` addresses an existing
term of sort `invoice` and this route does not resolve one…), and a backward-chain goal answers 400 Invalid goal term`. A pattern has no extent
to address, so use TermInputInline there.
Properties
Section titled “Properties”designator
Section titled “designator”designator:
ReferenceDesignator
Defined in: src/types/homoiconic.ts:111