Skip to content

Evidence Assertions

An Evidence Assertion (ASN-YYYY-NNNN) is the smallest meaningful unit of evidence in OrviQ: one observation, about one subject, at one moment, from one source.

Everything in the assurance layer evaluates assertions. Nothing evaluates files.


What an assertion states

ElementQuestion it answers
SubjectAbout what? An asset, an account, a service, or the organisation
Observed stateWhat was observed?
Observation timestampWhen?
Source originFrom where?
Freshness windowHow long does this observation remain current?
StatusIs this assertion still the live one?
LinkageWhich control, requirement or obligation it speaks to

Observed states

StateMeaningEffect on evaluation
passThe expected condition was metCounts toward coverage and passing
failIt was notCounts toward coverage and failing
partialPartially metCounted, but does not satisfy an all-pass rule
infoInformationalCarries no pass or fail judgement
inconclusiveCould not be determinedNot treated as a pass

inconclusive is not fail

An account that could not be read because it was disabled mid-collection is not a failing account. Recording it as inconclusive keeps the distinction between "we looked and it was wrong" and "we could not tell" — which is the same distinction as not_satisfied versus not_assessed, one layer down.


Assertion statuses

StatusMeaning
activeThe current observation for this subject; counted
supersededReplaced by a newer observation of the same subject
disputedFlagged as contested pending resolution
invalidatedDetermined to be unreliable and excluded
archivedRetained but out of evaluation scope

Supersession

When a collector observes the same subject again, the new assertion becomes active and the previous one becomes superseded.

Superseded assertions are not deleted. They remain available for historical reconstruction — which is how a determination as of March can use March's observation rather than today's.

Disputes and invalidation

An assertion can be disputed where its accuracy is contested, and invalidated where it is determined to be wrong.

This matters in a specific situation: a collector misconfiguration produces a run of false passes. Invalidating those assertions removes them from evaluation without deleting the record of what happened — and, importantly, without pretending the period they covered was evidenced.

Invalidating assertions lowers coverage, correctly

Invalidating a batch of false passes does not turn them into failures. It removes them, so the subjects they covered have no fresh assertion and coverage falls. The resulting picture — "we do not currently have reliable evidence for these subjects" — is the truthful one.


Where assertions come from

OriginTypical source
collector_runAn automated collector execution
manual_evidenceAn artefact in the Evidence Register
attestationA person attesting to a fact
governed_testA governed control test result
push_apiAn external system submitting through the authenticated push API
webhook_pushA webhook gateway
trusted_integrationA trusted integration

All produce the same record type. An attestation from the Company Secretary and a nightly cloud configuration read are both assertions, evaluated by the same rules.


Freshness

Each assertion carries a freshness window appropriate to the evidence it represents.

EvidenceSensible window
Daily configuration read48 hours
Quarterly access review100 days
Annual board approval12 months
Annual penetration test12 months

Beyond the window the assertion is stale: present, still historically valid, but no longer speaking to the current state.

Setting the window too short produces constant false staleness. Setting it too long lets genuinely aged evidence look current. Match it to the real cadence of the underlying control.


Recording assertions manually

  1. Open the evidence artefact or the control.
  2. Select Record assertion.
  3. Identify the subject — this must resolve to a scope member for coverage to count it.
  4. Set the observed state.
  5. Set the observation timestamp to when the evidence was produced, not when you are recording it.
  6. Set the freshness window.
  7. Link it to the control or requirement.

Requires assertion.create. This is part of core compliance and does not need the Continuous Assurance entitlement.


Assertions and requirements directly

Assertions can attach directly to a requirement rather than through a control. This is how non-control obligations are evidenced — a filing, a board approval, a published notice.

For these, requirement satisfaction is derived from the assertions themselves: any failure means not_satisfied; all passing and current means satisfied; all passing but stale means partially_satisfied.


Permissions

ActionPermissionEntitlement
View assertionsassertion.readcompliance_core
Record manual or attestation assertionsassertion.createcompliance_core
Submit assertions via push APIevidence_push.submitcontinuous_assurance

Example

One control, three assertion sources.

Control CTL-2026-0044 — Privileged Access Management, scope SCP-2026-0012 with 214 privileged accounts.

SourceAssertionsSubjectWindow
Daily collector on the identity platform214 per dayEach account48 hours
Quarterly access review upload63 per quarterEach in-scope system100 days
Annual attestation by the Head of IT Security1 per yearThe organisation12 months

The daily collector gives current operational state. The quarterly review gives evidence of the governance process. The annual attestation gives evidence of executive accountability.

Three indicators evaluate them separately, and control effectiveness combines the three. If the daily collector breaks, operational assertions go stale and effectiveness degrades — while the quarterly and annual evidence remains valid for what it covers. That is a more useful picture than a single blended score.


Troubleshooting

"Assertions exist but coverage is zero." The subjects do not resolve to scope members. Compare assertion subjects with scope membership.

"An assertion I expected is not counted." Check its status — it may be superseded, disputed, invalidated or archived. Only active assertions count.

"Everything went stale at once." A collector stopped, or a freshness window was shortened. Check collector run history and the window setting.

"I recorded an assertion with today's date but it shows as stale." The observation timestamp was set to the evidence date rather than today, which is correct behaviour if the underlying evidence is old.


OrviQ Enterprise Governance, Risk & Compliance Platform