Evaluation Workflow

See how a real evaluation is reviewed before anything is published.

For technical evaluators who need to understand the review boundary, proof artifacts, and the exact evidence a first session should leave behind.

Talk to an Implementation Reviewer All Docs Paths

Evaluation Workflow

What proof should we expect from a first serious evaluation?

What proof should we expect from a first serious evaluation?

Audience

What proof should we expect from a first serious evaluation?

Technical evaluators, implementation leads, and security reviewers.

Operating Model

Source data is evidence, not automatic truth.

VeridataOps separates collection, normalization, review, commit, and destination publication. Jobs collect source evidence, data packs describe source semantics, operators review proposed changes, and only committed evidence updates the current estate cache or downstream destinations.

1. CollectSources or collectors return raw evidence and metadata.
2. MapData packs translate source fields into shared estate meaning.
3. ReviewOperators inspect creates, updates, conflicts, skips, relations, and source evidence.
4. CommitApproved evidence becomes current estate context and destination-ready output.

Evaluation Checklist

What a technical evaluation should include.

A customer-safe evaluation should produce visible artifacts that show how VeridataOps behaves with real source evidence, not just how it is described in a slide or diagram.

1. Source and scope choiceName the first source, what credentials or collector reach are required, and what part of the estate is intentionally in or out of scope.
2. Reviewed previewShow one saved review with creates, updates, conflicts, skips, and destination operations before any approval or publish step.
3. Proof artifact setRetain one Evidence Explorer record view, one review workflow sample, and one coverage discussion that documents source limits and remaining gaps.
4. Deployment next stepsLeave with a scoped list of collector, destination, security, retention, and rollout decisions required for the next implementation step.

Claims Register

Keep customer claims tied to tested product behavior.

Public, sales, onboarding, and audit-facing material should map every product claim to the capability that proves it, the evidence state required, and the caveats that qualify the statement. Customer-facing reports must be generated from committed estate evidence, release evidence, and scoped audit records rather than raw unreviewed payloads.

Claim area Status Evidence basis Limits and caveats
Evidence collection tested product capability Source packs and customer-network collectors collect raw source payloads, source timestamps, runtime logs, and mapping output for review. Coverage depends on the installed data packs, source credentials, network reachability, collector version, and customer-approved collection scope.
Review before current estate tested product capability Collected evidence enters a review workflow before selected rows are committed into tenant current estate records and cache indexes. Rejected or uncommitted evidence remains audit evidence and must not be presented as current estate truth.
Collector execution tested product capability Collectors run near private systems, call home outbound over HTTPS/WSS or polling, lease scoped jobs, and report version/log/status telemetry. Collectors can only reach systems available from their network zone and should be kept on a compatible published image.
Estate relationships and confidence evidence-backed semantic capability Data packs declare semantic objects, identity keys, relationship contracts, source metadata, and confidence/correlation guidance. Cross-source matches are confidence-based. IP-only, name-only, and proxy/relay observations need caveats when no stronger identity evidence exists.
Customer-facing reports release-gated claim Reports must be generated from committed estate evidence, release evidence, and scoped audit records, not from raw unreviewed source payloads. Each report must name the tenant/environment, product version, evidence date, known limits, and open work-item caveats.
Compliance support scope-dependent support statement Product controls can support ISO/IEC 27001, NIST CSF, PCI-sensitive, GxP, SOC 2, GDPR, DORA, and supply-chain readiness discussions through evidence and release records. Do not claim VeridataOps is ISO certified, GxP validated, Part 11 compliant, or PCI compliant unless a formal audited scope has achieved and approved that statement.

Next Step

Move from documentation to a scoped review.

Use the implementation reviewer path when you want to turn this page into a concrete source, deployment, or assurance discussion.

Talk to an Implementation Reviewer

Next Step

Pair this doc page with proof, fit, and one scoped follow-up.

A documentation page should answer its question and then route the visitor to the proof artifact, coverage page, or reviewer path that finishes the evaluation.

Proof

Inspect the corresponding artifact Use the proof library to connect the written explanation to a real product surface or public-safe sample. Browse Proof Library

Coverage

Validate support and caveats Use the coverage pages to confirm what is modeled already and where scope still matters. Open Coverage Hub

Contact

Route the next technical question Escalate to an implementation reviewer only after this page made the remaining blocker explicit. Talk to an Implementation Reviewer