A copied file is not yet a verified replica

A write call returning successfully is a useful event. It is not the same observation as independently reading the destination and checking that it contains the intended evidence.

The public Replication component separates those responsibilities. It converges already-finalized immutable evidence onto an already-bound target. It does not capture or process the input, choose a destination on the operator’s behalf, provision storage, create credentials or change IAM.

Bind the destination before trusting it

The worker validates the configured target ID against canonical database state and checks the target’s bound identity marker. The core depends on a provider-neutral ReplicationTarget contract rather than provider SDK types.

That boundary matters when a path exists but points to the wrong target. A reachable directory or bucket name alone is not sufficient authority to write there. An identity mismatch fails closed.

The source is eligible finalized evidence plus immutable bytes referenced by SQLite. CLI summaries and demo receipts describe state; they do not replace the database and bytes that establish it.

Source: standalone architecture, worker and target binding.

Three destination states, only two successful paths

This is stronger than “upload again if uncertain.” It retains a contradiction rather than erasing it.

Before publication, the worker checks the local source size/hash against the expected object. The adapter owns immutable publication and destination readback. Only after that path returns successfully does the core mark the replica verified in canonical state.

The mounted-filesystem adapter and optional GCS adapter implement that contract differently. Their existence does not mean a real NFS service or GCS bucket was exercised by every local test.

Source: run and verify, NFS target, optional GCS target.

Reconciliation and independent verification answer different questions

reconcile visits already-known pending objects. It validates target identity, handles guarded transient cleanup, and can adopt exact destination objects after inspection. It does not invent a second checkpoint authority.

run reconciles first, discovers eligible source objects, registers pending work, records attempts and performs immutable publication or adoption. A recorded failure remains a failure finding rather than being smoothed into success.

verify opens the database read-only and checks objects already recorded as verified against the target. It does not create a new replica. This separates “perform replication” from “check the result afterward.” The target is still accessed for the byte check; read-only database access is not proof that no I/O occurred.

Source: reconciliation, read-only verification.

What the local proof establishes—and what it does not

The deterministic demo covers exact adoption, exclusive creation, readback, idempotent reruns and collision refusal. It uses synthetic data, SQLite and a local target directory, substituting the NFS mount-type probe so a reviewer does not need a real NFS service. That substitution must remain visible in any reproduction claim.

For this draft, 32 selected local integration, target-contract and configuration tests passed. One GCS-marked case was deliberately deselected because the optional provider SDK is not installed. An initial broader attempt exposed that missing optional dependency; no cloud access or credential operation was performed. This is not an all-provider or live-storage validation.

Source: local proof scope, integration tests.

Worked synthetic trace: adoption, verification and refusal

The standalone demo constructs two synthetic source objects and a bound local destination, intentionally pre-populating one destination object with exact expected bytes. The following values come from the demonstration’s assertions and integration test, not a newly executed live storage run.

The assertions are in tests/test_integration.py and demo/run_demo.py. The demo deliberately bypasses the NFS mount-type probe for a local fixture. That is not evidence of a real NFS service, GCS bucket, provider credentials, network durability or multi-writer behavior.

A reviewer should inspect both the receipt and the underlying SQLite replica rows, target identity marker and destination bytes. The synthetic receipt is a helpful index to observations, not the independent authority for its own claims.

Receipts are useful, but not a substitute for authority

A result can report published, adopted and verified counts. To assess a particular claim, follow it back to the target binding, source object identity, canonical replica state and independent byte check.

The separate Showcase integration additionally checks a Processor-to-Replication handoff and reports replay with no new writes. It uses bundled worker versions and may cache the result served by /api/demo; it is not automatically the same experiment as running the standalone component at this chapter’s pin.

The Visual Gateway, by contrast, explains three supplied synthetic records. Its Explain button does not copy data or independently verify a live replica. Keeping those demonstrations separate makes both more credible.