Repository navigation
Prompting Fallbacks for Granite Library Intrinsics #993
Description
We should think about a strategy and acceptance criteria for allowing prompting fall-backs from granite library intrinsics. The construction and evaluation of those prompts (e.g., for proprietary models) should likely be owned by the developers of those libraries, but we'll need to provide infra for them.
Activity
jakelorocco commentedon Sep 3, 2026
Repurposing this for the prompt based io.yamls.
jakelorocco commentedon Sep 3, 2026
Results of meeting:
anymodel is used instead of for a specific modelprompttype for adapters / io.yamlanybased prompt adaptersThe presumed structure of the new repos will be:
<capability>/<model or any>/prompt/io.yamlplanetf1 commentedon Sep 10, 2026
Summary of my suggestions from an out-of-band discussion on the design (prompted by a couple of questions Alex raised):
PromptBinding(WeightsBinding), a fourth binding reality alongside local_file/embedded/server_mediated, not anOptionalweights field. Keeps every call site (adapter_scopeetc.) working unmodified for either case.prepare()/release()as genuine no-ops.activate()not — it should log that the soft adapter fired, at the same severity as a real adapter activating. That's separate from the "warn if a prompt foranymodel is used" case above — that warning belongs whereanyis chosen over model-specific, not at this normal-severity log.IntrinsicsRewriterinstruction-injection rather thanIOContract.build_prompt— that method is unimplemented and uncalled anywhere in the codebase today. See design(adapters): IOContract.build_prompt is unimplemented and uncalled everywhere — decide whether to finish it or remove it #1644, filed separately, unrelated to this issue.ServerMediatedBinding.planetf1 commentedon Sep 25, 2026
Two items for this issue's infra half, surfaced while reviewing #1654. Recording them here so they survive whatever that PR decides, since both are about the contract between Mellea and whoever authors the prompts.
Mellea should validate that a prompt
io.yamlcan actually work. The prompt rung is implemented entirely by the rewriter injecting theio.yamlinstruction, and that field is optional: onlymodel,response_formatandtransformationsare required. So a promptio.yamlwith no instruction resolves, registers and runs. The base model receives the bare conversation, llguidance forces the output into the declared schema, the caller gets a well-formed score, and telemetry records success. I verified that end to end. Since this issue puts prompt authoring with the library developers, Mellea is the only place that can catch it, and the failure mode is a confident wrong number rather than an error. Raised on the PR, and worth keeping in scope here in case it is deferred.The prompt
io.yamlcontract is undocumented. Nothing states what a prompt file must contain for the infrastructure to work:instructionis required in practice though optional in the schema,response_formatdrives constrained decoding and so is load-bearing, andparameterscarries the token caps the trained adapters set (the published files use 15 forrequirement-checkanduncertainty, 4096 forcitations). The consumer of that contract is a different team, so writing it down is part of providing the infra rather than a docs nicety.Neither is a blocker for the LocalHF work. Both are cheap now and awkward later, once prompt files exist upstream and a malformed one is already in someone's cache.