How to license your code to AI labs: the full process

1. Understand prices and what the buyer is buying.
2. Inventory the code and establish the rights.
3. Choose the route and define the broker's job.
4. Measure the candidate and keep the report traceable.
5. Compare the offer and calculate your net.
6. Agree who cleans the code and verify the result.
7. Let the buyer evaluate the agreed package.
8. Confirm the license, acceptance and payment terms.
9. Deliver the right version and track payment.

These are decisions, not nine compulsory contracts. A standing-rate partner route can combine confidentiality and the license in one agreement signed before connection and preparation. It may authorize later lab licenses without another owner signature. A separately scoped opportunity can use an NDA and limited evaluation before a final license. Read step 8 before signing whichever document grants the rights.

The original, the evaluation sample and the licensed delivery are separate objects. Each needs an identifiable version and permission for its use. If a right is unresolved, stop before sharing the affected material. A correction returns to the person preparing that route's copy.

Use a price reference for the right object

A repository, a million tokens and a finished training task are different units. Comparing their prices without that distinction can make a modest source license look like an underpriced task-production contract.

The Rightmark Price Index, Q4 2026, published October 26, gives these code references:

Epoch AI's January 12, 2026 report attributes the task-cost range to interviews. A task requires a problem and a reliable way to grade the result. Do not multiply a guessed number of possible tasks by that range and call the product your repository's value. Someone still has to produce, check and obtain a buyer for those tasks.

The index is neither a lab tariff nor evidence that a similar repository has sold at the top of a range. It does not certify rights or demand. Keep its edition, unit, evidence type and confidence beside the number when discussing it with your team.

Reconcile a token quote before judging the price

One public program makes the distinction tangible. Pangea's company code-licensing page lists indicative rates of $100 per million source-code tokens and $40 per million Git-history tokens. Those are Pangea's program rates, not Rightmark's rate card or a universal AI-lab price. Its eligible counts exclude material such as generated, vendored and third-party code.

Invented calculation, using those published rates and assumed quantities: 2 million eligible source tokens plus 20 million eligible history tokens gives (2 × $100) + (20 × $40) = $1,000 for one license. If only 12 million history tokens qualify, the same calculation gives $200 + $480 = $680. These are explanatory calculations, not measured repository results or actual offers.

The useful question is what was counted. Record the repository revision, included history, exclusions, token-counting method and version, and whether the amount uses estimated or accepted quantities. Repo Check's source-token measure is a rough character-based estimate. It is not proof that a buyer's tokenizer will produce the same quantity. Ask for reconciliation before comparing two totals.

Improve evidence of value before increasing volume

Here is what I would inspect before paying for preparation:

Rightmark's code guidance emphasizes hard, testable work and genuine bug-fix history. A tidy repository is easier to inspect, but a cleanliness score does not establish how many paid tasks it will yield. Rarity matters only when a buyer needs what is rare.

Removing generated files may reduce the count while improving the usable package. Restoring missing history or explaining a real regression test can add more useful evidence than writing new code to inflate volume. The valuation guide explains why a quote changes with scope, selected quantity and rights; later in this guide we will compare the money on both sides.

Make an inventory your engineer can reconcile

Start with a candidate whose purpose, ownership and build history are understandable. A retired service may be easier to consider than code central to your current competitive advantage. You still decide whether the proposed use is acceptable.

Keep a private row for each candidate: neutral label, purpose, language or engine, versions, source-control system, active years, approximate size, available history, tests, linked context, dependencies, business owner and engineer. Add known exclusions and unanswered rights questions. Inventory the catalog before proposing a catalog price, then separate distinct repositories from mirrors, forks and overlapping lots. The same code in two places is not automatically two saleable assets.

We will follow Northstar Tools and its retired Python scheduling service. The company, repository, records, findings and outcomes are invented. Assume it has full Git history, tests, a client-specific connector with unresolved rights, a private package needed by a test, and issues in a separate tracker. A fixture contains an exposed credential.

Northstar's engineer revokes or rotates the credential immediately. Removing it from the copy to be licensed is a separate task. GitHub's sensitive-data guidance puts revocation first; a pending deal is no reason to leave an active secret exposed.

A clone also does not necessarily contain all the surrounding material. GitHub's backup guidance distinguishes repository history, large-file objects, wiki repositories and other metadata. Inventory the pieces separately. Use the export guides to plan the selected exports rather than assuming one ZIP includes everything.

Match permission to each included part

