Zum Hauptinhalt springen

Project Profile

Some standards do not apply to every system in the same way. The EU AI Act asks whether you are a provider or a deployer, whether the system is high-risk, and whether it is in scope at all — and the answers decide which of its controls you actually have to satisfy.

The Project Profile is where you record those answers. Until it is set, nori will not start an analysis: the project header shows a single Setup Project Profile button in place of the run actions.

What a profile does

A profile is a set of applicability tags — short declarations about what this project is, such as high-risk provider or general-purpose AI model. Controls are scoped to those tags:

  • A control with no applicability tags is evaluated for everyone.
  • A control scoped to a tag you did declare is evaluated.
  • A control scoped to a tag you did not declare is reported as Not Applicable instead of being evaluated.

That last point is why the profile matters: leaving a category unticked doesn't just hide controls, it excludes them from the analysis and from your compliance score.

Out-of-profile controls are still visible. In the run picker they carry a grey Not in profile chip and are unchecked by default — you can always tick one back in for a particular run.

Setting the profile

Open the project and go to the Project Profile tab. Each row is a category you can tick, showing how many controls and wiki topics it pulls in; expand a row to see exactly which ones. Tick what applies and choose Save Profile.

If you would rather be walked through it, use Run guided triage.

Guided triage is available for the EU AI Act

The Project Profile tab works for any policy that scopes its controls by category. The guided triage is available where the policy ships a classification decision path — today that is the EU AI Act. For other policies, tick the categories yourself.

Guided triage

Guided triage opens a conversation panel. Describe the system — what it does, whether you build it or deploy it, and the domain it operates in — and the assistant works through the standard's decision path with you. You can pick a triage model for the conversation independently of the model your analysis runs on; a CLI model can also read your source code and scanned documents, which a Direct Cloud API model cannot.

Two shortcuts are worth knowing:

  • Derive from source code starts the assistant off by inspecting the repository instead of asking you to describe it. Available when the triage model is a local agent CLI.
  • Documents (optional) lets you attach supporting material — a system description, a DPIA — for the assistant to read.

When the assistant reaches a conclusion it presents a Proposed classification: the outcomes and roles it determined, its confidence, a step-by-step rationale citing the specific articles it applied, and the list of applicability tags that will activate. Read it, and either Keep chatting to correct or refine it, or Confirm classification to record it.

You are confirming a determination, not filling in a form. If the proposal is wrong, say so in the conversation rather than confirming and editing afterwards — a confirmed triage carries the reasoning with it, and a later manual change replaces that reasoning with a bare tag list.

Prohibited and out-of-scope outcomes

If the triage concludes the system is a prohibited practice, the proposal says so prominently: a compliance evaluation does not resolve that, and the finding is not something nori can score away. An out-of-scope determination is equally legitimate to confirm — it resolves to no applicability tags, and recording that a determination was made is the point.

When a capability can't be recognised

If the assistant reports something about your system that the local decision path doesn't recognise, nori refuses to resolve the tags rather than guessing. The tag list reads could not be determined, Confirm classification is disabled, and you are asked to continue the conversation so the assistant can restate it.

This is deliberate. The alternative — silently dropping a capability nori didn't understand — would also silently drop whatever legal duty attached to it.

What gets recorded

Confirming writes a classification record into your project's configuration inside the .nori data directory. It holds the outcome, the roles determined, the reasoning with its article references, the version of the decision path used, and who confirmed it, on which machine, and when. The triage conversation itself is kept alongside it so the record can be traced back to the discussion that produced it.

A profile saved by ticking categories records a thinner version: that a person chose these tags, at this time. It deliberately does not invent outcomes or reasoning nobody stated. If you later change the tags by hand on a project that was classified by triage, the manual record replaces the triage one — a human override should be visible, not hidden behind rationale that no longer matches. Saving without changing anything leaves the existing record intact.

Confirming is local

Confirming a classification makes no network call. It works offline, on an expired key, and on an air-gapped machine. The conversation is not local — each turn consults the policy's decision path and sends your description to whichever model you selected — but the act of recording the decision is entirely on your workstation.

The record is written for audit and for the analysis engine to read; there is no screen in the app that displays it back to you. What you see reflected in the UI is the applicability tag list.

Changing the profile later

Re-open the Project Profile tab at any time. Changing project settings — the name, the model, the workspace paths — does not affect the profile.

If two windows have the same project open and the tags changed elsewhere, a save is refused rather than applied blindly; the card refreshes so you can review the current tags before saving again.