Verify a software escrow deposit by reconstructing an agreed build and core task from the deposited materials in a clean, bounded environment. Source readability is useful evidence but does not demonstrate that the receiving team can operate the product.
Define the reconstruction scope before testing
Name the product release, deployment target and core task the verification should reproduce. Inventory source, lockfiles, build instructions, runtime versions, schemas, migration scripts, configuration descriptions and non-code assets. Include the external services the software cannot reproduce from source alone. The legal agreement determines deposit and release obligations; this article describes a proposed technical exercise rather than interpreting those terms. A verification plan should also state what is excluded, such as access to a third-party production service or a proprietary dataset that cannot be deposited.
Escode’s current independent-build description distinguishes a new verifier-managed environment from a build observed inside the software owner’s setup. That provider-specific distinction is useful when scoping independence; it does not establish a legal requirement or guarantee recovery for a different deposit.
Escode: independent build verification scope
Separate source access from build success
A repository that opens in an editor may still depend on a private registry, unavailable compiler or undocumented environment variable. Record each reconstruction stage independently: unpack, dependency resolution, compilation, deployment and task execution. A lockfile helps identify versions but does not guarantee those artifacts remain obtainable. Keep hashes and a manifest for the deposited release so the verifier can identify what was actually tested. Avoid replacing missing dependencies with arbitrary newer versions and calling the original deposit verified. Such substitutions need a separate record and a clear statement of their consequences.
| Stage | Synthetic observation | Status |
|---|---|---|
| Source and lockfile | Present in fictional deposit | Inventory only |
| Dependency resolution | Assumed successful in scenario | Illustrative |
| Application startup | Endpoint contract missing | Blocked |
| Core record task | Startup prerequisite absent | Not run |
Walk the fictional missing-configuration case
A synthetic deposit contains source and a lockfile, but no environment inventory. Dependency resolution succeeds in the proposed trace, while application startup asks for an unknown service endpoint and fails. Report the startup stage as blocked and the core task as not run. Do not mark the whole verification passed because compilation produced a bundle. The missing material is a configuration contract, not a request to deposit live production secrets in a document. A safe deposit can describe required variables, secure provisioning steps and representative test values without exposing credentials.
Use isolated services and a bounded task
Create a clean verification environment with synthetic records and mocked or dedicated test integrations. Attempt one agreed task such as creating and retrieving a fictional record, including the data schema and permissions needed. Retain command versions, errors and resulting artifacts. Avoid sending messages, charging accounts or modifying production systems during reconstruction. An exercise using an existing developer laptop can conceal cached dependencies or private access. Have the intended receiver follow the instructions and identify every point where undocumented assistance from the original team was needed.
Report stages and unresolved dependencies
The report should distinguish passed, failed, blocked and not tested, with a timestamp, artifact identity and corrective owner. Retest only the changed stages and affected task when missing materials are supplied. Keep the technical findings separate from decisions about release events, rights and contractual obligations. No actual escrow deposit was reconstructed here. The deliverable is an engineering verification plan that a legal and operational owner can scope against the real agreement, supported by observable reconstruction evidence.
Software maintenance handover checklist
Choosing a SaaS development partner: the evidence to request
Bring the deposit manifest and agreed core task to scope an isolated reconstruction exercise.
B2B SaaS development: scope and acceptance
Does a readable source deposit prove the product can be rebuilt?
No. Dependency resolution, configuration, deployment and a core task require separate verification.
Should live secrets be pasted into the deposit instructions?
Use an approved secure provisioning process and a configuration inventory; do not put production credentials in ordinary documents.