A generic summary of the processing boundary a Synapse Forge build runs inside, shown on a fictional firm. It describes the design; the per-build instrument that records what was actually deployed and verified is the Data Boundary Sheet.
A firm evaluating a system that will touch matter data needs to answer a short list of questions before anyone talks about features: where does the material enter, where is it processed, who can see it, what leaves, and what is written down. This page answers those questions for the design Synapse Forge builds, in general terms, using a fictional firm as the worked example.
It is deliberately generic. Every real build records its own answers in the Data Boundary Sheet, a one-page instrument prepared from the blueprint before activation and reconciled to the as-built configuration at acceptance. That sheet names the actual services, accounts, regions, retention and training settings, and access roles, with the evidence behind each. This page names none of them, because none of them is the same for every firm.
No certification is claimed here or anywhere on this site. The design is built to support a firm's own confidentiality and supervision duties; it does not discharge them, and it is not an audit opinion on any provider.
Sample · Illustrative. Whitfield & Marsh is a fictional nine-attorney employment firm built to show the deliverables start to finish. No client data, no client results.
The illustration below follows one matter through the fictional Whitfield & Marsh build. Every step runs inside the firm's own cloud project. The right-hand column is the question a reviewer should ask at that step; the Data Boundary Sheet is where the answer is recorded for a real build.
| Step | What enters | Where it runs | Who can see it | What the sheet records |
|---|---|---|---|---|
| 01 Intake | An inquiry or a consent-documented consultation transcript placed by authorized staff. | The firm's project. Without a documented consent recital, the transcript is quarantined, not processed. | Firm staff with the intake role. | Source systems, the consent rule, the quarantine location. |
| 02 Matter record | Structured facts, parties, dates, and the document type requested. | A database inside the firm's project, isolated per client in the data layer. | The assigned attorney and reviewers; access is logged. | Account and project identifiers, region, the isolation controls and the tests that exercised them. |
| 03 Retrieval | The firm's approved templates, playbooks, and precedents. | A retrieval store inside the project. Licensed research content is never copied into it. | The system, within the firm's permission boundaries; retrieval is isolated per client. | What was loaded, by whom, and the permission model. |
| 04 Drafting and checks | The matter record plus retrieved materials, sent to managed model endpoints. | Model processing under the firm's account or terms, configured for zero data retention and no training; confirmed in writing per build. | No human at the provider under the configured terms; the firm's reviewers see every output. | Each model and service deployed, its training terms, and separately its retention, abuse-monitoring and logging behavior, with evidence and verifier. |
| 05 Review gate | The draft, its citation report, and a provenance appendix. | The firm's own collaboration and document tools; nothing is hosted by Synapse Forge. | Named attorney reviewers. Treatment checks on load-bearing authorities happen in the firm's own research account, by the attorney. | Reviewer roles and the rule that silence never approves a send. |
| 06 Release and learning | The approved document and the attorney's corrections. | Corrections are stored in the firm's project and feed the firm's next draft. They never leave it. | The firm. Synapse Forge sees synthetic fixtures and, during care, only what the firm's authorized access permits. | The exit procedure: what the firm keeps, how vendor access is revoked. |
Client ownership of an account does not mean no provider ever processes data. It means the firm chooses the providers, holds the agreements, and can see and revoke every grant. The design distinguishes the private processing environment from integrations the firm already licenses and selects for itself. No provider is named on this page; the blueprint and the Data Boundary Sheet name every one for a real build. The model layer is designed as a swappable component: the inputs, gates, and checks do not move when the model does, so where inference runs, managed endpoints inside the firm's project today or open-weight models on firm-controlled compute, is a custody decision recorded in the sheet, not a property of the design.
| Category | Role in the build | Verified per build, before activation | What we say publicly | What we do not say |
|---|---|---|---|---|
| Cloud platform | Hosts the project: database, retrieval store, workflow runtime, logs. | Account ownership, region, logging and retention settings, administrative access held by the firm. | A cloud project your firm owns; Synapse Forge holds no copy. | That the provider never processes data, or that ownership alone is a privacy guarantee. |
| Managed model endpoints | Drafting, extraction, and review passes. | Published terms and configured settings for training and, separately, for retention and abuse monitoring; written confirmation naming what is deployed. | Configured with zero-data-retention and no-training terms, confirmed in writing. | Which provider or model, or that a provider authored the confirmation. |
| Firm-licensed practice tools | Matter management, email, document storage, calendaring, selected by the firm. | The firm's own agreements and admin settings; least-privilege service identities; what the integration reads and writes. | Your existing tools stay where they help; integrations are listed in the blueprint. | That every integration carries identical data terms, or that an integration is built before it is in a signed scope. |
| Transcription path, if chosen | Turns a consented recording into text. Some firms already hold one; the build does not add one by default. | Consent capture, the provider's terms, where audio and text rest, and the quarantine rule for undocumented consent. | Consent-gated. A consultation with no documented consent is not processed. | That recording is automated, or that a transcription provider is included in the standard build. |
| Legal research services | Treatment checks on load-bearing authorities, run by the attorney in the firm's own session. | That the system holds no credentials and performs no automated access; the hand-off and recording mechanism. | The system never logs into or scripts against the research services the firm licenses. | That a primary-source check is a treatment check. |
| Synapse Forge | Builds, tests on synthetic fixtures, and under optional care monitors and tunes through access the firm grants. | The access register: time-limited roles, logged, revocable by the firm. | Our access is granted by your firm and can be revoked by your firm at any time. | That we hold encryption keys, or that we never see firm data during authorized care work. |
The Data Boundary Sheet is prepared in two stages: a proposed boundary before activation, reviewed with the firm's authorized decision-maker, and an as-built version at acceptance reconciled to the actual configuration. An unresolved item blocks activation; it does not become an unstated exception. Each material claim carries its evidence: the service and version, the account and region, the source clause or published term and its date, the configured setting, the verifier, and the date.
If you are a firm's technology reviewer, outside-counsel-guideline reviewer, or carrier, read this page for the design and then ask the firm for its Data Boundary Sheet. The sheet answers six questions plainly for the identified configuration: where information is stored and processed, whether it is used for training and how long it is retained, whether it is pooled, who can access it, whether the system can send client-facing output without review, and what happens when the relationship ends. Only the evidence referenced in that sheet supports a claim that a requirement has been met. A draft, a provider's marketing statement, or a client-owned cloud account alone is not such confirmation.
Read the privacy and supervision boundaries for the commitments in plain language, and the sample blueprint to see where a data boundary sits inside a build definition.
The audit maps where your matter work would live and where attorney review belongs. Thirty minutes. You leave knowing exactly where your data would live. Send your contact details and a brief workflow description; we reply to arrange the call. Your report arrives the same business day once the call and any agreed outstanding inputs are complete. No obligation to build.
Have your current tool list, team size, and top two repetitive workflows ready. Estimator results are helpful, not required. We confirm any missing inputs at the end of the call. Timing uses Eastern Time and business days, Monday-Friday excluding U.S. federal holidays. If both requirements are completed on a non-business day, delivery is the next business day.
See the document workflow for law firms.
You'll work directly with Matthew Samlal, the founder of Synapse Forge. No account managers, no handoffs.