01 / SOURCE CONNECTIONS
Connect and review every source
A single source directory shows connection state, owner choice, permission requests and selective data access.
BLACKMORE / BRIDGE APP / 2026
BRIDGE APP · USER EXPERIENCEBridge app workflows: choose, authorize, review, release, and retain evidence
The BTG Bridge app is the participant-facing interface for controlled source connections. Its screens are organized around explicit decisions—what is connected, who can use it, for what purpose, where information is going and what has actually been recorded. The four public screen groups are illustrative designs, not a statement that all integrations already operate.
PRODUCT PRESENTATION · CONCEPT UI, NOT LIVE INTEGRATIONSBRIDGE APPCONTROL CONNECTIONS. CONTROL PERMISSIONS.BTG BRIDGE
FOUR CONNECTED PRODUCT EXPERIENCES
The Bridge app, in detail.
Unlike the Exchange app, the BTG Bridge app focuses on source connections, explicit consent, destination rules and traceable handoffs. These four screens are concept presentations showing the intended experience—not screenshots of live integrations or transaction records.
02 / PERMISSION & HANDOFF
Authorize precisely and review before release
The permission workflow defines purpose, data scope, duration, intended destination and required evidence before proceeding.
03 / EVIDENCE & TRACEABILITY
Carry consent and provenance forward
The evidence-ledger design shows records, signed authority status, chain-of-custody fields and exportable references; figures are illustrative.
04 / DESTINATION CONTROL
Keep destination rules visible
Source profiles include allowed uses, retention and destination rules, with blocked or reviewed destinations distinct from permitted ones.
INTERFACE PREVIEWS: Illustrative people, providers, activity counts and approval states demonstrate the application design; they do not represent live customer records or transactions.
BRIDGE APPLICATION
Section 01 / 05
Source directory: understand what is connected
A meaningful source directory groups connections by controlling account or organization and shows the source type, identity, connection method, permission state and most recent verified activity. Connected, awaiting approval, paused, expired and failed should be distinct conditions. A visual “connected” badge cannot imply commercial authorization or verified legal title.
For an industrial manufacturer, a local machinery telemetry source and a separate employee-information store should not collapse into one general access grant. The operator chooses the allowed records; ineligible or unrelated content stays disconnected.
Section 02 / 05
Permission review: one purpose at a time
Before release, the app should present the exact requested access: records, destination, purpose, time period, export or computation rights, transformations, onward sharing and applicable restrictions. An approving participant should see meaningful changes to a previous permission rather than receiving silent increases in scope.
The rights basis may come from a documented licence or organizational decision rather than an individual checkbox. For public or collectively governed records, additional authority can be mandatory and the interface should show why approval is pending or refused.
Section 03 / 05
Handoff review: what crosses the boundary
At the handoff stage, the operator should know whether the recipient gets a full permitted file, a minimized subset, a content-addressed source reference or only the result of a remote computation. A final review identifies the recipient, expected output, sensitivity classification and required evidence before transmission. The system should preserve separate transport acknowledgement and independent quality review.
A signed receipt records the grant reference, source version, delivery time and accepted destination. The app must not suggest that a transport acknowledgement represents ownership, a research certificate or financial settlement.
Section 04 / 05
Evidence and aftercare
A usable history shows the exact authorized operation, its state, applicable policy, source version, time and resulting reference. The participant needs a way to inspect previous permissions, note errors, cancel future access and see which already-completed obligations remain under the governing agreement.
Where the next system is NIKI or a FarmNode, access must be constrained to the approved research mandate and technical sandbox. Where the destination is Bit Trade Global, eligibility for commercialization is reviewed separately through ENTITY, relevant contracts and independent technical evidence.
Section 05 / 05
What the concept visuals do not prove
The images communicate the desired quality and information architecture, including source selection, permission controls, evidence records and destination rules. The example source names, activity counts and approval states are illustrative. They should not be mistaken for verified third-party connections, live customer records, actual crypto-chain proofs or a completed controlled handoff.
A production-ready app would need end-to-end tests of connector identity, restricted grants, expiry, revocation, offline behaviour, data minimization, encryption, event signatures and unauthorized access prevention. Production acceptance depends on the documented outcomes of these end-to-end tests.
What the records must establish
Facts that belong in the supporting evidence
| Connections | Source owner, identity, health and scope |
|---|---|
| Consent | Purpose, data fields, period, jurisdiction and authority |
| Delivery | Explicit recipient, material released, outcome and restrictions |
| Evidence | Source fingerprint, policy, receipt and history |
| Review | Expiry, cancellation, disputes and blocked permissions |