Back to notes
The Tesseract MemoryTechnical note

What a keyword support score can tell us

Brimfox AI Core makes its explanation checks inspectable, but shared vocabulary is a narrower signal than a supported claim.

Topics

Make the calculation visible

The verifier receives explanation and grounding objects separately. It takes the headline, fit, taste and texture fields, then adds substitution guidance and quick takeaways as text units. A recursive walk collects string values from the grounding object.

Each unit first passes a literal phrase check for language including treatment claims and allergy-safety certainty. A matching unit increments the dropped count and adds a warning. Otherwise, the algorithm compares lowercase alphanumeric keywords of at least four characters with the grounding-term set.

The share of matching keywords is compared with a threshold, defaulting to 0.28. The response reports supported, dropped and total units, deduplicated warnings, a grounding-term count and an overall outcome. A reader can trace that outcome to a small set of rules rather than an unexposed model judgment.

Keep the interpretation as narrow as the rule

A sentence can reuse the right words while changing the subject, quantity or negation. Keyword overlap does not establish that the relationship it asserts is true. The unsafe-phrase list is also literal matching, not a complete medical or food-safety policy.

Supported therefore means that a unit cleared this calculation. It does not mean that the claim was independently verified. The response contains counts, not approved claim identifiers or a rewritten explanation.

Nothing in this handler removes text from Brimfox's response. Laravel would have to define that behavior at the integration point, and its current recipe-explanation path does not call the verifier.

Turn the weak cases into evaluation cases

The outer request is typed, but the nested dictionaries are broad. The algorithm converts an arbitrary configuration value into the support threshold. Constraining that value at the request boundary would make malformed input fail before calculation.

Extraction also converts selected values to strings before testing whether they are empty. An omitted field can therefore become the nonempty word None and count as another unit. This is visible in the source, not a runtime failure reproduced during this review.

The existing verifier test checks an unsafe allergy statement. An evaluation set still needs omitted fields, threshold boundaries, misleading overlap and mixed supported and unsupported units, as well as the HTTP route and product acceptance rule. The dated six-test report is historical evidence, not a fresh evaluation of those cases.

How the prototype computes a support outcome

Selected text is checked against literal unsafe phrases and grounding keywords; the result is counts, not a rewritten explanation.

Direct callResponse / returnBlocked / denied
Structured input
Deterministic checks
Support metadata

Scroll or drag the background to move. Use the zoom buttons to resize.Arrow keys move between components. Enter selects.

Choose a component to explore

Select a numbered component on the map or use the component menu. Its details and connections will appear here.

No component selected.

All connections (8)
  1. 01 · Explanation object03 · Text-unit extractionSelect explanation fields · Direct call
  2. 02 · Grounding object04 · Grounding keyword setCollect and tokenize strings · Direct call
  3. 03 · Text-unit extraction05 · Unsafe-phrase checkCheck each unit · Direct call
  4. 05 · Unsafe-phrase check07 · Unit counts and warningsPhrase match: count as dropped · Blocked / denied
  5. 05 · Unsafe-phrase check06 · Keyword-coverage thresholdNo phrase match · Direct call
  6. 04 · Grounding keyword set06 · Keyword-coverage thresholdKeyword membership · Direct call
  7. 06 · Keyword-coverage threshold07 · Unit counts and warningsCount support or rejection · Response / return
  8. 07 · Unit counts and warnings08 · Aggregate outcomeSummarize counts · Direct call