Q100 - Why_must_RAIDT_be_treated_as_the_project_object_before_its_i

Q100 — Why must RAIDT be treated as the project object before its internal components?

← RAIDT · Star C0 - RAIDT Core, Definition, Values, Claims and Innovation · primary item: C0.01 · RAIDT

Appears in sources
Answer

RAIDT must be treated as the project object before its internal components because the framework is an integrated governance method whose parts derive their meaning from the whole. The papers describe RAIDT as comprising an outcome taxonomy, an evidence protocol, and a scoring method. If one begins instead with an isolated component, such as scoring, prompting, or audit logs, one risks misclassifying RAIDT as a checklist, a template, or a technical control. That would miss the framework's central claim that governance quality is established through reconstructable run-level evidence linked to a scored judgement of readiness.

This priority order is also necessary for theoretical coherence. The academic logic paper formalises RAIDT as a mechanism-based mid-range design theory in which governance artefacts and influence methods as governance interventions affect run-level outcomes under stated boundary conditions. Internal components therefore only make sense once the root object is clear: RAIDT governs configured uses, not models in the abstract, and it does so by treating run as the unit of governance. The five pillars, the run-level evidence pack, the score profile, and the anchors 1=missing / 3=partial / 5=audit-ready are not detachable features; they are coordinated elements of one method.

Treating RAIDT first as the project object also prevents organisational error. It stops teams from building a logging system without a scoring rationale, or a scorecard without evidence requirements, or a prompting intervention without traceable run records. The object must come first so the components can be assembled in the right governance relation.

Practical example

Take an HR workflow in which GenAI drafts shortlist justifications. If a team begins with the internal component 'LoRA adapter versioning', it may produce technically neat documentation yet still fail to govern the run properly. There may be no clear rule for what counts as sufficient evidence, no record of the prompt template, and no agreed scoring logic for whether the outcome was contestable.

If the same team begins with RAIDT as the project object, the sequence changes. The governed entity becomes the configured use; the run-level evidence pack is defined first; the score profile is then produced across the five pillars; and only then is PEFT or LoRA interpreted as one among several influence methods as governance interventions. That ordering makes the workflow reviewable months later if a candidate challenges the process.

Sources in RAIDT papers
Powered by Forestry.md