Repository administration and ownership are different responsibilities. The person who can connect GitHub may not be able to license work owned by a client or a former employer.

Rightmark's code ownership pack calls for relevant founder, employee and contractor IP documents, client permissions and earlier licenses. Match those records to the included work. Review marketplace assets, engine components, copied files, generated material and dependencies separately. A root LICENSE file cannot establish the provenance of every component.

Use three decisions: continue with evidence covering the proposed use; exclude a bounded unresolved component and recheck usefulness; or hold the candidate because an essential right is missing. Counsel should assess the actual contracts and licenses.

For invented Northstar, excluding the connector may solve the disclosure boundary but break the executable task. The engineer must test that consequence. Permission to distribute your own scheduler does not manufacture permission to distribute a private dependency or client data inside a fixture.

Record whether the code was ever public, including releases, mirrors and packages, and disclose known AI-generated or assisted material. “Private today” does not mean “never public.” Keep owner statements separate from tool observations. Preserve genuine development history; squashing it or adding superficial commits to improve a count makes the evidence less useful.

Establish the format before converting the project

Owners often have more than a conventional Git repository. The next question is what a buyer can inspect and reproduce, not whether every project can be forced into the same upload.

These are qualification questions, not a promise that every format is accepted or a reason to reject one without review. Repo Check is Git-based. For other systems, ask about the accepted evidence and export before migrating anything. Preserve the native original and the mapping through any conversion. Screenshots of an editor or a folder of current files do not reproduce development history.

Describe the candidate before arranging access

A first message can be useful without including private source, paths or customer names:

We have three retired software repositories, mainly Python and TypeScript, developed over several years. Full history and tests are available; some issue context is separate. One candidate has a client-specific connector that needs exclusion or permission, and another needs a private package to build. We can start with one selected repo or discuss screening the catalog. Which route fits, and what evidence should our engineer prepare next?

This is an invented first-contact template, not a customer quotation. Add a business contact and an engineer who can answer technical questions. A useful reply establishes the next artifact, intended use, recipient and permission. Request a call if it would resolve those issues; a call request alone does not establish buyer selection or a quote.

An AI developer may buy through a licensing intermediary. The party signing with you, the operator preparing a copy and the eventual lab receiving it can be different. Find out their roles and what identification you receive before granting access.

Name the deliverable and when rights are granted

Tests and CI history can support screening; they are not already finished accepted tasks. For invented Northstar, the private package and excluded connector must be resolved before promising a runnable task. A source/history license may have a different usable scope.

On the standing-rate route described in Rightmark's Trust page, a combined confidentiality and license agreement precedes connection. The partner prepares its authorized copy and may arrange later selected lab licenses under that grant. On a separately scoped route, an NDA, engagement, evaluation permission and final license may be separate or combined documents. What matters is the authority each supplies, not a required number of papers.

Before signing, ask who may receive the material, which uses or later sales are authorized, and who can approve wider access. Some processes permit an expressly agreed confidential buyer code; do not assume every eventual lab must be named or that an NDA gives you a fresh veto over each sale. The agreement-permissions guide explains how those permissions fit together.

Make the service and the economics explicit

A useful intermediary can assess fit, coordinate rights evidence, find buyer interest, negotiate scope and economics, organize permitted preparation and evaluation, and reconcile delivery and receipts. Agree which of those services are included. Advice and coordination are different from hands-on engineering, legal representation, a commitment to secure a buyer or collecting the money.

Rightmark's published offer is concrete: on standard licenses, the buyer pays Rightmark's fee on top, with no deduction from the owner's payout. On premium and bespoke deals, the owner keeps 75% to 85%, agreed in writing before sale. Buyers cover extraction, scrubbing and transfer, with nothing upfront for the owner. The worksheet below turns that offer into an amount, a defined calculation base and a work scope.

Check the broker's legal entity, responsible contact, authority, term, services, fee payer and base, access rules, subcontractors and reporting. Ask for permitted references or appropriately redacted completed-work evidence if that matters to your decision. A buyer logo, intake record or attractive portal does not prove a completed paid deal. An illustrative calculation is not a reference either.

If you are considering other brokers or a direct buyer, review prior mandates and protected introductions. Non-exclusive licensing can coexist with restrictions or fees concerning an introduced opportunity. Identify pre-existing buyer relationships in writing and check what survives termination. The broker-role guide goes deeper into that distinction.

Run the check on a known full clone

