Five core steps, one data model: how a project in CIVAC runs from scope to report, and where no model is involved

Key takeaways

• Seven case types run on the same model: data protection impact assessment, transfer impact assessment, supplier audit, TOM inspection, external DPIA, audit and incident response. The five core steps are the same for all of them; what differs is the template the report is generated from.
• Each core step has three states, open, in progress, done, and the case itself has four: new, in progress, report drafted, completed. A project's progress is the number of completed core steps, not an estimate.
• When a project is created, a language model generates three to five starter risks and three to five starter questions from the scope and the file names of the documents. The content of the files is not read at that point; that happens only once the documents are uploaded and processed.
• The third step, answering questions and editing risks, is the only one with no model involved. It is also the step that makes the report project-specific: the answers and the risk list go verbatim into the report template.
• The report is a draft with a counter. Every generation increments the iteration, and a checksum comparison of the inputs marks the report as stale as soon as an answer or a risk has changed since the last generation.
• CIVAC is not a law firm. The report is organisational support with source references; whether a processing operation is lawful, whether a risk is acceptable and whether the report is signed is decided by the appointed person or the company.

What a project is, technically

In the interface it is called a project; in the data model it is a case. A case has exactly one type from a fixed list of seven: data protection impact assessment, transfer impact assessment, supplier audit, TOM inspection, external DPIA, audit and incident response. That list is defined in the model and is not freely extensible; anyone who needs an eighth type picks the closest one and adapts template and special tasks. The type mainly decides which template from the mastersheet library shapes the report, and for incident response it triggers a notification as soon as a new case of that type is created.

Regardless of type, every case has the same five core steps in the same order: scope, documents, questions, risks, report. Each step carries one of three states, open, in progress or done, with a timestamp of the last change. The case itself has four states: new, in progress, report drafted, completed. The progress shown in the project list is the number of completed core steps. It is counted, not estimated.

Step one: the scope

The scope consists of four text fields and a list. The fields are tool, department, purpose and description: which system or process is being looked at, in which department, for what purpose, and what, in the author's own words, the subject is. The list holds the people involved. A person involved is either a member of the organisation with a user ID or an external contact recorded by name and optionally an email address, such as a supplier or an external auditor.

Once the scope is filled in, the first thing a language model does in this flow happens when the project is created: from the four fields and, if documents are already listed, from their file names and tags, it generates three to five starter risks and three to five starter questions. The content of the files is not read at this point. If a template with predefined risks and questions exists for the chosen type, that template takes precedence over the model; if the model call fails, fixed starter lists are used so that the project does not begin empty. That order, template before model before fixed list, is set in the code.

Step two: the documents

Every document is filed under one of six tags: contract, TOM, vendor document, process, policy or note. Besides file name, time, uploading person and size it carries a processing state that passes through four values: pending, uploaded, extracting, ready; a fifth value, failed, records that extraction did not succeed. Ready means the file's text has been extracted and stored in the database, split into sections. Only in that state can a model use the content for suggestions; until then the file exists for the model only as a name and a tag.

From ready documents the officer can request two things, both optional: a gap detection that suggests additional questions, and a risk extraction that suggests risks from the text of the documents. Both are suggestions, entered as such into the lists of steps three and four, where they can be edited or deleted. The system instruction for both calls is derived from the project's template, that is from role, use case and sources, so that a supplier audit is not enriched with the questions of a data protection review.

Step three: the questions, with no model

A question carries its text, optionally an addressee, a priority from three levels, blocker, important or nice to have, and a reason why it is relevant to this project. Its state is open or answered. Answering is an entry made by a person, and it is the only core step with no model involved. It is also the step that makes the later report project-specific: answered questions are inserted verbatim, with their answer, into the context from which the report is generated. An unanswered blocking question is therefore not a formality but a gap in the report that the template does not close.

Step four: the risks

A risk carries a title, a likelihood and an impact, each on three levels, low, medium, high, optionally a mitigation and a category, and an origin field with exactly two values: manual or suggested by the model. That field stays on the risk even if it is later edited; a suggested risk does not become a manual one by being edited. Adding, changing and removing are pure entries, as in step three. All risks, with likelihood, impact and mitigation, go into the report's context.

Step five: the report, with a counter

The report is not generated from a fixed text but from an instruction assembled at runtime: the template from the mastersheet library, the case context, that is scope, answered questions and risks, and a format block that sets the report kind. The template is chosen in this order: an explicitly selected template, otherwise a template whose keywords match the case type, otherwise the role's first audit template, otherwise the default template for a data protection impact assessment. Free-text reports are streamed so the draft is readable as it forms; structured report kinds such as training, checklist, protocol or matrix are generated against a fixed schema.

Two mechanisms make the report traceable. First, every generation increments a counter and stores the list of sources used together with the template's identifier. Second, the system computes a checksum over the report's inputs. If an answer or a risk changes after the last generation, the checksum no longer matches, and the report is shown in the interface as stale, with a note that the inputs have changed. The old draft does not disappear; it is simply no longer the state of the inputs.

Special tasks beside the core steps

Whatever does not fit the five steps is run as a special task: with title, description, state, due date, its own documents, notes and an assigned person, who as in the scope can be a member or an external contact. A special task can carry a checklist; the case then reads its progress as the share of ticked items. Special tasks do not change the state of the core steps; they run alongside.

What this means for the officer

Knowing where in the flow a model works and where it does not lets an officer spend their time deliberately. The starter lists are an offer, not a review: they come from four text fields and file names. The suggestions from documents are only as good as the documents that reached the ready state. The report is only as specific as the answers in step three. And the stale marker is not a fault but the note that the report should be regenerated before it is exported.

What the model does at no point: decide. CIVAC is not a law firm and gives no legal advice in the individual case. Whether a processing operation is lawful, whether a risk is acceptable, whether a measure is sufficient and whether the report is signed in this form is decided by the appointed person or the company. The report is organisational support with source references. Where a question calls for a legal assessment of the individual case, it belongs to the legal department or a law firm.

Which project types exist in CIVAC?

Seven, fixed in the data model: data protection impact assessment, transfer impact assessment, supplier audit, TOM inspection, external DPIA, audit and incident response. All seven run on the same five core steps; the type mainly determines the report template.

At which points does a language model work?

At three: at creation, where starter risks and starter questions are generated from the scope and file names; optionally on ready documents, where additional questions and risks are suggested from the document text; and at the report, which is generated from template and case context. Answering the questions and editing the risks are pure entries.

Does the model read my files at creation?

No. At creation only file name and tag go into the call. A file's text is used only once it has been uploaded and processed, that is once it has reached the ready state, and even then only if a gap detection or risk extraction is requested.

Why does the report suddenly say it is stale?

Because an answer or a risk has changed since the last generation. The system compares a checksum of the inputs with the state at the last generation. The old draft is kept; the marker says it no longer matches the current inputs.

Is the generated report a legal assessment?

No. It is a draft from template, answers and risks, with the sources used listed. The assessment of whether something is lawful or acceptable, and the signature, lie with the appointed person or the company; CIVAC is not a law firm.