An investor opens an offering page, reads the documents and submits a subscription. Later, an operator publishes a revised PDF. When support opens the old order, which document should appear?
A link to the current file cannot answer what the investor accepted. A durable record needs the document version, its content hash, the language presented and the subscription that accepted it. It also needs continued access to the corresponding file. A hash can identify a mismatch, but it cannot recreate a missing PDF.
Aurum RWA’s local implementation already stores document versions, offering terms bundles and subscription acceptance records. This article follows those connections. It also identifies a deliberate limitation. The current terms-editing path requires an offering to remain in draft. A live amendment and investor reacceptance workflow should not be assumed from the existence of versioned files.
Separate a file from the bundle offered to the investor
An offering may include terms, risk disclosures and an offering memorandum in more than one language. Updating one file should not silently change the entire set attached to an earlier subscription.
The prototype’s terms builder takes explicit document version IDs. For each selected document, it checks ownership, publication status, a clean scan result and an effective time that has arrived. It records the document ID, hash, locale and revision in a terms payload, together with the rights description and redemption conditions. That payload receives its own terms version and content hash.
The distinction is useful. The document version identifies one file. The terms version identifies the selected bundle and related text. A subscription can therefore refer to the bundle it accepted even if an administrator later prepares different documents elsewhere in the system.
Validate acceptance on the server
A checked box is a user interface event. The backend still needs to verify what the checkbox refers to.
In Aurum’s subscription handler, the request includes the quote hash, quote version, terms version ID and an acceptedDocuments list. The service recalculates the quote context and rejects a mismatch. It then checks that the submitted list matches the documents in the selected terms bundle, including each document version ID, SHA-256 hash and locale. It rechecks that the documents remain published, clean and consistent with their stored hashes.
The subscription stores the accepted document snapshot. Separate acceptance rows link the investor, document version, actual locale, session and subscription. These records answer a narrower and more useful question than “has this person ever accepted terms?” They identify the documents attached to this particular submission.
The diagram shows the current data relationships. The live amendment lane is a design question outside the current draft-only terms editor.
Give every identifier a specific job
A synthetic bundle might contain an English terms file at revision 3 and an English risk disclosure at revision 2. The numbers need not match. A revision belongs to a document series, while the bundle version identifies the combination selected for an offering.
| Record | What to retain | Why it matters |
|---|---|---|
| Document version | Stable ID, file hash, locale, revision and file reference | Retrieve the exact file |
| Terms bundle | Selected document versions, related text and bundle hash | Reconstruct the offered set |
| Subscription | Terms version, quote context and accepted document snapshot | Preserve the submission context |
| Acceptance record | Investor, session, subscription and actual locale | Trace the recorded acceptance |
Keep content hashes and version identifiers distinct in the interface. Operators may understand “English risk disclosure, revision 2” without reading a long hash. Engineers still need the hash when checking that the retrieved bytes match the record.
Decide what happens when a live document must change
Aurum currently rejects terms edits once the offering leaves draft. That constraint prevents a casual replacement from becoming an undocumented amendment to a live offering. It also means the current workflow does not implement every scenario an issuer might require.
For a proposed live amendment feature, define the scope before adding a replacement button. Which new subscriptions use the new bundle? Can an investor with an open quote continue? Which existing investors must acknowledge the change? What happens if one translation is ready and another is not?
These are design requirements for an extension. An implementation could introduce an amendment record, an effective boundary and explicit reacceptance tasks. Historical subscriptions should retain their original snapshots, while the amendment records describe subsequent changes. Whether a particular change requires renewed acceptance belongs in the project’s business and legal review, not in an inferred rule based on a filename.
Test retrieval as well as submission
A versioning feature is incomplete if support cannot retrieve the historical file. In a review environment, create a bundle, submit a subscription and then prepare a new document revision. Open the old subscription and retrieve its original files. Compare their bytes with the recorded hashes.
Also test a stale quote, a missing document, the correct version with the wrong locale, and a file whose bytes no longer match its recorded hash. Keep the expected rejection separate from the observed result. A checklist with every row marked passed before running it provides no evidence.
Download the offering document versioning review kit. It includes a bundle inventory, acceptance fields and a change-review matrix. Use synthetic records when sharing the exercise publicly; investor identities and private offering documents should stay out of a demonstration repository.
Aurum RWA includes the draft-stage bundle and subscription acceptance workflow described here. For an investor portal project, bring a sample document set and one realistic update scenario. That makes it possible to discuss the records, screens and approvals the implementation actually needs.