Repo Check currently measures a Git repository locally. Release 2.5.0 requires Python 3.8 or newer and Git. Download the current archive from that page, check its listed fingerprint, unzip it and point the script at a full local clone.

On macOS or Linux:

python3 rightmark-repo-check/scripts/rightmark_repo_check.py /path/to/repo --out ~/rightmark-reports/project-a --label "Project A"

On Windows:

py rightmark-repo-check\scripts\rightmark_repo_check.py C:\path\to\repo --out $HOME\rightmark-reports\project-a --label "Project A"

Replace the illustrative paths. Keep the output in a separate folder and choose a label you are comfortable sharing.

By default the check reads locally without uploading source, installing dependencies, running the project or executing tests. The optional --public-check is off unless enabled. It makes disclosed requests to public code archives, registries and a web archive; consider whether those checks are appropriate before turning it on.

--ref selects a branch, tag or commit. --quick skips the full-history pass and estimates history size, so retain that limitation. --test-report reads an existing JUnit XML report; --test-commit can identify its tested commit when the report does not. The tool records whether the report matches the assessed revision. It does not rerun the tests or certify that the prepared delivery passes them. An owner-supplied --merged-prs count likewise stays distinguishable from measured evidence.

The source-token estimate uses a rough characters-divided-by-four model. Save the tool version and count basis with the result. A quoted buyer quantity may use a different tokenizer or exclude material that this preliminary measurement included.

Keep a private map from each report to its repository

A neutral report becomes difficult to use if nobody can reliably match it to the actual code. Keep a private crosswalk with:

• Neutral label, owner-local repository locator and report repository ID.
• Checked ref and commit, tool version, script/archive checksum and scan date.
• Included lots, mirrors or overlaps with other candidates.
• Rights and private-dependency flags, plus the responsible owner.

Keep actual URLs, internal names and this crosswalk with the owner. They do not belong in the initial share file. A matchable identifier and neutral label are useful controls, not a guarantee of anonymity.

Read share.json before sending it. Do not upload the whole output folder, source or credentials. The tool page's browser preview and the action that saves a report to the portal are separate. Reconcile every quote's neutral ID to your private inventory before accepting it.

Turn findings into assignments

The current standing-rate route checks for 3 human contributors, 100 non-merge commits, 10 merged pull requests and 10,000 original code/test lines, after relevant exclusions. These are route-specific gates, not minimums imposed by every AI lab. Readiness signals do not prove title, never-public status, demand or accepted task yield.

In the invented Northstar fix list, the rights owner resolves the connector; the engineer tests a permitted private-package setup; the security owner verifies removal of the rotated secret from the export and history; and the scope owner decides which issue context may travel. Stop if the useful package cannot be cleared. Do not manufacture commits or conceal a limitation to obtain a pass.

Match the measured candidate to the proposed buyer set, excluding duplicate lots. If price and report disagree, reconcile version, eligible quantity and rate basis first. That is more informative than assuming either a low offer or a market-price change.

If you have a candidate ready, run Repo Check locally and inspect the output before commissioning preparation.

Put the same scope on both sides

I would compare offers on one sheet, beginning with the exact repository version and selected quantity. Align source/history versus task delivery, permitted uses, recipients, term, exclusivity and onward rights. A higher amount for broader rights is not a higher price for the same thing.

Define three money lines. Owner license consideration is the amount or basis agreed before owner deductions. Owner net is what remains after actual owner-borne deductions and costs. Buyer total includes the license plus buyer-paid fees, preparation and other charges. The invoice flows should explain how those totals are reached.

For Rightmark, place its public offer beside the calculation: buyer-funded fee on top for standard licenses; 75% to 85% owner retention for premium/bespoke, agreed in writing; buyer-funded extraction, scrubbing and transfer with no upfront owner cost. Identify the retained-share base and included preparation. Do not assume “80%” tells you whether it applies before refunds, withholding or installments.

Rightmark's Trust policy also says it pays a Scout from its own income, never the owner's. Do not add a routine scout deduction to the owner's worksheet. Reconcile any other proposed charge separately, including who approved it and what it purchases.

Follow a filled comparison through to both totals

Invented offers: all amounts, rates and terms below are assumptions, not actual Rightmark transactions. Assume both offers cover identical code, non-exclusive rights, currency and payment conditions. Taxes and bank charges are excluded so the fee difference is visible.

