feat: update granite library examples to use Granite 4.1 3B adapters.

[nrfulton]

Misc PR

Type of PR

• Bug Fix
• New Feature
• Documentation
• Other

Description

• Link to Issue: Fixes Use Granite 4.1 in intrinsics examples. #982

Testing

• Tests added to the respective file if code was changed
• New code has 100% coverage if code as added
• Ensure existing tests and github automation passes (a maintainer will kick off the github automation when the rest of the PR is populated)

Attribution

• AI coding assistants used

[github-actions]

The PR description has been updated. Please fill out the template for your PR to be reviewed.

[markstur]

This commented out one is supposed to be a SWITCH alternative. I'm thinking this was a search/replace mistake.

If you intentionally did rename switch -> 4.1 3B, then the other commented references below were missed. Also the alternative would probably not be needed anymore or at least need different comments that explain.

[nrfulton]

Yeah, the commented-out code in intrinsics.py still needs to be changed.

[nrfulton]

reverted that line thanks for catching.

[nrfulton]

We're waiting to merge this one until all of the 4.1 library models are in the HF ibm-granite granite library collection repos.

[planetf1]

uncertainty.py and requirement_check.py haven't had the same change? Omission?

[planetf1]

For factuality-detection.py and factuality-correction.py there isn't get a granite-4.1-3b intrinsic in the repo -- is this expected to be there soon -- before the PR merges?

[planetf1]

A few other things I noticed - unsure if this is out of scope of this pr and/or will be addressed on another issue/pr ?

• AGENTS.md still refers to the granite-4.0-micro model
• similar in various places in our published docs
• does the start_backend default need updating ? (it's granite 4 for now)
• I don't see granite-4.1:3b in the BASE_MODEL_TO_CANONICAL_NAME - no sign of granite-4.1-3b there yet?

[nrfulton]

Thanks, @planetf1 !

uncertainty.py and requirement_check.py haven't had the same change? Omission?

Yes; fixed.

For factuality-detection.py and factuality-correction.py there isn't get a granite-4.1-3b intrinsic in the repo -- is this expected to be there soon -- before the PR merges?

They're being staged; those will exist for 4.1 prior to release. The context_relevance intrinsic will not exist for 4.1, so I reverted that example to 4.0.

AGENTS.md still refers to the granite-4.0-micro model

Fixed.

similar in various places in our published docs

Doing a sweep now. A bit more annoying to find everything :) Update: did a sweep of the docs and tests, and changed everything that I thought made sense. The 4.0 models still get mentioned in certain places, and I think those remaining mentions are okay:

1. design docs that were written at 4.0 vintage -- preserving the model ids that were used at the time those decisions were made is best practice.
2. some docs that are specifically about h vs non-h (we don't have h in 4.1 so arguably those could be removed entirely, but I'll leave that for later because the 4.0 models will remain in common use for a while)
3. some other misc places where I judged keeping the 4.0 reference is reasonable.

@planetf1 what repos should I be sweeping (in addition to this one)?

does the start_backend default need updating ? (it's granite 4 for now)

This was already done by #964; I just hadn't merged main in a minute.

I don't see granite-4.1:3b in the BASE_MODEL_TO_CANONICAL_NAME - no sign of granite-4.1-3b there yet?

Done.

[nrfulton]

Current status: there are three examples still failing:

• fact correction: no worries so far; still staging looks good.
• fact detection: no worries so far; still staging looks good.
• context_relevance: need to investigate. this is the transformations vs parameters bug in the io.yaml for that intrinsic. It's also the reason tests are failing on this PR. Fix is in-flight over on HF. Fix is in on HF; should be good here now.

[nrfulton]

Saving a helper script here for the next release. Drop in the intrinsics dir; runs all of the local examples. Gives a tighter ooda than waiting on nightlies.

#!/usr/bin/env bash
set -uo pipefail

SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
entries="["
first=true

for py_file in "$SCRIPT_DIR"/*.py; do
    echo $py_file;
    filename="$(basename "$py_file")"
    stdout="$(uv run python "$py_file" 2>/tmp/_intrinsic_stderr)"
    exit_code=$?
    stderr="$(cat /tmp/_intrinsic_stderr)"
    entry="$(python3 -c "
import json, sys
print(json.dumps({
    'file': sys.argv[1],
    'exit_code': int(sys.argv[2]),
    'stdout': sys.argv[3],
    'stderr': sys.argv[4],
}))" "$filename" "$exit_code" "$stdout" "$stderr")"
    if [ "$first" = true ]; then
        first=false
    else
        entries+=", "
    fi
    entries+="$entry"
done

entries+="]"
echo "$entries" > "$SCRIPT_DIR/run_outputs.json"

one-liner to get failed tests:

python3 -c "import json
print('Failures:\n *','\n * '.join([failed['file'] for failed in json.load(open('run_outputs.json', 'r')) if failed['exit_code'] != 0]))"