Latest verified engineering — 25 October 2026
Targeted Bridge signed gateway tests passed 13/13 locally; the full 169-test integration suite still had one missing original process-peer module. Bridge must bind ENTITY, correct device consent, data permissions, scoped service grants and exchange use receipts across actual applications.
Oct 25 full engineering record · Contribution/use economy · Council qualification
Executive overview
BTG Bridge is the participant-controlled data connection and permission layer. It can connect approved information sources to governed work, but a connected source is not automatically a tradable asset, ownership transfer or investment. The purpose is to make participation and authorized use understandable and accountable.
01 — Why Bridge exists
A person or organization may hold useful information across devices, software, repositories or records. Bridge is designed to allow specific, consented participation without making every underlying record available to the Exchange or to an unknown buyer.
Bridge’s job is permissioned intake and evidence of approved use. ENTITY addresses authority and rights, NIKI and FarmNodes perform authorized research, BTDU retains qualified knowledge, and the Exchange deals with distinct, lawful rights-defined instruments.
02 — The four separate decisions
Connection establishes an authenticated relationship to a source. Permission authorizes a named purpose and scope. Transfer or computation permits information to move or be processed only under those conditions. Commercialization requires additional enforceable rights.
Treating those four decisions as one checkbox would undermine the design. The interface must give the source owner a comprehensible explanation of what is being sought, by whom, for how long and for what benefit or risk.
03 — Permission details to inspect
The participant should be able to examine source category, selected fields, purpose, recipient, geographic controls, retention period, permitted processing, onward sharing, expiry and withdrawal rules. Consent should be recorded as a scoped decision, not inferred from merely installing an app.
Special care is needed for shared workplace data, minors, clinical information, third-party identities and material subject to confidentiality agreements. Possessing a copy of information is not proof of authority to authorize its resale.
04 — From raw source to permitted result
A permitted research operation may transform, aggregate or analyze approved inputs and return a limited result. The raw information can remain with a source custodian when the authorized process permits compute-to-data rather than copying entire datasets.
A useful discovery could become the subject of a separate asset-qualification record. It still requires checks for privacy leakage, scientific validity, source restrictions, ownership, derivative rights and valid contracts before any commercial or investment proposal.
05 — Source categories and compatibility
Potential sources include individual devices, approved applications, organization-controlled systems and permitted file or research collections. Each connector requires its own authentication, field mapping, legal permission and testing.
Not every named provider, handset or account is currently connected. An illustrated source card or demonstration does not establish that a production provider has granted access, that refresh tokens are recoverable or that deletion is supported.
06 — Revocation and retention
A participant may withdraw future access within the rules of the applicable agreement and law. A usable revocation flow needs a clear effective date, acknowledgement and what it will stop.
Withdrawal cannot literally undo a permitted transfer that has already occurred, erase a recipient’s legally required records or revoke a separately lawful entitlement. Where deletion is requested, the outcome must distinguish completed deletion, pending propagation and legitimate retention exceptions.
07 — Security and identity
Bridge is intended to use authenticated source relationships, precise scope checks, encrypted records, verifiable decision history and separation of participant accounts. These safeguards require production testing against cross-account leakage, key recovery and real provider behavior.
Never enter credentials into an unfamiliar page, approve a broader scope than necessary or share raw access tokens with any market participant. Access to an app is not evidence that a private key or underlying record is safe.
08 — Rights and payment boundaries
Contributing data does not automatically mean selling it. A separate agreement must address rights to process inputs, ownership of any derivative work, possible contributor benefit and how disputes would be resolved.
Bridge is not a bank, an exchange wallet or a guarantee that activity will produce monetary returns. A participant may opt into permitted research without any investment or data-product listing occurring.
09 — Institutional adoption
An organization should examine lawful basis, roles of controller and processor, data residency, incident handling, consent evidence, record minimization, retention, connector validation and audit access.
Third-party security claims should be identified by auditor, dates, scope and exclusions. Local encryption tests are useful engineering evidence but do not independently certify an entire consumer service.
10 — Development status and safe expectations
Public BTG evidence describes local permission and encrypted-core demonstrations. Real multi-user consumer identity, independently assessed isolation, provider-approved connector deployment and operational recovery must still be evaluated.
The manual describes the intended accountable participant experience, not a promise that all screens, connectors and controls are available for production use today.
Related manuals and use
The companion User & Operator Manual describes the decisions and reviews applicable to this system. References to proposed user flows are explicitly conditional on qualification of the relevant product release.
Expanded system explanation
| Question | Clear answer |
|---|---|
| Audience and purpose | BTG Bridge is described for the public, institutional evaluators and prospective partners; this is not a software implementation reference. |
| What exists | A consent and permissions gateway between approved personal or organizational data sources and separately authorized research, without automatic resale or investment rights. |
| Analogy | A supervised doorway: permission to enter one room for a stated purpose is not permission to copy the entire building or sell its contents. |
| Authority | The described process requires actual contracts, human authority and technical qualification at every relevant boundary. |
Practical examples — what a reader should infer
Everyday example
A person consents to a one-time analysis of selected shopping comparisons. Bridge should state whether only aggregated results leave the private area. The Exchange cannot automatically sell those comparisons.
Refusal example
A provider denies a requested field or the source includes someone else’s private communications. Bridge should refuse or restrict the transfer; being able to read the record does not grant commercial rights.
Revocation example
The participant cancels future permission. The system records the request and stops future authorized collection, while explaining any legally retained previously delivered material.
System lifecycle — each separate decision
- Identify a source and person or organization with authority
- Explain recipient, data categories, purpose, territory and retention
- Obtain specific permission; refuse by default outside scope
- Minimize, protect and record any authorized transfer
- Enable a record of what was accessed and the terms
- Process withdrawal, correction and exceptional lawful retention
People, organizations and responsible roles
- Individual participant controls eligible choices
- Source provider imposes its own applicable terms and technical permissions
- Recipient is accountable for permitted use and retention
- Privacy lead reviews risk, complaints and breaches
- ENTITY and ADAM can reference rights and policy, but not invent permission
Where the system can fail
- App account access and commercial permission are not the same.
- Sensitive or third-party information may need exclusion even after consent.
- Withdrawal cannot always erase past permitted transmissions.
- Production provider connectors, independent tenant isolation and real-account enrollment remain to be qualified.
Evidence a serious evaluator would require
These are acceptance requirements, not claims that each artifact has been issued or independently certified:
- User-facing consent notice, granularity and revocation record
- Source authority and platform terms
- Real connector compatibility test by version
- Data-flow map, minimization, retention and deletion handling
- Independent privacy and security assessment
- Incident-response and affected-user notification procedures
Terms explained in ordinary language
| Term | Meaning |
|---|---|
| Consent | Informed, purpose-specific permission where applicable law requires it. |
| Scope | The exact information and actions covered by permission. |
| Revocation | Withdrawal of future authority, subject to law and prior lawful activity. |
| Derived result | An output from permitted processing; rights and disclosure limits still apply. |
How to read the current status accurately
The architecture and local engineering records are distinct from production operation. A named component or test figure cannot establish authorized commercial rights, fully qualified infrastructure or independently accepted financial activity. Read the dated corporate evidence register for each claimed version; ask for a scoped, access-controlled evidence bundle for decisions that rely on private implementation.
Corporate system information → Engineering evidence and limitations → Publications → ENTITY (the separately published open component) →
AI Creation Council and FarmNode research — audited update
The council must not treat data gathered through Bridge as free-to-send model input. A free public AI endpoint may retain or train on submitted data. No personal, provider-restricted, confidential, child or unapproved research input may be transmitted to hosted council models.
Read the complete AI Council research guide → · Public operator manual → · Printable evidence report →
UPDATED AUDIT · 23 OCT 2026 · 18:26 UTC
Latest Council and FarmNode qualification evidence
The completed 18:26 UTC audit reports 114/114 local tests in nine suites, including the earlier 70 tests (not 184 independent results). The 34 physical-host security tests qualify policy/refusal contracts only, not three real computers. Four explicitly approved hosted routes were zero-priced at the 18:17 UTC catalogue snapshot; no authenticated hosted inference comparison was completed.
Public hosted models may collect input prompts; no Bridge personal, confidential or otherwise restricted data is allowed into third-party council prompts without authorized separate approval.
Full Council qualification report → · Download qualification PDF → · Three sector evaluator packs → · Download evaluation PDF →