Source & Repository Readiness

Safe metadata only. These records support readiness work; they do not establish complete legal title, repository acceptance or production readiness.

Inventory report

VPLedger_E_Drive_Recovery_Report_2026-09-17.xlsx — dated 17 September 2026

Integrity coverage

52,014 files / 54.27 GiB SHA-256 hashed without missing entries; USB OpenLedger manifest contains 10,024 file records

Ownership declaration

Boesing_Corporation_IP_Ownership_Schedule_2026.docx records the owner's VPLedger ownership declaration and sole complete-code custody statement

Historical support

Surviving documents support founder/originator status and record OpenLedger project ownership, contractual SaaS rights and an external development contractor

Legal-title limitation

Historical title documentation is incomplete; possession alone does not establish ownership of every component, and contractor-assignment and bankruptcy-transfer evidence is incomplete

Sensitive-material status

Restricted wallet, key and credential-related categories are indexed for safe handling; quarantine and repository-level scanning remain pending

Twelve gates, each stated with the evidence its current state rests on. States are deliberately conservative: anything unproven is not started or blocked.

• G1

  Inventory complete

  In progress

  Every candidate source set is mapped and named.

  Basis: The five core VPLedger roots and broader OpenLedger roots are inventoried; full canonical intake scope is not approved.

• G2

  Integrity captured

  In progress

  Manifests and hashes recorded where practical.

  Basis: Estate-level evidence records 52,014 SHA-256 hashes without missing entries and a 10,024-record USB OpenLedger manifest; accepted repository baselines are not yet linked.

• G3

  Provenance classified

  In progress

  Class A/B/C/D/X assigned with evidence.

  Basis: Core candidate roots remain class C while commit history, legal title, licensing and canonical intake are reviewed; nothing is class A or B.

• G4

  Sensitive material separated

  In progress

  No secrets, private keys or wallet dumps destined for Git.

  Basis: Restricted wallet, key and credential-related categories are identified for index-only handling; quarantine and repository-level secrets scans remain pending.

• G5

  IP and licensing reviewed

  Blocked

  Ownership and licence gaps explicitly recorded.

  Basis: An owner declaration and historical founder/origin and project-rights evidence exist, but contractor assignment, bankruptcy-transfer, complete chain-of-title and licensing evidence remain incomplete.

• G6

  Canonical repo mapping approved

  Not started

  Each accepted source set has an approved target.

  Basis: Mapping is proposed only; no approval recorded.

• G7

  Build baseline documented

  Not started

  Build, dependency and test state recorded per source set.

  Basis: No build has been attempted or reported.

• G8

  Version baseline assigned

  Blocked

  Versions assigned after source verification.

  Basis: Blocked by G3; no version may be assigned before provenance.

• G9

  Documentation baseline present

  Ready for review

  Readme, security, contribution and provenance expectations defined.

  Basis: Expectations are specified in this preview and await owner review.

• G10

  GitHub connection approved

  Not started

  Explicit owner approval to connect GitHub.

  Basis: No approval requested or given.

• G11

  Repository import verified

  Not started

  Imported contents match the accepted source sets.

  Basis: Nothing connected, so nothing imported.

• G12

  Domain release gate

  Blocked

  ByteShares.org links and domain release after full acceptance.

  Basis: Depends on G1 through G11 and explicit owner approval.

Proposed repository architecture — awaiting source and provenance acceptance.

Separation follows responsibility and provenance rather than a monorepo assumption, so a source set with unclear origin cannot contaminate verified material. Names are working labels, not final, and no URL is implied by any of them.

No material is currently classified A or B. Assigning a class requires evidence, not familiarity.

Every candidate source set is recorded against the same fields before any disposition is reached. Secret contents are never recorded — a sensitive file is represented by safe metadata only, and its contents are quarantined.

Source inventory

Core roots inventoried and preserved; canonical scope and repository intake pending

Integrity evidence

