Evaluate a defined JRS licence or asset transaction.
JRS is evaluated as an interconnected system: methodology, evidence, software, technical specifications, implementation materials, version controls, brand assets, and provenance records. The Manifest alone is not the transaction proposition. The technical system remains in operational validation.
Potential transaction asset
Method and construct
- JRS methodology
- Decision Reconstruction Risk
- Five review conditions
- Codebook and evaluation logic
Technology
- Review Engine implementation
- Versioned API contract
- Manifest specification and generator
- Tests, fixtures, and integrity controls
Evidence and adoption
- Research records and stated limitations
- Training and implementation materials
- Public professional resources
- Platform evaluation evidence as developed
Governance and provenance
- Version and release records
- Asset and evidence registers
- Rights documentation actually established
- Brand and publication assets actually transferable
Transaction routes and commitment structure
No price is published before an executed transaction creates a supportable reference. Scope and cost move with the rights, environment, implementation work, support, field, exclusivity, and transition obligations actually agreed.
| Route | Purpose | Required definition |
|---|---|---|
| Evaluation | Bounded, non-production examination under an Evaluation License. | Environment, versions, test rights, data boundaries, confidentiality, support, success measures, and disposition. |
| Integration setup | Defined technical connection between current platform controls and JRS components. | Data flow, adapter, Manifest handling, routing, testing, security review, responsibilities, and transition. |
| Potential platform licence | Commercial organizational or embedded use. Term and scope determined in writing. | Methodology, software, brand, field, version, end-customer, derivative, improvement, support, audit, termination, and data rights. |
| Exclusive licence | Defined exclusivity supported by appropriate consideration and performance duties. | Field, territory, market, duration, minimum commitments, milestones, reserved rights, anti-shelving protection, and purchase option if applicable. |
| Asset Purchase Agreement | Transfer of a defined, diligence-supported asset schedule with limited transition obligations. | Included and excluded assets, conveyable rights, liabilities, consideration, representations, retained rights, transition assistance, and closing conditions. |
What moves it: a completed controlled evaluation, evidence of workflow value, a defined rights schedule, and agreement on implementation and transaction obligations.
Rights and diligence gate
A transaction schedule must classify each proposed asset before it is priced or transferred. Public availability, authorship evidence, permission to publish, permission to use commercially, exclusivity, assignment, successor transfer, and trademark rights are different legal questions.
Established evidence
Public authorship and development records, structured contributor consents, repository history, research records, technical implementation records, and asset provenance materials exist in the controlled estate.
Required before grant
The exact rights available for commercial use, exclusivity, derivative use, sublicensing, successor transfer, trademark use, and asset conveyance must be confirmed for the assets named in the proposed agreement.
Professional determinations
Contributor scope, revocability, AI-assisted authorship evidence, publisher rights, trademark status, employment context where relevant, and transaction structure require qualified professional review.
Controlled disclosure
Detailed chain-of-title records, agreements, unpublished research, source code, security information, and transaction documents are provided only under an appropriate diligence process.
Readiness gates
| Gate | Evidence required | Decision |
|---|---|---|
| 1. Rights | Asset schedule and counsel-reviewed rights classification. | What can be evaluated, licensed, made exclusive, or transferred? |
| 2. Technical | Stable contract, tests, limitations, data flow, security review, and integration evidence. | What exactly is operational and supportable? |
| 3. Commercial | Demonstrated workflow value, scope, consideration, obligations, and performance requirements. | Why transact instead of reproducing the general concept? |
| 4. Transferability | Documentation, institutional knowledge, dependencies, transition plan, and independent operability. | Can the asset function without continuing founder dependence? |
Preferred sequence
Controlled evaluation precedes commercial commitment. Integration evidence can support a platform licence. A licence can include an acquisition option. An Asset Purchase Agreement becomes credible when the buyer can identify distinct value, complete diligence, and operate the defined asset package with limited transition support.