Key takeaway
An internal retrieval grant does not automatically cover customer outputs, training or another product. Test the destination and operation as well as the input file.
Use product operations as the unit of review
A product team may describe all of its work as analytics while one feature returns source text, another builds an index and a third trains a model. Those operations create different artifacts and output audiences. Translate the proposed agreement into an explicit feature matrix so an engineer can distinguish a permitted action from a new licensing question.
US copyright law distinguishes protected expression from ideas, methods and other excluded subject matter. Its compilation and derivative-work provisions do not enlarge rights in pre-existing material, and reproduction, derivative-work and distribution rights have statutory limitations. These provisions do not decide whether a specific model is a derivative work or whether a training use is fair. The contract and applicable law both need review.
W3C's provenance overview offers a vocabulary of entities and activities for tracing where an artifact came from. For product review, use that trace to connect inputs, transformations and destinations. Technical derivation does not itself create an unrestricted commercial use right.
Worked example: a narrow internal grant
In this hypothetical agreement, recipient L-7 may use package D-7 in an internal diagnostic retrieval feature for its own authorized staff. The assumed wording explicitly covers a private index and bounded source excerpts in that internal feature. It does not authorize external source-text outputs, model training or affiliate use. No real license is represented by these assumptions.
The completed matrix records the fictional grant as understood for review. It names the operation and audience rather than saying every artifact is allowed because it is derived. A release owner can inspect each feature against this map and reopen the agreement question where the feature differs.
| Product operation and artifact | Audience/use | Position under the hypothetical grant |
|---|---|---|
| Raw D-7 plus private search index E-7 | L-7 authorized staff, internal diagnostic retrieval | Within assumed express scope, subject to agreed constraints |
| Internal console shows a bounded D-7 excerpt | L-7 staff reviewing a diagnosis | Within assumed express scope |
| Customer API returns the same excerpt | External customer receives source text | Outside assumed grant; block release pending reviewed permission |
| External report contains aggregate fault trends | Customer-facing product, new output purpose | Not resolved by internal grant; hold for explicit review |
| Training job produces model M-7 from D-7 | Internal or external model purpose | Training permission absent; do not start from the retrieval approval |
| Group affiliate copies E-7 | Another legal entity's product | Affiliate use not assumed; separate recipient/grant review |
Follow the output route, including caches
For the hypothetical customer API, the development team initially reuses the internal console's response builder. The input and excerpt are identical, but the recipient of the output changes. The feature matrix catches the scope change because the output audience is part of the rule. A code path being technically reusable is not evidence that its use is covered.
The team also lists response caches, downloadable reports and logs containing source excerpts. The external feature could distribute those artifacts even if the main database stays private. Trace the delivered output, not merely the storage location of D-7. Identify who can obtain each copy and what the actual feature lets them do with it.
For the aggregate report, the absence of quoted text does not settle the contractual question. The hypothetical grant names an internal purpose, while the proposed report serves external customers. Rights, confidentiality, privacy and any relevant competition issues still need their own review. The matrix records a hold rather than a conclusion that aggregation grants permission.
Turn the matrix into release cases
The hypothetical product owner prepares demonstration cases using invented records so no real licensed data is required to test the routing logic. The expected results below are a completed release specification, not a claim that VOID has tested an actual customer's implementation. Engineers must implement and verify the checks in the real product.
Store the package identifier, agreement version, licensed entity, operation, output audience and grant decision beside each case. A successful technical response is a failure for a release case if it reaches an audience outside the approved scope. A new contract decision should change the recorded rule explicitly rather than being inferred from a feature launch.
| Demonstration case | Expected decision under hypothetical D-7 grant | Evidence the real team should inspect |
|---|---|---|
| Authorized staff asks internal console for excerpt | Allow the approved internal operation | Authenticated audience, bounded output and recorded grant version |
| Customer calls reused excerpt endpoint | Block source-text delivery | Response body and cached outputs, not only database access |
| Training job references D-7 as an input | Hold until separate training decision | Job input lineage and actual permission record |
| Customer requests an aggregate report | Hold external-product release for scope review | Purpose, audience and artifact definition |
| Affiliate service requests E-7 copy | Hold new-entity access | Legal recipient identity and specific grant |
A product change gets a grant decision
The completed hypothetical decision permits the defined internal retrieval feature while holding the customer API, report, training job and affiliate copy. The product team has concrete release cases to apply. Counsel has a list of requested changes rather than a vague request to approve all analytics and all derivatives.
Use offer comparison to compare the actual operation and audience clauses. Use due diligence to learn how a recipient's product exposes outputs and downstream copies. The secure-evaluation guide addresses a bounded test environment; this matrix governs a commercial product's functional scope. The annotation guide helps identify where source content persists within a new artifact.
VOID's permissioned introduction does not grant the product rights. The owner and named recipient separately decide samples, training and the final license. If a receiving program compensates VOID, that payment is conditional and disclosed; it does not replace the product/grant review or impose an upfront seller referral fee.