Offer B's larger headline leaves the owner $400 less, while the buyer spends the same amount. Its intermediary share is already inside the license amount; adding it again would overstate buyer cost. The assumed $2,000 fee in A is not Rightmark's published standard rate. The invented 80% in B lies within its public premium retention band but is not an agreed transaction.

In A, the paperwork should direct the $10,000 owner payment and the separate fee/preparation payments to their named recipients. In B, it must identify who collects the $12,000 and accounts for the $9,600 owner share and $2,400 intermediary share. Do not assume money passes through Rightmark in every route.

Now change one condition: B buys exclusive rights, requires unpaid engineering or makes payment conditional on a wider acceptance test. The two offers no longer buy the same thing. Record those differences before ranking them; invented dollar values for every restriction would create false precision.

Ask for a better offer with evidence

A good offer combines acceptable use and authority, an attractive owner net, affordable work and credible payment terms. It is not automatically the largest number in the Price Index.

Use this response when the amount looks low:

For candidate Project A at the stated revision, please show the accepted quantities, exclusions and rate basis. We can supply the preserved history and a matching test report that may be missing from the assessment. Please price that scope again, or propose a narrower grant and preparation requirement at the current amount.

This is an invented negotiation template. If fewer history tokens qualify, the earlier $680 calculation may be correct. Challenge an exclusion with evidence or discuss the rights being purchased. A buyer may simply have no current need for the project; ask whether another route or later review is useful without assuming a better bid will appear.

Decline or hold when authority is missing, onward use is unpriced, deductions remain unexplained, preparation is extensive and unpaid, liability is unacceptable, or proceeds fall below what makes the transaction worthwhile to you.

Test whether an improvement pays for itself

Invented work decision: eight engineer hours at an assumed internal cost of $100 an hour consume $800 of capacity. An additional conditional $500 in net license proceeds does not, by itself, justify that work. Buyer-funded preparation changes the calculation, but owner review time and uncertain future sales still count.

Recover existing evidence and fix an agreed useful dependency before building a large new test suite for a speculative premium. Ask which improvement changes buyer eligibility, price or acceptance, who pays and what happens if no license follows. The written quote should include taxes, withholding, currency conversion, transfer charges, payment trigger and any extras. Unknown charges remain open items, not zeroes.

Separate four jobs that are often called anonymization

Code preparation is more than deleting names. It must remove material that cannot travel while preserving the engineering relationships the buyer needs.

The ICO's pseudonymisation guidance distinguishes replacing identifiers from making people unidentifiable. Data remains personal in the hands of someone holding the additional identifying information; a recipient's position depends on context. A clean-room boundary also does not erase identifiers or create a right to share client material.

Consider this invented transformation; every identity, address and value is made up:

Names may remain in commit messages, paths, reviews, attachments, fixtures and links after the latest file is cleaned. Check the included history and context. Keep a consistent identifier only where the relationship is useful, restrict the reversal map, and avoid a global pseudonym reused across unrelated recipients.

In Northstar's invented package, the scheduler issue still needs to connect to the fix and regression test. Removing that relationship merely to make the export look simpler damages the intended evidence. Removing the client's name also cannot cure a missing contractual permission.

Choose the performer, location and bill

There is no universal rule that the owner must complete all cleaning before any authorized transfer. Put the chosen arrangement in writing:

Rightmark publicly says buyers cover extraction, scrubbing and transfer, with no upfront owner cost. Convert that into a code work order: repositories and refs, history/context, exclusions, secret handling, dependency changes, tests, human reviewer, permitted execution/network, outputs, funded work and approval for extras. A general offer should not become a surprise engineering bill or an assumption that unlimited work is included.

Current tools have distinct limits. Repo Check measures code now. The Clean Room page describes code identity rewriting as future work, and later archive-cleaning jobs as pilot work. Rightmark separately offers company-data de-identification by specialists inside owner systems. Ask which code work and environment your quote covers; a local measurement report does not mean a repository has been scrubbed.

A buyer-supplied assessment also needs review. Determine whether it installs packages, executes code, calls a model or uploads results. Use only the authorized environment and inspect its output. A report can expose paths or flagged snippets even when its summary looks harmless.

Transform a separate copy, then prove it still serves the task

Freeze a secure original and record the chosen revision, included history, linked exports and test baseline. Keep a separate preparation copy with controlled access. The baseline explains the transformation; it should not become an uncontrolled archive of sensitive material.

