Who this manual is for
Authorized operators, governance reviewers, rights holders and institutional stakeholders. 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 — Understand an approval request
Review the action, affected object or right, requesting party, purpose, expiry, expected effect and the authority claimed.
02 — Approve or reject a protected change
Only in an authorized production interface, confirm that the underlying evidence and legal mandate are valid. Refuse unclear, expired or overbroad requests.
03 — Review an action record
Check the event identifier, initiator role, state before and after, decision outcome and any separate external confirmation required.
04 — Investigate a denied action
Use the reason category to identify a missing permission, invalid version, expired mandate or inconsistent evidence. Correct the legitimate cause rather than bypassing policy.
05 — Reconcile an interrupted workflow
Verify the last trusted state, distinguish pending from completed actions and compare any separate institution or payment acknowledgements.
06 — Escalate a dispute
Preserve the signed or authoritative references and request review from the competent rights holder or governing body, not only the software operator.
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.
Review request
Identify target, requested transition, requester, purpose and claimed authority.
Check state
Compare current and proposed state with active grant, scope and expiry.
Decide
Approve, deny or route for human adjudication, keeping reasons intelligible.
Audit event
Inspect record ID, time, decision class and evidence under least privilege.
Investigate interruption
Separate committed operations from pending requests; never double-execute external effects.
Escalate dispute
Preserve relevant signed references and seek the competent authority, not an interface override.
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
- Receive a proposed protected change and its target
- Identify requester, source of authority, scope and expiry
- Evaluate current state and applicable policy
- Approve, deny or defer without leaking sensitive rules
- Record signed or verifiable decision context
- Verify resulting state and handle exceptions or replay within approved scope
Problem and recovery guide
| What you notice | What to do |
|---|---|
| Unsigned or expired grant | Deny the change; re-enroll authorized principals if required. |
| State conflict | Stop before mutation; reconcile source-of-truth and version. |
| External side-effect uncertain | Do not replay payments or rights transfers blindly; reconcile separately. |
| Policy disagreement | Escalate to competent human governance without bypassing controls. |
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
- Production owner authority chain and grant revocation
- State transition receipts with time and actor
- Idempotency / duplicate side-effect safeguards
- Negative and conflict test results
- Cross-host evaluation when distributed
- Governance change-control and escalation rules