Systems and intake

• A name, a purpose, a deployment contextFree text you write. It appears on documents.
• Your intake answersThe structured facts the rules are tested against: does the system interact directly with people, does it generate synthetic media, and so on.
• Your roleProvider if you built or put the system on the market, deployer if you use it in your own operations, or both. Marking a system both gives it provider duties and deployer duties — the union, never the smaller set.
• A risk classificationSelf-declared. Clause50 records the classification you give it; it does not work out for you whether your system falls into a high-risk category.

Because the record drives everything, an inaccurate one produces a confident, wrong document. That is the failure mode worth guarding against — not a low score.

The intake is not a hand-written questionnaire. Clause50 reads the condition attached to every rule in the loaded rule pack — the human-authored, legally-reviewed file that encodes the obligations — collects every fact those conditions test, removes duplicates, and renders one question per fact. Sections are titled after the rule that first needed each fact, so you can see which obligation is asking.

Two consequences, because they are the ones people notice:

• The question set changes when the rule pack changes — not as you answerClause50 asks the whole de-duplicated set on one form; it does not reveal or hide questions as you go. What your answers change is which obligations then apply, and therefore which requirements are scored on your coverage page. If a later rule pack adds a rule that tests a new fact, a new question appears for everyone.
• Your answers decide your obligationsA rule applies when its condition is true of your answers and its role matches yours. Change an answer and the applicable set changes with it — which is why editing the intake and recomputing can add or remove whole obligations from your coverage page.

A record version is a point in time at which the description of the system was fixed. Completing the intake for the first time opens version 1.0.0.

Versions exist because some proof is only meaningful for the version it was recorded against. A requirement whose cadence is per version — in plain terms, “you must confirm this for each release” — is only met by a statement tied to the version that is current now. When a new version opens, a statement tied to the old one is not deleted and does not disappear. It changes status to stale: it proved something once, and no longer proves it for the system as currently described.

Evidence that is not per-version — an uploaded document, a usage record collected by a connector, a one-off statement — is unaffected by a version change and keeps its status.

• Nothing is ever removedThe evidence log can be added to but never edited or deleted. Changing the system record cannot delete, rewrite, or invalidate anything you recorded — it can only change how a requirement reads that evidence today. See Evidence.
• Stale is a prompt to refresh, not a lossA stale requirement had proof and needs fresh proof. It counts as a gap in your score, and it raises an Evidence out of date alert rather than a Coverage gap — precisely because the work differs: refresh something you had, rather than produce something you never had.
• Your score follows the change on its ownSaving the intake recalculates immediately and shows you the new number. Opening a new version is picked up by the hourly pass, or straight away if you press Recompute. See when the score updates.

Version 1.0.0 opens when you first complete the intake. After that, Clause50 decides whether an edit deserves a new version by looking at what you changed, and asks you before doing it rather than deciding silently.

Edit an answer that changes the system definition and you are stopped with a confirmation before anything is saved. It tells you, in advance, exactly what the change costs: how many per-version statements will stop counting, which requirements they were holding up, and that your score will drop until you re-confirm them. You then choose:

• Create the new versionThe right answer when the system genuinely changed. The named statements go stale — kept, never deleted, and needing re-confirmation against the new version.
• “That was a typo”Saves the corrected answer on the existing version without opening a new one. For fixing a mis-click or a wrong entry, where nothing about the system actually moved.
• CancelDiscard the change entirely.

The distinction is the same one that runs through the rest of Clause50: correcting a record and recording that the world changed are different claims, and the product asks which one you mean rather than guessing. Opening a version also raises a System changed alert, so anyone watching the inbox sees that the description behind the score has moved. See Alerts.