Support the native ICP-fit model on validate_icp - #29
Merged
Merged
Conversation
The API now takes integration_id="native-icp" on /validate/icp and /discogen/process to score against DiscoLike's own model instead of the customer's BYOK LLM, so callers who have no LLM key — or don't want the spend — can still qualify a domain list. That run returns different columns (ICP Fit / ICP Score / Reasoning instead of Fit / Confidence / Reasoning), and the submit response has always said which set applies. The SDK was dropping everything but task_id, leaving no way to read it short of guessing from the result keys, so Job/AsyncJob now carry column_name. The generated request models already accepted the sentinel — the field is a plain str — so nothing needed loosening; their descriptions pick up the new wording on the next regen against a deployed spec.
The native model emits one calibrated probability, so the API sends reasoning back as null and the app grid shows N/A. Our docs left readers expecting a sentence in that column, which is exactly the assumption the column_name plumbing exists to prevent: someone reads "Reasoning" in the native set, writes code that formats it, and gets None at runtime. Spell out what each native column carries instead - ICP Fit as Yes/No at a 0.50 threshold on ICP Score, the calibrated probability - and why the null column is still there: dropping it would make the native result a different shape from an LLM validation, and callers key off a stable set. LLM validation docs are untouched; that run still returns a real explanation.
The API's LLM validation schema was the last surface forcing a lowercase verdict; it now returns Yes / No like the native engine, DiscoGen and the app already did, so switching engine on the same endpoint no longer flips the casing out from under an exact-string filter. Breaking for clients matching on "yes".
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
integration_id="native-icp"onvalidate.icpanddiscogen.processselects DiscoLike's own ICP-fit model instead of the customer's BYOK LLM — no LLM key, no LLM cost.column_name, so a caller had no way to tell which column set a run produced.Job/AsyncJobnow carry it.ICP Fit/ICP Score/Reasoning (always null).Fitverdict is now title caseYes/Noon both engines. Nothing in the SDK or CLI compares the value, so this is documentation plus the changelog warning.Platform side is on
development(140822e99..e0dd23eb9); docs MR is discolike-api-docs!31.The PR appears safe to merge with no actionable correctness, security, or repository-rule issues identified.
Summary
This PR exposes the native ICP-fit engine sentinel and preserves submit-response column metadata on synchronous and asynchronous jobs.
NATIVE_ICP_ENGINE.column_namethrough DiscoGen and ICP-validation job creation.Reviews (1) · Last reviewed commit: "Document one casing for the ICP-fit verd..."