Revoke exposed secrets first, then remove them from the agreed source, history and context. GitHub documents that history rewriting changes affected commits and their descendants. Preserve an old-to-new mapping so issues and tests can be reconciled. The git-filter-repo manual describes a commit map covering changed, unchanged and removed commits; a removed commit may have no replacement.

Work through the prepared version in this order:

1. Apply agreed exclusions and transformations across the included material.
2. Make required dependencies available through a permitted mechanism, or document the limitation.
3. Rescan for the relevant secrets, identifiers and excluded material.
4. Build and test in the approved environment where the deliverable requires it.
5. Follow important issue, fix, review and test relationships through the transformation.
6. Inspect a representative sample with a human reviewer and record unresolved limitations.

For invented Northstar, the connector is excluded or expressly cleared, the private package is lawfully available or remains a declared limitation, issue IDs point to the prepared commits, and the credential has already been rotated. Run the tests against the version intended for delivery. Do not restore production credentials or replace a meaningful failing test with a trivial green one.

Preparation tip: Have another engineer follow the setup instructions in a clean environment. A test that works only because the original engineer already has a private library installed has exposed an incomplete handoff.

Finish with the prepared revision and manifest, inclusion/exclusion summary, dependency/build instructions, test and rescan results, sample coverage and owner release decision. Keep identity and commit maps privately controlled. A technical rescan is useful evidence, not a certification of ownership or anonymity. The preparation-scope guide helps define the work and costs in more detail.

Put a cover sheet beside the sample

A sample should answer a question, such as whether the buyer can follow a bug/fix/test sequence or reproduce a specified task. Choose the material against that question, including a likely weak point rather than only the most flattering example.

Give the buyer a cover sheet with the candidate and prepared revision, selection method, included material, sample size and unit, exclusions and known gaps. Add the recipient, purpose, allowed operations, location/network rules, retention/deletion terms, contact and decision date.

A curated service can demonstrate a build; it cannot show that every repository in the catalog runs. Say how it was selected. The sample-evaluation guide explains the inference limits, but the immediate action is simple: make the coverage visible beside the files.

Separate code inspection, execution, model-assisted grading, training and retained evaluation use. An NDA alone is not permission for all five. State which operations are allowed and who approves a change before a buyer starts. A permissible execution test can be useful; it just needs to be the one the owner authorized.

Turn feedback into a next action

Ask for the version inspected, method used and specific result. “Needs more work” is difficult to act on. “The setup still calls the excluded connector” identifies a bounded problem. A new buyer preference is not automatically a defect in something never promised.

Suppose that connector failure occurs in the invented Northstar sample. One option is a permitted replacement that still tests the same behavior. Another is a source/history license with the exclusion expressly accepted. A third is to decline the task route. The choice changes scope and possibly economics; it must reach the offer worksheet.

A passing sample supports the next commercial decision. It does not establish acceptance of all repositories, a signed license or a paid transaction. If quantity, rights, work or acceptance conditions change, refresh the quote. Record a new sample version after a correction and identify what has been retested.

When a buyer asks for another recipient or operation, check the existing permission before expanding access. If the opportunity ends, close access and follow the agreed return, deletion and retention terms. Keep the decision evidence you are entitled to retain.

Use this check before the initial grant on an advance-authorized partner route, then verify that the later sale stays within it. On a separately scoped deal, it may accompany the final license. It is not a fictitious extra signature required for every route.

Put ownership and use on different lines

Rightmark's licensing explanation describes ownership retained while specified rights are granted. Non-exclusive does not mean “training only,” and a narrow source license differs from broad onward-use authority. Price those differences against your competitive concerns. No buyer is obliged to accept every restriction an owner proposes.

Define acceptance against the actual deliverable

Specify the accepted object and revision, counted units, dependencies, context, concrete tests and exclusions. Name the authorized decision-maker, review period and how acceptance or rejection is recorded. A source/history package and an executable task require different tests.

Agree what happens if a check fails: correction, replacement, narrower scope, price adjustment, rejection or refund where applicable, plus responsibility for extra work. These are choices to settle, not universal Rightmark entitlements. Decide whether one rejected repository or task affects payment for the rest. The acceptance-and-payment guide expands that practical decision.

Have counsel assess title warranties, liability, caps, indemnities and disputes. Some code routes described on Rightmark's Trust page include uncapped ownership responsibility. Decide whether the proposed responsibility is acceptable for the net proceeds or requires narrower scope, a different price or declining the deal.

Approve the money and authority together

