ENTITY Documentation Portal
Scenario tutorial · contribution economy

Turn accepted engineering into a verifiable economic lineage

This scenario uses the real Vector and Memnox pattern: an external problem becomes a bounded BTG contribution, the exact change-set enters ENTITY lineage, unrelated upstream infrastructure reviews or tests it, acceptance becomes external evidence, and any later commercial relationship is recorded separately rather than invented retroactively.

1 · Start with an external problem

Capture the upstream repository, issue, problem statement, licence context and contribution class. Do not begin by assuming payment or ownership.

opportunity: external issue / defect / requirement
contribution_class: PRO_BONO | PROMISED/CONTINGENT | FUNDED/SETTLED
upstream_license: recorded
payment_settled: false until independently verified
upstream_source_ownership_claimed: false

2 · Engineer and freeze the exact change-set

Record the contributor identity, branch/commit, exact paths/blobs, local validation and the relationship to the external issue. The purpose is to make the contribution reconstructable and attributable before upstream consequence is known.

ISSUE → REPRODUCTION → FIX → TESTS → COMMIT → ENTITY / BTDU LINEAGE

3 · Push into an independent venue

Opening an upstream PR moves the contribution from internal assertion into an environment controlled by another project. Capture the PR number, head SHA, changed-file set, review state and CI state.

4 · Preserve intermediate states

StateMeaning
UPSTREAM_PRContribution is externally visible at a fixed head; acceptance is not claimed.
REVIEW_CIReview/CI state captured; maintainer action, required changes or workflow approval may still be pending.
UPSTREAM_ACCEPTED_RECORDEDUpstream acceptance/merge has been independently observed and anchored to ENTITY evidence.
SETTLEDOnly use when the economic settlement has its own verified evidence.

5 · Record upstream consequence

When maintainers approve, request a change, reject, close or merge, capture that as an external event. Do not rewrite earlier states. A requested changeset, for example, becomes part of the causal contribution history.

6 · Convert acceptance into contribution-value evidence—not automatic money

An accepted contribution has externally evidenced technical adoption. That can support future services, support contracts, sponsorship, procurement, integration work or a contribution instrument. It does not automatically create a dollar valuation, invoice, royalty, ownership transfer or obligation to pay.

ACCEPTED CONTRIBUTION → VERIFIED CONTRIBUTION RECORD → COMMERCIAL TERMS (IF ANY) → OBLIGATION → SETTLEMENT EVIDENCE

7 · If commercial terms exist, make them explicit

For future paid work, bind the agreed economic instrument to the contribution or service: sponsor agreement, procurement order, bounty contract, accepted-contribution compensation, support/integration service or other legitimate agreement. Preserve amount, currency, payer/payee, trigger, verifier and settlement evidence separately from the technical acceptance receipt.

8 · Publish only a portable public projection

The authoritative local/sealed receipt may include operational paths or internal state. Publish a portable projection anchored to the sealed receipt SHA-256 and ENTITY atomic root rather than exposing workstation-local paths or pretending the public projection is the sealed record.

Real baseline

Negative tests

Why this matters

The contribution economy is where ENTITY stops being only internal provenance. Independent organizations become actors in the causal history, allowing technical acceptance, rights context, later economic agreements and settlement to become separately verifiable states.