Six controls between intake and deliverable.
Most cross-border professional work involves sensitive counterparties, documents and amounts. ExpertDesk is structured so identifiers stay in Singapore, sources are mapped explicitly, and no deliverable releases until the review gate is satisfied.
- 01Singapore-first intake
- 02Controlled reviewer access
- 03Cross-border transfer review
Identifiers stay in Singapore. Review happens on tokens.
We treat sensitive data as a layer to manage, not as something to remove from the workflow. The principles below describe how the platform handles it end to end.
- 01
Singapore-first intake
Matter intake, redaction and orchestration run through a Singapore-resident server. Sensitive identifiers are mapped to anonymous markers before any cross-border review.
- 02
Controlled reviewer access
Reviewers see redacted briefs scoped to the matter they are assigned. Restoration to originals is gated behind two-person approval and is audit-logged.
- 03
Document redaction
Uploaded documents are parsed and segmented; entities, amounts, IDs and identifying narrative are tokenised before they leave Singapore.
- 04
Source mapping
Outputs link back to the underlying clauses, statutes, registry records or document excerpts they rely on, so any answer can be traced to its source.
Structural controls, not editorial promises.
Each control below is a real piece of the matter runtime — visible in the portal, enforced in the API, recorded in the workspace audit trail. The artefact tag on each card names where you can see it in your portal.
- 01Portal · matter card · Route badge
Route label
Every matter is classified into one of three routes — Matter Check, Desk Review or Expert Review — before paid work begins. The classification is visible on the matter card, and changes through review are logged.
- 02Portal · matter detail · Source Map panel
Source map
Outputs cite the source layer they rely on: current matter facts, official source candidates, secondary source leads, internal rule or PageIndex structure. Customers never see raw source IDs — only labels and status.
- 03Portal · matter detail · Missing Facts list
Missing facts
If a matter is missing facts that would change the legal or commercial conclusion, the reviewer surfaces them as open questions rather than guessing. The customer sees the prompt and the reason it matters.
- 04Portal · matter detail · Review Gate · Human review row
Human review trigger
High-risk topics — PRC tax, labour, data, foreign exchange, export controls — default to a required human review state. The deliverable is held until a qualified reviewer confirms or declines.
- 05Portal · matter detail · Matter progress timeline
Matter log
Each stage transition (intake → matter check → review → deliverable → follow-up) is recorded with a timestamp and human-readable label. The same log drives both the customer timeline and the workspace audit trail.
- 06Portal · matter detail · Review Gate · English output row
Boundary notice
When an output would change substantive legal or tax meaning — for example a translated clause that no longer matches the Chinese original — the deliverable is annotated so the customer knows what changed and why.
No deliverable is released until five gate rows clear.
Privacy, copyright, source check, human review and English output — each row has a status. While any required row is amber or red, the customer view shows the matter as held pending review, not as ready.
Deliverable is held until every row is satisfied.
- Privacypass
- pass
- Anonymised on intake (SG-resident).
- Copyrightpass
- pass
- No third-party verbatim reproduction.
- Source checkcandidate found
- candidate found
- Official source candidates identified; pending professional review.
- Human reviewrequired
- required
- PRC tax route — reviewer assignment pending.
- English outputpending
- pending
- Drafting in EN; substance-change check not yet run.
Five source layers, one label policy.
Outputs cite the layer (current matter facts, official source candidates, secondary leads, internal rule, PageIndex structure) and its status. The internal IDs, rule numbers, PageIndex nodes and reviewer notes that drive the routing never appear in customer view.
Customer sees the source layer and status. Not the source ID.
| Source layer | Status | Customer-visible label |
|---|---|---|
| Current matter facts File identifiers and the mapping that turns names back into tokens stay on the Singapore server. | available | Contract clauses you uploaded (anonymised). |
| Official source candidates The candidate-to-rule binding matrix is reviewer-only until the source is verified. | candidate found | PRC tax authority candidates identified for cross-border WHT. |
| Secondary source leads Used as a research lead; never the sole basis for a customer-facing conclusion. | available | Counsel articles consulted for issue framing only. |
| Internal rule Internal rule numbering, triggers and reviewer notes stay in the workspace audit trail. | available | Substance — applied for issue map (no rule numbers shown). |
| PageIndex structure Section pointers and page ranges are kept for reviewer use; long source text is never reproduced. | available | Reference chapter located for cross-border framework guide. |
What you write vs. what reviewers see.
A live example of how identifiers are tokenised before any cross-border review.
Shenzhen ABC Co., Ltd. proposes to acquire 60% of PT XYZ in Indonesia for USD 5,000,000.
[Company A] proposes to acquire [Pct]% of [Company B] in Indonesia for [Amount].
Want the legal detail? See our privacy policy and terms.
Start a matter→