Interface: RuleTermDraftDto
@kortexya/reasoninglayer / RuleTermDraftDto
Interface: RuleTermDraftDto
Section titled “Interface: RuleTermDraftDto”Defined in: src/types/inference.ts:1960
One side of a drafted rule (its head or one antecedent): a sort name plus a feature map.
Remarks
Section titled “Remarks”Serialization format: Untagged (RuleDraftFeatureValue).
Feature values are raw JSON scalars — "hello", 42, true — or the
string form of a variable (e.g. "?X"). They are NOT tagged
import(‘./values.js’).ValueDto objects: there is no
{"type": "String", "value": "..."} wrapper anywhere in a rule draft.
The backend converts each of these to a TermInputDto::InlineByName when the draft is
submitted to addRule, so a drafted term maps directly onto TermInputDto’s
inline-by-sort-name variant. A negated antecedent is the exception: it is
submitted inside the negation carrier (see RuleTermDraftDto.negated).
Properties
Section titled “Properties”features?
Section titled “features?”
optionalfeatures?:Record<string,RuleDraftFeatureValue>
Defined in: src/types/inference.ts:1964
Feature name → untagged scalar value, or a variable string such as "?X".
negated?
Section titled “negated?”
optionalnegated?:boolean
Defined in: src/types/inference.ts:1975
true on an ANTECEDENT that must NOT hold — negation as failure over the
tenant’s facts (“there is no meat topping on the pizza”). Absent is an
ordinary positive condition; the engine omits it when false. A head is
never negated.
A negated antecedent is not written with a flag: submit it through
addRule wrapped in the reserved negation carrier — not(psi(...)) —
which the rule listing renders back as NOT EXISTS ….
sortName
Section titled “sortName”sortName:
string
Defined in: src/types/inference.ts:1962
The sort (type) name of this term.