Governed adapter foundry

Use case

An adapter foundry breeds small capability overlays for a shared base model. It is a practical first step because adapters are smaller than full model descendants, easier to version, and easier to roll back.

Pipeline

FUNCTION adapter_foundry_job(request, policy)
    REQUIRE request.base_model IN policy.approved_bases
    REQUIRE request.data_sources WITHIN policy.allowed_data

    dataset <- BUILD_DATASET(request.data_sources, filters: policy.filters)
    adapter <- TRAIN_ADAPTER(request.base_model, dataset, budget: policy.training_budget)
    package <- PACKAGE_ADAPTER(adapter, request.base_model)
    scorecard <- EVALUATE(package, policy.adapter_suites)

    IF HARD_GATES_PASS(package, scorecard) AND VIABILITY(package) >= policy.archive_threshold
        REGISTER(package, scorecard)
    ELSE
        RECORD_REJECTION(package, scorecard)
    END IF
END FUNCTION

Foundry records

Every adapter should record base model, adapter method, rank or equivalent capacity, training data lineage, hyperparameters, teacher outputs if used, evaluation results, license constraints, and compatible runtime profiles.

Release path

Start with offline evaluation, then shadow traffic, then canary for low-risk tasks. Do not hot-swap adapters into high-impact workflows without a rollback path and calibration evidence.

Failure modes

Adapters can interfere with each other, overfit a narrow task, inherit teacher errors, obscure provenance, or encourage too many small artifacts. The foundry should include retirement and consolidation, not only creation.