Who this manual is for
Knowledge custodians, researchers, records managers, rights holders and institutional reviewers. Readers should first understand the product scope and respect the fact that roles, contracts, source permissions and approvals cannot be created by a mere software screen.
Before starting
- Use only an official, current and authorized release.
- Identify which organization or account is responsible for the action.
- Review the permissions, data classification, allowed scope and supporting rights.
- Verify current product availability and the limits of published evidence.
- Do not disclose passwords, access tokens, financial details, sensitive source records or confidential algorithms.
01 — Find an authorized knowledge record
Start with the record identifier or topic and confirm source, version, owner or custodian and purpose of the available view.
02 — Interpret a semantic view
Check whether you are seeing a summary, derived analysis, raw authorized record or released public evidence. Do not substitute a view for the primary data when exact reconstruction matters.
03 — Request a permitted export
Confirm the legal and technical permission, allowed fields, recipient and retention terms. Use only the approved release method.
04 — Verify reconstructed material
Where released for inspection, compare the version and published digest with the reconstructed artifact, and confirm the test scope.
05 — Report conflicting versions
Preserve both identifiers, observed differences, source references and the date; do not overwrite historical evidence in response to a disputed interpretation.
06 — Review a commercial description
Distinguish the knowledge asset from the licence or security describing its lawful economic use.
Understanding statuses and results
Proposed: a design or candidate, not an accepted product or offering. Qualified: supported by named evidence within a stated test scope. Authorized: a competent rights holder, organization or regulator has given the particular approval required. Completed: the independently defined outcome has actually occurred, including any external settlement or delivery where applicable.
Common questions
Does the public document grant access?
No. Publishing a description or a manual does not give readers access to private software, underlying data or investments.
Does a test pass establish production readiness?
No. Tests must be interpreted by version and scope; actual production readiness requires the applicable operational, legal and security qualifications.
Who decides data or investment rights?
The legally competent rights holder, issuer, contracting parties and applicable authorities—not a software identifier or automation alone.
Support and issue records
Record the date, relevant public identifier, product version if known, symptom or question, steps observed and the minimum permitted evidence. Report through BTG’s official contact page. Avoid attaching unrelated confidential or personal records.
Detailed workflow and decision record
This is a task and review manual for a planned or specifically authorized deployment. Screen names, buttons, account permissions and automatic outcomes must be checked against the actual tested product version; where the UI has not been verified, instructions are deliberately expressed as actions, not invented clicks.
Find record
Locate identifier, custodian, version, allowed view and scope.
Interpret semantic index
Read the meaning and source of a tag rather than treating a keyword as underlying truth.
Request reconstruction
Confirm purpose, audience and permission before retrieving authoritative payload.
Verify results
Compare a permitted output with expected hash/byte-count/version proof.
Resolve discrepancy
Report mismatched payload, changed version or restricted-field exposure.
Publish limited description
Remove protected contents while retaining accurate non-sensitive metadata.
Before operating — acceptance checklist
- Identify the actual operating version and service owner.
- Confirm your role and explicit authority for this data, research or financial action.
- Read the purpose, risks, permitted scope and available evidence before taking action.
- Know which support and incident-reporting channel applies and how to stop safely.
- Make no release, resale, rights-transfer or investment decision on a proposed record alone.
Expected workflow
- Register the lawful authoritative payload and its version
- Record atomized reference structures and content evidence
- Attach indexes, metadata and governed semantic relationships
- Allow only permitted views for each user/purpose
- Reconstruct original bytes and compare integrity evidence
- Retain version history, provenance and exceptions
Problem and recovery guide
| What you notice | What to do |
|---|---|
| Hash mismatch | Stop acceptance; compare frozen version and reconstruct with controlled input. |
| Unexpected sensitive fields | Revoke access pending privacy and authorization review. |
| Contradictory semantic view | Trace the index and source version; do not rewrite the original silently. |
| Claim of superior model capacity | Require controlled baseline, hardware, quality and cost evidence before asserting it. |
What the operator should record
- Date, timezone, role and intended action.
- Public object identifier and version, never a secret or private credential.
- The authority, permission or review reference in appropriately protected storage.
- Expected outcome versus observed result, including negative and failed cases.
- Whether action is proposed, internally qualified, externally authorized or actually completed.
- Escalation destination and final decision, if any.
What this manual does not promise
Not every capability described here is available to a public account or installed in a consumer application. Real operation depends on qualified builds, actual provider permissions, formally delegated roles and sometimes legal authorization. Do not infer an available menu, released feature, verified rights entitlement or active securities market from a conceptual workflow.
Documents to request before relying on a result
- Frozen source and provenance receipts
- Exact-byte reconstruction fixtures and negative tests
- Versioned semantic dictionary and permission rules
- Independent performance benchmark methodology
- Retention, deletion and correction pathways
- Security assessment of view isolation
Corporate system information → Engineering evidence and limitations → Publications → ENTITY (the separately published open component) →
AI Creation Council and FarmNode research — audited update
Original ADAM/BTDU memory now retains identified council model responses, critiques and changed-version history as untrusted research. Hash-correct reconstruction supports reproducibility but does not establish that an algorithm is original, useful or legally owned.
Read the complete AI Council research guide → · Public operator manual → · Printable evidence report →