Skip to content

MCV-1 / SSX360 methodology

Prove who or what authorized the machine.

MCV-1 is SSX360's scoped method for tracing a machine action from stated intent through delegated authority to the resulting record. We report what the evidence supports, what is missing, and what cannot be concluded.

Master design for the MCV-1 verification mark
Master mark specimen. An issued lockup also carries its registry ID, URL, and expiry.

What the mark means

The MCV-1 mark is a claim you can check.

The mark is not issued as a standalone image. Each issued lockup includes a registry ID and URL that resolve to the scope, method version, assessor, dates, status, and signed record.

The mark
Issued only after all six MCV-1 criteria are Supported for the scope named in the report. The master artwork alone carries no verification status.
Criteria version
Names the exact published method used for the review so a later criteria revision cannot silently change the meaning of an earlier mark.
Registry ID
Resolves to the public entry containing the holder, subject, scope, assessor, dates, status, digests, and signed record.
Expiry date
Verification lasts no more than twelve months. Renewal requires a new review and a newly signed registry record.
Open the MCV-1 registry

The authorization sequence

MCV-1 does not treat a signature as authorization by itself. It checks the full sequence and records the first unsupported link.

  1. 01

    Human intent

    Decision owner, requested outcome, and source record

  2. 02

    Delegated mandate

    Permitted systems, constraints, validity, and revocation

  3. 03

    Machine action

    Observed action, machine identity, target, and result

  4. 04

    Auditable proof

    Source register, checksums, signature results, and gaps

Why authorization evidence needs its own review

The MCV-1 criteria

Each criterion names the test and the report output. A missing record is a finding, not a reason to infer the intended result.

MCV-1.1

Intent and accountable owner

Identify the person or governed system that initiated the request, the intended outcome, and the record that expresses that intent.

Report output

Owner and source record named, or an evidence gap recorded

MCV-1.2

Delegated authority and scope

Identify what authority was delegated, which systems and actions it covered, its constraints, validity period, and revocation path.

Report output

Authority boundary reconstructed and exceptions listed

MCV-1.3

Identity and action binding

Bind the observed machine identity, action, target, and result to the authority record that preceded them. Verify signatures where signed records exist.

Report output

Action linkage supported, contradicted, or not evidenced

MCV-1.4

Timing, freshness, and revocation

Check that the authority was valid when the action occurred and that expiry, replay protection, and revocation evidence are available where the system claims them.

Report output

Time and validity findings with source timestamps

MCV-1.5

Log completeness and gap detection

Reconstruct the sequence across human, service, and machine identities, then identify missing, ambiguous, overwritten, or shared records.

Report output

Sequence map and ranked evidence gaps

MCV-1.6

Reviewable evidence export

Export the method version, source register, files, checksums, signature results, findings, and stated limits so another reviewer can repeat the checks.

Report output

Signed report and offline-reviewable evidence package

Supported
The named evidence supports the criterion.
Gap
A required link or control is missing or contradictory.
Not evidenced
The available records cannot support a conclusion.
Out of scope
The agreed system boundary excludes the criterion.

Deliverables and pricing

  • Signed MCV-1 Machine Authorization Report
  • Four-stage authorization sequence for each action sampled
  • Criterion-by-criterion result using Supported, Gap, Not evidenced, or Out of scope
  • Source register with file hashes and signature-verification results
  • Prioritized remediation list for identity, authority, logging, and evidence gaps
  • Offline-reviewable evidence package

Framework evidence mapping

These mappings identify control evidence that may support a separate review. They are evidence mapping, not a certification claim. Certification under any scheme named here comes from that scheme's own accredited assessors.

PCI DSS
Identity, least-privilege, access-review, and audit-log evidence where the reviewed system is in the cardholder data environment.
SOC 2
Evidence relevant to selected security, availability, processing-integrity, confidentiality, or privacy criteria.
ISAE 3402
Service-organization control evidence where the service is relevant to user entities' financial reporting.
NIST AI RMF
Govern, Map, Measure, and Manage evidence for identity, oversight, traceability, and response.
EU AI Act
Technical-documentation, logging, risk-management, and human-oversight evidence where applicable.
DORA
ICT risk, change, logging, incident, and third-party oversight evidence for applicable financial entities.
CRI Profile
Financial-services cybersecurity control evidence, subject to the selected profile scope and version.

What MCV-1 does not prove

  • A valid signature proves control of a key and the integrity of signed bytes. It does not, by itself, prove that an action was authorized or correct.
  • MCV-1 does not assess model quality, safety, legal sufficiency, business judgment, or the fitness of an automated decision.
  • Missing source records remain missing. The report identifies the gap and does not reconstruct evidence that the system did not retain.
  • A pass applies only to the systems, period, evidence, and criteria named in the report. It is not a portfolio-wide claim.

Return to the full service list or begin with the scoped MCV-1 inquiry.

Request an MCV-1 scope