Pair Factory · where raw evidence becomes trusted intelligence.

DefendableOS does not treat every observation as truth. A marketplace listing, a rental signal, an operating receipt, a validator correction and a verified transaction each carry different evidentiary weight. Pair Factory converts those distinctions into structured learning pairs that help AIOV reason better and help DefendableOS issue stronger records.

The system does not learn from confidence. It learns from proof, correction and receipts.

What is a pair?

A pair is a structured learning example built from an Evidence Input, a Draft Claim, a Validator Challenge, a Corrected Output, and a Receipt / Source Class. Pair Factory does not manufacture truth · it records the difference between what was observed, what was claimed, what was challenged and what survived validation.

Compute example · one GPU, many evidence types (EDUCATIONAL · NOT A LIVE VALUATION)

• Marketplace listing shows an asking price · correct class: Active listing observation only.
• Vast.ai shows a visible hourly listing rate · correct class: Rental market signal only.
• Founder captures an actual paid rental receipt · correct class: First-party rental evidence.
• nvidia-smi capture verifies memory and operational state · correct class: First-party operating evidence.
• Verified paid sale receipt exists · correct class: Verified transaction evidence subject to comparability review.

Doctrine: Listed is not sold. Offered is not rented. Rented is not future yield. Operational is not valuable without context. Proof is what survives review.

Edge example · small hardware, real utility (EDUCATIONAL · CAPABILITY REQUIRES CAPTURED EVIDENCE)

An affordable Jetson Orin Nano-class device may carry real utility through low power, local privacy, sensor integration, offline execution or persistent deployment. Its utility must be established by evidence appropriate to its role · a small device is not lesser evidence, it is a different compute role requiring the right proof.

The Pair Factory pipeline

1. Capture · sources enter the system (asset specifications · receipts · operating captures · rental history · benchmarks · observations · partner records · validator notes).
2. Classify · evidence receives a truth class (first-party operating evidence · rental receipt · active listing observation · partner transaction · verified sold comp · unsupported assertion · private-only).
3. Challenge · is the claim supported · is evidence stale · is a listing being misrepresented as a sale · is private information about to be exposed · is a capability claim untested · does the comp match the asset and deployment context.
4. Correct · unsupported or overbroad conclusions are revised with proper scope and disclosures.
5. Pair · evidence + failed claim + validator finding + corrected output become a structured learning pair.
6. Improve · approved pairs improve AIOV analysis quality · source grading · comp selection · disclosure discipline · validator consistency · future asset records.
7. Deed · only approved, public-safe conclusions may move toward a Defendable Deed.

Doctrine: The failure is not discarded. The correction becomes the training asset.

Eight pair types

• Identity Pair · correct asset identification from incomplete or conflicting evidence.
• Comp Pair · difference between relevant comps, weak references and non-comparable observations.
• Rental Pair · difference between listed rental rates, completed rentals and receipt-backed yield analysis.
• Utility Pair · what workload an asset can actually support when tested.
• Disclosure Pair · what can be safely shown publicly versus kept private.
• Contradiction Pair · how conflicting inputs are surfaced and resolved.
• Lifecycle Pair · difference between draft, review, issued, transferred and retired records.
• Failure Pair · what the model or analyst got wrong and how it was corrected.

Where Pair Factory sits in DefendableOS

ProductRadar discovers observable signal and candidate assets. Pair Factory converts evidence, conflicts and corrections into trusted learning pairs. AIOV uses classified evidence and learned discipline to form draft opinions. The Validator Workflow challenges claims, checks evidence and controls disclosure. DefendableOS governs records, lifecycle, provenance and public/private boundaries. The Defendable Deed ships the approved public-safe trust record.

Privacy discipline

Pair Factory never exposes raw serial numbers, private invoices, customer documents, partner-confidential transaction records, rental payout receipts unless approved for disclosure, personal identifying information, unreleased asset records, private validator commentary, or proprietary training corpora. The public page may show educational examples, evidence classes, redacted sample workflows, public-safe issued records, doctrine language, generic correction examples, and hashes or lifecycle states where already public-safe. Private evidence can teach the system under controlled rights and disclosure rules without becoming public evidence.

Defendable Compute Bench · test the asset before you trust the opinion

A hardware record should not begin with a price guess. Defendable Compute Bench captures the asset configuration, runs an appropriate health and utility test, hashes the receipt bundle and records what the system actually demonstrated at inspection time. AIOV may then form an opinion from measured utility and source-classified market evidence. DefendableOS validates the record before any public-safe deed may be issued.

Bench pipeline: CAPTURE → DIAGNOSE → BENCHMARK → HASH → CLASSIFY → ANALYZE → VALIDATE → DEED. Output is never a single composite score · the bench produces four orthogonal grades (Identity Confidence · Health · Utility · Evidence) that the operator and validator read together.

The bench proves what the machine did during the test, what workload class fits this hardware today, that identity was captured and hashed, and that health was within a specific envelope at capture. The bench does NOT prove what buyers will pay, what the card will earn rented over a year, that the hardware will never be substituted, or that performance repeats in another rig.

Phase A (identity + system + runtime + idle-health capture) is implemented as defendable-compute inspect in the platform repo's edge-agent. Phase B adds diagnostic adapters (DCGM · smartctl · fio read-only) · Phase C adds workload tests per E0-E7 profile. The CLI is read-only by default · refuses to run on GPUs occupied by active compute processes · never installs anything · never changes GPU clocks or power limits.

The Evidence Vault · where proof lives

The model can form an opinion. The vault must preserve the proof. DefendableOS routes every artifact into one of four logically separated vault classes: Private Evidence Vault (client uploads · serials · invoices · raw captures · never public by default), Observation Vault (timestamped marketplace/rental/reference observations · source-classified · internal), Derived Intelligence Vault (normalized comps · AIOV drafts · Pair Factory pairs · validator corrections · internal unless approved), and Public-Safe Export Vault (issued deed manifests · approved summaries · public only after validation).

Evidence flows · CAPTURE → STORE → HASH → CLASSIFY → CHALLENGE → APPROVE → PUBLISH. A stored file is not automatically a proven claim. Evidence must still be classified, challenged and approved before it supports a public record.

Doctrine: The vault stores the evidence. The hash protects the trail. The validator judges the claim. The Deed publishes only what survives review.

Implementation status: 4-bucket privacy model implemented at the service boundary with a public_export_or_refuse() guard that has no exception path · SHA-256 manifest pipeline implemented end-to-end · object-storage live-mirror gated by per-environment kill switch · MinIO local + Tigris/S3 production support · technical specifics in OBJECT_STORAGE_POLICY.md in the platform repo.

Closing doctrine

Signal begins the inquiry. Evidence grounds the claim. Challenge exposes the weakness. Correction creates the pair. Validation earns the trust. The Deed ships only what survives proof.