Attach the offer worksheet: fixed amount or rate/base/eligible quantity, payer and payee, fees, funded work, currency, taxes, withholding, invoice trigger and due date. State any condition involving buyer selection, acceptance, cleared buyer funds or required tax/payout details. Advances and milestone payments are deal terms to record, not assumptions about the service.

Resolve signatories, permitted recipients, transfer method, execution/network limits and retention before access or delivery. A faster delivery target cannot substitute for missing rights or an unfinished preparation job. Request the current proposed agreement for your route and have counsel review it; an unsigned generic sample is not the contract governing your code.

Read the timeline from the correct starting event

The current Rightmark homepage gives indicative code-scrubbing and lab-review ranges; the code hub describes the wider sequence and total. Use them for planning, then agree the actual milestone definitions for your opportunity.

The homepage does not define an exact start event for every range. Put one in your plan: for example, when an authorized usable copy enters cleaning, and when the ready package is presented for lab review. Those are milestones to agree, not automatic clocks starting with your first email.

Do not add the longest stage estimates into a new forecast. Work may overlap, scope may change and review can return to preparation. The total is not a signature-to-cash SLA. You can accelerate the rights pack, stable version, dependency access and owner decisions. Buyer selection and lab payment remain counterparty events. Ask which event is pending and who owns the next action.

Send a package the receiver can identify

Use an approved export or scoped, revocable connection. Your administrator should understand access and revocation; password sharing is not the transfer method. Direct owner-to-buyer delivery and partner-managed distribution follow their respective grants.

A useful delivery manifest records:

Keep credentials and reusable access secrets out of every sample, manifest and delivery. Private repository crosswalks, identity maps and reversal keys stay with the owner. If rights or security evidence is needed for an agreed review, redact secrets and send it through the separately controlled review channel, outside the licensed dataset.

The receiver checks integrity and expected files, then the agreed functional and coverage tests on that version. A receipt proves arrival, not acceptance or payment.

Consider two invented Northstar outcomes. A source/history package meets its express connector exclusion and agreed checks. Alternatively, a task fails because the necessary private package is still unavailable. Apply the negotiated correction, narrowing or rejection path to that specific failure. Give any corrected package a new manifest and rerun the relevant checks; an old green report belongs to the old version.

Reconcile events and cash separately

Maintain an event log with the responsible person, evidence, agreed deadline and next follow-up. Track delivery, review, acceptance/rejection, correction, the invoiceable event, invoice issue, buyer funds and onward owner funds. This is an illustrative set of events, not a universal order: an advance can precede delivery, and installments can split settlement.

Return to the step 5 worksheet when money arrives. Reconcile contracted owner consideration, authorized deductions, invoiced amount, tax/withholding/FX/transfer treatment, cash received and balance. A smaller bank receipt needs documented explanations rather than an assumed commission.

If owner payment is conditional on buyer funds clearing, show that condition beside the expected net and due event. A signed contract, technical acceptance and cleared cash are different evidence. Keep verified bank and tax details in the agreed secure process, never a repository or public template. Assign someone to follow up on the outstanding event instead of treating a successful file transfer as a completed transaction.

Maintain a register by candidate/version, recipient or authorized partner, use, term, exclusivity, economics and later-license authority. Non-exclusive code can be licensed again when a buyer chooses it and the commitments allow it. There is no dependable number of future sales to multiply into a forecast.

Refresh evidence when commits, contributors, dependencies or context change. Check protected introductions and earlier buyer relationships before switching broker or route. On withdrawal or expiry, follow the agreement's notice, access and deletion terms. Revoking a Git connection does not revoke a completed license or undo permitted training.

You can start with five actions:

1. Choose one candidate worth discussing.
2. Name its rights owner and technical owner.
3. Record exclusions and missing permissions.
4. Preserve history and rotate any exposed credentials.
5. Send a non-sensitive description or run the local check.

The companion inventory, private crosswalk, offer worksheet, preparation checklist and stage tracker give you somewhere to keep the answers. Fill private fields only in your own controlled copy. You do not need to clean an entire estate or upload source to begin.

• Repository inventory (CSV)
• Private report crosswalk (CSV, keep your filled copy private)
• Offer comparison and economics worksheet (Markdown)
• Preparation, sample and delivery checklist (Markdown)
• Stage and payment tracker (Markdown)

I would start with one candidate and one specific question about its fit or economics. Appraise your code to explore the route and indicative value. The first answers do not commit you to a license or guarantee a buyer.