Your prompt file is an ML artefact.
Nobody is tracing it to a requirement.

In 2026 a consumer app's "ML" is half trained models and half natural-language instruction files. Requirements traceability research only knows how to follow the first half. This project built — and then deliberately broke — a framework that follows both.

Requirements engineering assumes software that behaves the same way twice.

A user story says what the system shall do. That grammar was built for deterministic code, where a requirement is either met or it isn't. Machine learning does not offer that courtesy.

McKinsey's State of AI reports put organisational AI adoption at 60% in 2023 and 90% in 2025. Consumer teams are shipping ML features inside ordinary agile sprints — with no more time for requirements analysis than before, and specification techniques that never anticipated a probabilistic answer.

And then the ML artefact stopped being a model.

Since ChatGPT in 2022, consumer teams increasingly compose features on hosted foundation models rather than training their own. The result is a stack that spans two paradigms with different artefacts, different versioning surfaces, and different ways of failing.

Existing RE4AI traceability work — PROV-ML, ML-Schema, MSR4ML — assumes the traced artefact is the output of a training procedure. None of them has a representation for a natural-language specification file. That leaves a growing share of shipped ML behaviour outside any traceability chain at all.

Six gaps in the literature, turned into nine requirements the framework itself has to pass.

The project follows the DSRM process model of Peffers et al.: identify the problem, define objectives, build the artefact, demonstrate it, evaluate it. The point of the derivation below is that the framework's own success criteria were written before it was built, from documented gaps rather than assumed ones.

Four components. Two of them are documents you already half-write.

The framework deliberately extends existing practice rather than introducing a new tool — new tooling imposes adoption barriers, which is exactly the overhead that kills documentation in the first place.

The whole mechanism is a naming discipline.

No new tool, no plugin, no database. A requirement identifier is written into the artefacts each tool already produces, so the chain is queryable in both directions with what a team is running anyway.

# Trained model — MLflow run tags and registry description
mlflow.set_tag("req_ids", "REQ-FCT-01")
description="Satisfies REQ-CAT-01. RAMC: docs/ramc-classifier.md"

# Dataset version — DVC via annotated Git tags
git tag -a "data-v1.1" -m "REQ-OCR-01: Added receipts"

# LLM-agent — a commit message on the instruction file
git commit -m "[REQ-CAT-01] Add Beverage / Food disambiguation rule"

# Eval harness — one JSONL entry per criterion run
{ req_id: "REQ-CAT-01", skill_md_sha: "c0fc2aa",
  provider_model: "moonshot-v1-8k", agreement: 0.926,
  test_set_sha: "9574b207…" }

One requirement, four hops, no help.

On 29 July 2026 an external evaluator (E01) — a second-year CS undergraduate with no prior exposure to the repository — was asked to traverse the chain in both directions. The only briefing given was what MLflow is for.

ShareLah: three ML components chosen to straddle the split.

A social expense management prototype — the kind of app where ML is a convenience, not a safety function. Two components are LLM-agents governed by instruction files; one is a trained regression model. The framework had to cover all three with the same conventions.

The criteria were written first. Then they were run.

Every criterion below existed as a quantified threshold in §11 of a RASC before the harness executed. That is the property Model Cards lack: a post-hoc document cannot fail its own criteria, because its criteria are written from the results.

The failures are the finding.

Each of these could have been made to pass. None of them was.

Three quarters of the evidence section was already lying around.

DR8 claims the framework adds little work beyond MLOps and Git practice a team already runs. Rather than rest that on self-reported timings, every field instance in §12 of all three artefacts was audited and classified as machine-derivable (copyable from MLflow, DVC, the Git log or results.jsonl without interpretation) or author-supplied.

Every acceptance metric passed. That was not the interesting part.

Thirty participants, four-point forced-choice Likert (no neutral midpoint), acceptance threshold 3.0. Behaviourally: 28 of 30 (93%) accepted the suggested category unmodified. 7 (23%) reported an incorrect or missing extracted field — and overall satisfaction still sat at 3.67 with every participant at or above threshold. Consumers accepting a component with a visible error rate is precisely the tolerance that separates consumer from safety-critical contexts.

77% said they understood the badge. Four of them thought it meant the receipt was real.

The confidence badge is how the OCR component discharges its uncertainty-communication requirement. On the Likert item, 23 of 30 scored at or above threshold. The free-text answers told a different story: four participants — two of whom had claimed understanding — described the badge as signalling document authenticity.

"The authenticity of the document is high" · "its legit" · "Thought it was ligitamacy of the company" · "Receipt validity"

Nine design requirements, judged against the evidence.

A single traceability chain, one vocabulary, both paradigms.

One evaluator, in one session, traced a requirement forward through a RASC to a commit on a markdown file, and traced an MLflow run backward through a RAMC to its originating requirement. The cost per step proved effectively invariant to direction and to the paradigm of the artefact at the far end. That invariance — not any aggregate success rate — is the operational content of the claim.

It is a capability PROV-ML, ML-Schema and MSR4ML cannot supply, each taking the traced artefact to be the product of a training procedure. It is equally the respect in which RAMC and RASC extend rather than duplicate Model Cards and Datasheets for Datasets, both of which remain descriptive artefacts produced after the decisions they document.