Install · audit · correct · verify

VeriTrooper documentation

The starting point for deploying VeriTrooper, choosing the correct audit, tracing findings to governing evidence, targeting corrections, and preserving proof of what changed.

USER MANUAL · VERSION 1.7 · 11 SEPTEMBER 2026 · 27 PAGES
01

System requirements

Use a supported Windows workstation or customer-controlled virtual machine. Plan capacity around the selected local models and the size of the source collection.

  • 16 GB RAM minimum; 32 GB recommended
  • 8 GB VRAM recommended for bundled local analysis
  • Windows evaluation installation: at least 10 GB free, plus space for source indexes and run records
  • Customer-approved network access is required only for configured external model endpoints
02

Install and start

Use the approved VeriTrooper installer supplied for your evaluation or licensed deployment.

  • Run the installer with an account authorized to install software
  • Launch VeriTrooper and confirm the local service becomes available
  • Choose local analysis or configure a customer-approved model endpoint
  • Keep source material and output folders inside the approved customer boundary
  • Resolve startup or configuration warnings before beginning a production-relevant run
03

Choose the correct workflow

The suite contains three products. A shared Governance Records workflow is offered through each one; it is not a fourth product.

  • SitRep: audit source readiness, contradictions, unsupported claims, gaps, and file health
  • Scout: audit a model or assistant against approved source material before release
  • Watchtower: capture or probe deployed answers and evaluate quality over time
  • Governance Records workflow: within the selected product, assemble verified facts, signed packages, classification decisions, oversight measures, and named approvals
04

Run a Scout audit

Define the system under test, approved sources, model connection, and evaluation settings before generating or importing the question set.

  • Review the displayed scope and recorded configuration
  • Inspect each confirmed failure, referral, exclusion, malformed test, and connection error
  • Trace findings to the governing source and decide whether data, retrieval, prompts, policy, model behavior, or human process needs correction
  • Use baseline, pipeline, and delta as scoped summary measures—not substitutes for the findings
  • Rerun after correction and preserve the new result beside the original
  • Where supported, record named human signoff after review; a sealed package alone does not establish human review
05

Watchtower capture integration

Passive capture accepts newline-delimited JSON records. Every record requires a non-empty query and answer. Optional fields preserve conversation grouping and time order.

  • Required: query, answer
  • Optional: session_id, timestamp
  • HTTP endpoints: /capture and /v1/capture
  • Captured turns are evaluated during the next scheduled or manually initiated cycle—not inside the capture request
  • Protect capture and administrative routes with the configured token and customer network controls
06

Read and preserve the evidence package

Keep the completed package together. The human-readable reports explain the result; machine-readable records, the manifest, and checksums preserve detail and integrity.

  • Begin with the Executive Summary and consolidated Audit Report
  • Use the Results Report and Q&A listing to inspect individual verdicts
  • Use the System Card and Annex IV record for governance and technical-documentation workflows
  • Retain the original directory structure when moving or archiving a complete package
  • Share protected machine-readable artifacts only inside the appropriate diligence boundary
07

Verification and signoff

Verification confirms that the sealed files still match the recorded package. It does not broaden the scope of the test or certify legal conformity.

  • Resolve package-consistency warnings before signoff
  • Confirm the recorded system, sources, model, settings, dates, and exclusions
  • Record the responsible reviewer and disposition
  • Re-run the assessment when the model, prompt, retrieval configuration, sources, or deployment conditions materially change
08

Troubleshooting

Treat operational warnings as issues to investigate, not messages to bypass.

  • Missing token: confirm the configured provider or capture credential without exposing it in logs
  • Malformed JSONL: validate one complete JSON object per line and required query and answer values
  • No Watchtower traffic: confirm route, token, network reachability, and capture cadence
  • Corpus access failure: confirm permissions and that the selected path remains available
  • Package inconsistency: restore the original files or generate a new sealed package
  • Signoff failure: resolve incomplete fields, changed artifacts, or reviewer-permission problems
Need deployment help?

Use a 10-business-day assessment for your first controlled run.

Discuss an assessment