Trust / Governance

Every movement leaves a record.

Data should never become detached from its source, permissions, destination, or commercial history. bnd is designed to preserve that chain from first discovery to final closure.

Website today

Operational today

The diagnostic accepts high-level descriptions only. Raw data assets are not transferred through this website.

First transaction

In development

The first transaction will use deal-specific agreements, a controlled transaction record, and an approved transfer process before automated rail infrastructure exists. The internal process and templates are being prepared now.

Future rail

Future rail architecture

Provenance, permissions, access events, transactions, and lifecycle events will form a structured, queryable record across the rail.

01 / The seven records

The record that travels with the data.

A data package is more than a file. It is the material together with the evidence that explains where it came from, what happened to it, who may use it, and what occurred commercially.

01

Source record

Who supplied the material, the originating system or process, relevant collection context, time period, geography, contributor or subject categories where applicable, and the supplier's relationship to the source.

02

Authority record

What the supplier confirms it controls, what evidence supports that authority, what obligations or third-party rights may apply, and which questions remain unresolved. Supplier confirmation is not automatic legal clearance: the level of evidence required increases with the sensitivity and risk of the proposed use.

03

Package manifest

A persistent package identifier, version, format, included fields, excluded fields, volume, integrity hash, quality observations, and any approved samples.

04

Transformation record

Every material change made before delivery, including filtering, redaction, pseudonymisation, labelling, deduplication, normalisation, sampling, and quality review.

05

Access record

Who was authorised to inspect the material, which package or sample they accessed, when access occurred, what action they took, and which approval allowed it.

06

Rights and transaction record

The buyer's legal identity, licensed package, permitted purposes, prohibited uses, territory, duration, onward-transfer restrictions, applicable agreement, commercial terms, payment status, and renewal history.

07

Lifecycle record

Current package status, expiry, suspension, disputes, incidents, deletion or return obligations, buyer attestations, renewals, and closure.

The ledger is not a public catalogue and it is not a public blockchain. It is a private accountability record connecting source, permission, access, use, and transaction history.

02 / The data passport

One package, its whole story attached.

Data passportsynthetic · illustrative
package_idBND-DR-00014
sourceVerified institutional reservoir
version3.2
permitted_useEvaluation only
buyerVerified legal entity
authorised_reviewers3
delivered18 September 2026
licence_expiry18 September 2027
settlementCompleted
lifecycle_statusActive

Illustrative passport using synthetic values. No real package, supplier, or buyer is shown.

03 / Visibility

Controlled visibility, not public exposure.

Not every participant needs to see everything.

  • Suppliers control what may be inspected and disclosed.
  • Buyers receive only the material, samples, and metadata approved for their review.
  • bnd accesses only what is necessary for discovery, qualification, administration, and the agreed transaction.
  • Raw archives do not become publicly browseable inventory.
  • Buyer research secrets are not added to public-facing records.
  • Transaction records are visible only to authorised parties and bnd personnel with a legitimate need.
  • Legal or regulatory disclosure may still be required where applicable.
04 / Permitted use

“AI use” is not one permission.

Permission for evaluation is not permission for model training. Permission for one model, environment, or purpose is not automatically permission for another. Each transaction must distinguish between:

  • inspection
  • evaluation
  • benchmarking
  • retrieval or grounding
  • supervised fine-tuning
  • post-training
  • pretraining
  • agent development
  • safety testing
  • internal research
  • production deployment

Before a package moves, the record should state:

  • the intended use
  • the relevant model, system, or programme where appropriate
  • whether use is experimental or production
  • whether copies may be created
  • whether outputs or derivatives may be retained
  • whether onward transfer is allowed
  • what expiry or revocation means in practice
  • whether deletion, return, or model-unlearning obligations are technically available and contractually required

bnd will not promise retroactive model unlearning unless the buyer's technology supports it and the obligation is explicitly agreed.

05 / Incidents and disputes

When something goes wrong, the record matters most.

This is the intended incident and dispute process for transactions. It is part of the first-transaction operating standard being prepared, not a description of past events.

  1. Suspend access where appropriate.
  2. Preserve relevant audit evidence.
  3. Identify the affected package, people, and systems.
  4. Notify the relevant supplier and buyer.
  5. Contain and investigate the event.
  6. Determine contractual, technical, and regulatory obligations.
  7. Document remediation.
  8. Record deletion, credential rotation, restoration, or closure.
  9. Retain the minimum evidence needed to demonstrate what occurred.

Not every incident can be reversed, and bnd does not promise otherwise. What it commits to is that the response is recorded.

Report security concerns to khaled@bnd.one.

06 / The contractual chain

Technology records the movement. Agreements define the authority.

Depending on the deal, transaction documentation may include:

  • confidentiality terms
  • supplier representations
  • evidence of authority
  • data description and exclusions
  • licence scope
  • purpose limitations
  • prohibited uses
  • privacy and security responsibilities
  • controller and processor roles
  • international-transfer provisions
  • subcontractor or processor terms
  • retention and deletion
  • incident notification
  • audit and verification rights
  • commercial terms
  • dispute, suspension, and termination procedures

Whether bnd, a supplier, and a buyer act as controllers, joint controllers, independent controllers, or processors depends on the specific activity and agreement. The role must be determined for each transaction rather than assumed across the entire rail.

Related reading: Responsible Data Principles, Security, and Current State.