S8.12 - Paper-code_separation

S8.12 ? Paper-code separation

flowchart LR
    A[Overloaded manuscripts and weak technical transparency] --> B[RAIDT - run-level evidence framework]
    B --> C[[Paper-code separation]]
    C --> D[Readable governance argument in the paper]
    C --> E[Linked technical artefacts in repository and appendices]
    D --> F[Evidence pack]
    E --> F
    E --> G[RAIDT score profile]
    F --> H[Reviewer reconstruction]
    G --> I[Governance readiness]
    J[Healthcare, public services, enterprise productivity, cybersecurity] --> C

? Star S8 - Implementation and Operations

Star context: Shows how RAIDT can be adopted manually, semi-automatically or through orchestration, and how it becomes part of real governance routines. Within this star, paper-code separation explains how RAIDT is documented rigorously without collapsing academic argument, operational evidence, and executable implementation into one unreadable artefact.

Academic picture

Definition / background

Paper-code separation is the practice of keeping the main manuscript focused on the academic argument while locating executable code, repository structure, functions, configuration details, and related artefacts in appendices, linked repositories, or structured supplementary materials. It does not imply a separation between reasoning and evidence. Rather, it creates a disciplined relationship between them: the paper explains what was done, why it matters, and how it should be interpreted, while the technical artefacts provide the operational detail required for reconstruction and scrutiny.

Conceptually, this sits at the intersection of reproducible research, software documentation, and governance transparency. In a general research context, authors often separate prose from implementation to preserve readability. In a RAIDT context, the reason is stronger. RAIDT treats the run as the unit of governance, so each governance claim should be capable of being tied back to run-level evidence. That evidence may include prompts, model settings, wrappers, scripts, evaluation routines, approval checkpoints, or log schemas. If all of that is pushed into the paper body, the conceptual argument becomes hard to follow; if it is omitted entirely, governance claims become difficult to verify.

Paper-code separation therefore belongs inside RAIDT because RAIDT depends on both interpretive clarity and evidential traceability. The paper can explain the governance model, the meaning of the five pillars, and the logic of evidence collection. The linked technical artefacts can then show how particular runs were configured, logged, checked, and scored. This supports the run-level evidence pack and makes the score profile more defensible because the scoring logic is not left as an unsupported textual claim.

This item differs from generic supplementary material practices. A normal appendix may simply provide extra detail. Paper-code separation in RAIDT is more structured: it establishes a boundary between the narrative account and the executable substrate while preserving explicit links between the two. In that sense, it is an implementation and operations concept, not just an editorial convention.

Why this concept matters

Paper-code separation solves a practical governance communication problem. Organisations and researchers working with generative AI need to explain how a system was used, what controls were in place, what evidence was collected, and how conclusions were reached. If the academic paper attempts to carry every code fragment, schema, and operational detail, it becomes inaccessible to readers and weak as an argument. If the paper contains only high-level claims, it becomes difficult to audit.

The concept therefore avoids two common failures at once: evidence hidden inside unreadable prose, and prose unsupported by inspectable artefacts. In organisational settings, that distinction matters because governance is rarely judged only by principles. It is judged by whether a reviewer, supervisor, auditor, or regulator can reconstruct what happened in a specific run and assess whether the controls were proportionate.

In RAIDT, this matters because the framework is explicitly trying to move GenAI governance from principles and assertions toward evidence, reviewability, contestability, audit readiness, and continuous improvement. Paper-code separation helps that move by making sure the governance narrative remains intelligible while the underlying technical evidence remains organised, linkable, and reviewable.

Key idea: Paper-code separation matters because RAIDT needs governance claims to be readable in the paper and reconstructable in the evidence base.

What this item enables

A clear boundary between conceptual argument and executable implementation.
Cleaner academic writing without loss of technical transparency.
Explicit linking from manuscript claims to repositories, scripts, appendices, and artefacts.
Better reviewer reconstruction of how a RAIDT-governed run was configured and assessed.
More credible evidence packs because code references can be versioned, indexed, and audited.
More defensible score profiles because scoring logic can be tied to inspectable implementation details.
Easier organisational reuse, because methods and artefacts can be maintained operationally without rewriting the paper.

Practical example / likely audience question

Audience question

Why not just place the key code directly in the paper so that everything is visible in one place?

Answer

The concern behind that question is understandable: if governance depends on evidence, then placing code in the paper may look more transparent. The problem is that visibility is not the same as usability. Long code blocks rarely provide a good basis for conceptual understanding, and they often obscure the very governance logic a paper is trying to explain.

In RAIDT, the direct answer is that separation improves both readability and scrutiny when the links are explicit. A paper can explain the governance model, the role of the run, the evidence criteria, and the meaning of the five-pillar profile. The appendix or repository can then expose the scripts, prompts, configuration files, validators, and artefact schemas used to generate or assess that evidence. For example, a paper may state that Dependability scoring included repeatability checks across controlled runs. The repository can then contain the actual evaluation script, the parameter file, and the run log identifiers.

This is better than a generic AI governance approach because RAIDT is not satisfied with a broad statement that code exists somewhere. It requires operational linkage between narrative claims and run-level evidence. Separation is therefore not concealment; it is disciplined presentation with traceable technical support.

Practical example in RAIDT terms

Consider a healthcare trust using a GenAI assistant to draft discharge-summary templates for clinicians. A RAIDT-governed run is defined for one specific task, with a named model, a prompt template, a safety wrapper, date-stamped configuration settings, and human review checkpoints. The governance challenge is to publish or present the method in a way that clinicians, supervisors, and reviewers can understand without reading a full software repository inside the paper.

With paper-code separation, the manuscript explains the use case, the governance rationale, the risk controls, and the resulting RAIDT score profile. The linked evidence pack points to the repository commit, the prompt file, the redaction check, the validation script for output format, and the reviewer form used for post-run assessment. The run-level issue is whether a reviewer can reconstruct how one discharge-summary run was produced and evaluated. The needed evidence includes run identifiers, repository version, function names, configuration values, approval records, and output review results.

The most affected RAIDT pillars are Auditability and Traceability, with secondary effects on Responsibility and Dependability. Governance readiness improves because a supervisor or auditor can read the paper for the argument and inspect the evidence pack for the implementation detail, rather than being forced to infer both from a single overloaded document.

Detailed link to RAIDT

Paper-code separation links to RAIDT in four ways.

First, it supports RAIDT's core idea that governance should be grounded in evidence rather than broad assurance statements.
Second, it helps preserve the run as the unit of analysis by linking each textual claim to run-level artefacts rather than to abstract descriptions of a system.
Third, it strengthens the evidence pack and score profile because implementation details can be referenced, versioned, and reviewed without overwhelming the main argument.
Fourth, it improves reviewability, contestability, audit readiness, and organisational learning because different audiences can inspect the layer of detail appropriate to their task.

Paper-code separation ? Run-level evidence ? Evidence pack ? RAIDT score profile ? Governance readiness

This chain matters because RAIDT does not treat documentation as a cosmetic add-on. Documentation structure shapes whether governance evidence can actually be inspected, challenged, and improved.

Link to the five RAIDT pillars

Responsibility

Paper-code separation supports Responsibility by making it clearer who designed the governance logic, who implemented the controls, and where the operational artefacts sit. It reduces the chance that accountability is obscured inside a mixture of prose and code fragments.