Preserved estate hashes and manifests exist; canonical per-repository baseline linkage pending

Sensitive handling

Restricted categories identified; publication quarantine and repository-level secrets scans pending

Dispositions reached

None

Candidate source sets inventoried and preserved in the recovery report, presented pending canonical repository intake and provenance acceptance — not as imported repositories.

The order in which the five evidenced candidate roots will be worked, once repository-level intake is authorised. Nothing in this sequence has been started: no source has been accessed, scanned, built or classified beyond the existing inventory evidence.

1. 01

   Quarantine sensitive material

   Restricted wallet, key, credential and personal categories are separated as class X before anything else is touched. Contents are never transcribed; only safe metadata is recorded.

2. 02

   Repository-local secrets scan

   Each candidate root is scanned in place for credentials and key material. Findings are quarantined, not fixed in passing.

3. 03

   History capture

   Presence of .git, readable commit history, remote or origin evidence, author and committer records, and earliest and latest verifiable commit.

4. 04

   Dependency and licence inventory

   Package manifests, lockfiles, submodules, vendored and generated material, third-party licences and copyright notices.

5. 05

   Build and test baseline

   Whether the set builds, what it needs, and whether tests pass, fail, are not runnable or were not verified. Failures are recorded, not hidden.

6. 06

   SHA-256 baseline linkage

   The candidate root is linked to the preserved estate hash evidence so the accepted bytes are identifiable later.

7. 07

   Provenance classification

   A, B, C, D or X assigned against recorded evidence. Candidates stay class C until evidence justifies otherwise.

8. 08

   Proposed canonical target

   The classified set is mapped to a proposed repository, with the mapping itself still requiring owner approval.

9. 09

   Acceptance review

   A repository acceptance record is completed and reviewed. Acceptance means honestly described and safe to publish — never production-ready.

Sensitive material is handled first and never leaves quarantine. A step is only recorded as done when its evidence exists.

One record per source set, completed during authorised intake. Sensitive content is recorded as metadata only or excluded as class X — never credentials, keys, wallet dumps or secrets. No record has been completed.

The record feeds the gates: intake fields close G1–G5, target and version baseline close G6–G8, and a completed, owner-approved record is the evidence for G11. Acceptance is not production readiness — operation still needs implementation and operational verification.

One record per candidate source set, held in this preview only. Values shown are the current honest state — the template is not pre-filled with assumptions, and no set has reached a disposition.

Architecture pages on this platform expose version, maturity, source and verification, and last reviewed, using "not yet assigned" wherever a value is unknown.

Proposed governance. These are not currently active GitHub settings, because there is no GitHub connection to configure.

• Protected main branch.
• Feature and fix branches with a pull-request workflow.
• Review required before merge.
• Required build and test checks once continuous integration exists.
• No secret is ever committed; scanning precedes merge.
• CODEOWNERS or equivalent ownership review where appropriate.
• Release tags cut only from an accepted main state.
• Changelog and release notes for every release.
• Security-sensitive changes require explicit named review.

A repository counts as accepted only when all of the following hold.

1. Intended source scope is clear.
2. Provenance classification is recorded.
3. Sensitive content is excluded.
4. Ownership and licensing status is explicit.
5. Canonical branch and source baseline are identified.
6. Build and dependency state is documented.
7. Tests are classified as passing, failing, not runnable or not verified.
8. The readme accurately describes current maturity.
9. No production-readiness claim is made without evidence.
10. Version and tag policy is applied prospectively.
11. A mapping exists from the repository to its ByteShares.org documentation.
12. Owner approval is recorded where required.

Acceptance does not mean production-ready. It means the repository is honestly described and safe to publish.

Credentials, private keys, wallet dumps and personal or confidential material are class X: quarantined, excluded from anything destined for Git, and never reproduced in documentation. Where their existence must be recorded, only safe metadata is kept — location reference, type and handling decision, never contents.