What problem does this solve?
When a required dependency isn't installed in the inspection environment (e.g. xgboost, lightgbm), the inspector can't determine the framework. The LLM interpretation stage (A3) then has to guess from class name alone, which is unreliable. Users who know their model's framework have no way to provide that information upfront.
Proposed solution
Add --framework as an optional flag on the deploy command:
inference-engine deploy ./model.pt --framework pytorch
inference-engine deploy ./model.pkl --framework xgboost
Effect:
- Sets
raw_facts["framework_hint"] before extraction begins
- Passed to the LLM interpretation prompt as trusted input
- If confidence would otherwise be
low but framework is now known, may skip the clarifying question flow entirely
- Does not suppress structural extraction or skip inspection errors
The flag accepts: sklearn, pytorch, transformers, xgboost, lightgbm, catboost, onnx, sentence_transformers.
Alternatives considered
Requiring users to edit deployment.json manually after a failed deploy. This is error-prone and breaks the single-command deploy flow.
Area
CLI (deploy / fix)
What problem does this solve?
When a required dependency isn't installed in the inspection environment (e.g.
xgboost,lightgbm), the inspector can't determine the framework. The LLM interpretation stage (A3) then has to guess from class name alone, which is unreliable. Users who know their model's framework have no way to provide that information upfront.Proposed solution
Add
--frameworkas an optional flag on thedeploycommand:Effect:
raw_facts["framework_hint"]before extraction beginslowbut framework is now known, may skip the clarifying question flow entirelyThe flag accepts:
sklearn,pytorch,transformers,xgboost,lightgbm,catboost,onnx,sentence_transformers.Alternatives considered
Requiring users to edit
deployment.jsonmanually after a failed deploy. This is error-prone and breaks the single-command deploy flow.Area
CLI (deploy / fix)