Skip to content

.why_not mis-evaluates views whose rules have constants in the head, reporting derived rows as not derived #291

Closed

Description

@jsam

The .why_not defect:

>>> ?candidate("s-43", T)
<<< 3 row(s): escalate, issue_refund, open_ticket                  # the row exists
>>> .why_not allowed("s-43", "issue_refund")
<<< "Blocker: Body predicate 0 (candidate(\"s-43\", \"issue_refund\")) failed: No matching tuples in candidate"
>>> .why_not allowed("s-43", "open_ticket")                         # this row IS derived (see ?allowed above)
<<< "allowed(\"s-43\", \"open_ticket\") was NOT derived: ... No matching tuples in candidate"
>>> .why_not candidate("s-43", "issue_refund")
<<< clause 1 and 2: "Head unification failed: Target arity 2 does not match head arity 2"

Found while building the sales demo. .why_not must be correct for 'decisions your agents can prove': a derived row is reported as NOT derived, and .why_not on the view itself fails with 'Head unification failed: Target arity 2 does not match head arity 2'.

Activity

  1. jsam commented on Oct 5, 2026

    @jsam
    ContributorAuthor

    Done in #353 (merged, CI green).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions