Procurement · fictional business data
The approval was valid.
Then something changed.
Two purchases are ready to proceed. Record their starting point, change an offer or withdraw an approval, and see which decision still holds — with a real record behind every result.
Your purchasing desk
What can we approve today?
The service calculates the outcome. Nothing has been recorded yet.
Use the fictional values provided. These values are sent to BuildSeal and stored in demo records. This is not an encrypted or private workspace.
The decision trail
First, preserve the starting point.
How this experience works
A deterministic rule evaluator checks the offer against its budget, the supplier document and human approval. All three must pass. It creates assessment bindings using the existing assessment module, seals the decision and compares it with the previous sealed record using the decision-drift service.
This bounded example does not run the full NYM, A9 or A10 orchestration. A changed input associated with a changed decision is an attribution record, not proof of causality. A valid seal does not mean a correct business decision.
The separate verifier shows integrity, signature, timestamp, content and trust scope. Signer trust and strict verification are not implied here.
No service response yet.
Verify on your own machine
Download the evidence. Run the checks yourself.
Fictional procurement record:
seal_1792932046613_1cbf006ecbab.
This record passed local strict verification with an explicitly supplied
trusted public key.
Download the verification bundle
Check the archive before extracting it:
echo '29bdd308b8a53ce98930e8baf2f9d4d7cc3aff0fe8318c3a330508ca064e7c08 buildseal-strict-demo.tar.gz' | sha256sum -c - tar -xzf buildseal-strict-demo.tar.gz cd buildseal-strict-demo sha256sum -c SHA256SUMS
Inspect the downloaded verifier and script before running them. You can also build the verifier from source: read the build instructions.
./isc_pack_v5_bin --verify pack.json --content content.json \ --trusted-key 07bef2a88534eddfed032a4d06de927af771affe8975c98c21256a7855bdc03e --strict
Prebuilt binary: x86-64 Linux / compatible WSL, GLIBC symbols through 2.39, OpenSSL 3 libraries and the openssl command. Tested with OpenSSL 3.0.13; minimum OpenSSL version not established. macOS source-build instructions and native Windows builds are untested.
Public key and archive checksum
Ed25519 public key: 07bef2a88534eddfed032a4d06de927af771affe8975c98c21256a7855bdc03e Public-key SHA-256 fingerprint: a5ec97589519d9eea3c6985330f601eadcc6f261234636badb0137039bd0a595 Archive SHA-256: 29bdd308b8a53ce98930e8baf2f9d4d7cc3aff0fe8318c3a330508ca064e7c08
Also published in the source repository. These are separate operator-controlled publication channels, not independent identity certification.
Verification scope. Strict verification checks content matching, package integrity, signature, the explicitly trusted key and timestamp verification against the supplied CA trust store and request. It does not establish decision correctness, independently certify signer identity or verify the record chain.
This is isc_pack_v5_bin for hosted 5.1 packages, not isc_verify v0.2.0. Compatibility between the profiles is not established. The fictional content was processed by BuildSeal's server.
NYM / A10 / A9
Watch a memory earn its place.
Run three statements through the real NYM memory writer. Inspect the assessment, state transition and proof lifecycle that actually result.
Open the live memory experience →