Local vs managed voice AI: map your data boundaries

TL;DR: Choose local or managed voice AI by tracing every copy of audio, transcripts, tool payloads, recordings, and logs through processing, storage, and deletion. Local inference gives you more operational control only over the components you operate; a managed service's data guarantees must come from its current documented contract and your verified configuration.

A voice assistant can run its language model on a laptop while sending recognition audio to a remote service. Another assistant can use a managed model without retaining full recordings, yet send sensitive tool arguments to a poorly protected customer application.

The useful question is where each datum goes and who can access it. NIST's Privacy Framework treats privacy as an enterprise risk-management problem; a deployment label alone does not describe a complete processing boundary.

As of November 9, 2026, this guide compares architecture responsibilities rather than certifying a product's privacy, residency, or legal compliance. Pair the boundary map with the voice transport comparison, since a carrier, relay, or gateway may remain remote even when inference is local.

Contents

1. Define what local means
2. Inventory every data object
3. Draw processing and storage boundaries
4. Compare operational ownership
5. Verify managed service claims
6. Protect tools and telemetry
7. Test local operation and failure
8. Design deletion and migration
9. Frequently asked questions
10. Choose a boundary you can verify

Define what local means

Local inference describes where one computation runs. It does not, by itself, describe microphone capture, speech recognition, synthesis, storage, tool access, updates, or support telemetry.

Write a precise sentence for each proposed architecture. A fully device-local voice loop would capture audio, recognize speech, generate a response, and produce playback audio within the approved device boundary using the installed components.

That sentence still leaves business tools open. Looking up an order or creating an appointment can require a network request even when every speech and model component runs locally.

A self-hosted service describes another boundary. You may operate it in your cloud account, yet its machines, managed disks, monitoring, and network controls remain part of a cloud environment with their own administrators and contracts.

An on-premises deployment can likewise send crash reports or remote backups outside the building. Treat each path as an explicit design choice rather than relying on the physical location of the inference server.

Separate inference location from product mode

A runtime can support local and remote model modes. Ollama's current FAQ distinguishes local processing from cloud features and documents a way to disable cloud features; the selected mode and configuration determine the relevant boundary.

That is a useful example of why a product name is insufficient evidence. You need the actual endpoint, model mode, configuration, and observed network behavior for the workload being evaluated.

Do not infer the behavior of other components from that one runtime. A local language model says nothing about the speech recognizer, text-to-speech engine, vector search, crash reporter, or browser analytics installed beside it.

The same rule applies to managed voice platforms. A provider may operate several surfaces with different data handling, and a statement about one API should not be transferred to call recordings or post-call evaluation without checking scope.

Make the decision task-specific

A voice interface for offline equipment control has different constraints from a telephone appointment agent. The offline tool may need reliable operation without a network, while the telephone agent already depends on external routing and a live scheduling system.

Define the actual task, authorized data classes, expected concurrency, languages, and failure policy. Then compare architectures against those requirements using the outcome metric contract.

A local system that fails the task under realistic hardware load does not satisfy the requirement merely because it keeps inference nearby. A managed system that completes the task while crossing an unapproved processing boundary also fails the requirement.

Keep both acceptance criteria visible. You need correct task behavior and an approved data path, with evidence for each rather than a single combined score that lets one compensate for the other.

Inventory every data object

Start with the smallest set of objects that explains the task. Audio, transcript, model context, tool payload, recording, operational telemetry, and outcome evidence usually deserve separate rows.

For each object, record where it originates, which components receive it, whether it is transformed, where it is retained, and how it is deleted. Distinguish transient processing from durable storage even when they occur in the same service.

A transcript can contain a name, a phone number, or an account issue without a structured field announcing that it is sensitive. A tool payload can expose the same facts through a compact argument object that receives less review than the recording.

Do not assume derived data is harmless. Summaries, embeddings, sentiment labels, and error messages can preserve identifying details or reveal the subject of a conversation.

The table is a proposed inventory aid. It makes no universal claim about which providers retain which data, because those answers depend on the selected service, configuration, and contract.

Follow transformations and copies

Audio can become a partial transcript, a final transcript, a summary, and a quality label. Each derivative may be stored in a different system with a different access policy.

A recording may also be downloaded by a reviewer or attached to a support ticket. Those copies do not disappear automatically when the original call record is deleted.

Assign a stable internal object relationship so deletion and investigation can find derivatives without storing the same sensitive content everywhere. Restrict that relationship because a convenient join key can become a way to reconstruct a person's activity across systems.

The complete call trace guide recommends connecting observations through identifiers. In a boundary review, those identifiers need a retention and access rule too, even if they do not contain a person's name.

Record purpose before retention duration

Retention should follow a defined purpose. Debugging a failed media path, reconciling a booking, training a reviewer, and meeting a business record requirement can require different objects and different access.

Avoid one broad rule such as keeping everything for quality. It is difficult to test and encourages every new exporter or downstream reviewer to receive full content.

Instead, name the object and the purpose in the configuration record. A protected short-lived diagnostic sample can coexist with longer-lived aggregate outcomes without making the full recording available to every dashboard user.

A retention number is useful only with its scope. A documented tool-event-log limit does not establish the retention period for recordings, transcripts, provider logs, backups, or files downloaded by your own team.

Draw processing and storage boundaries

A data boundary is a point where processing authority, access, or retention responsibility changes. Draw boundaries around the device, your application services, the voice provider, the carrier, business tools, and the telemetry system as needed.

Label each edge with the data type and purpose. An arrow called API hides too much; an arrow called confirmed booking fields tells a reviewer what crosses the boundary and why.

Then mark which components can see plaintext. Transport encryption protects a link, while the endpoints may decrypt and process content; those are different facts that should remain visible in the diagram.

flowchart LR
    subgraph D[Caller device]
        M[Microphone and playback]
        L[Optional local inference]
    end
    subgraph A[Application boundary]
        O[Session orchestration]
        T[Authorized tool gateway]
    end
    subgraph P[Managed processing boundary]
        V[Speech and model services]
        R[Optional retained call data]
    end
    B[Business system]
    E[Approved telemetry store]
    M -->|Audio if managed route| O
    M -->|Audio if local route| L
    L -->|Permitted task request| T
    O -->|Audio and context| V
    V -->|Retention if enabled| R
    V -->|Tool proposal| T
    T -->|Minimal authorized fields| B
    O -->|Redacted timing events| E
    B -->|Verified outcome| O

This diagram compares possible routes; it is not a representation of 60db Agent internals. Remove unused boxes and replace each remaining arrow with the actual documented service contract for your deployment.

Separate media encryption from end-to-end confidentiality

A browser WebRTC session has media protection requirements defined by the WebRTC transport specification. A gateway that terminates that media can still access audio for recognition, recording, or forwarding.

Likewise, TLS on a WebSocket connection protects traffic between endpoints without preventing the receiving service from processing content. A SIP route may have different signaling and media protection, so verify each hop instead of borrowing a browser security claim.

The SIP troubleshooting guide examines signaling and media independently. That distinction helps a security review too, because protecting session setup does not automatically protect the separate audio path.

Describe the guarantee precisely. If a service decrypts audio to run speech processing, do not describe the whole conversation as opaque to that service unless the selected architecture supplies and documents such a guarantee.

Include control and support paths

A data-flow diagram often omits the dashboard, support access, and export jobs. Those paths can expose retained content even when the live media route is tightly controlled.

Ask who can open a recording, who can export transcripts, and whether support access is logged and restricted. Include administrative identity and workspace membership in the review rather than focusing only on model endpoints.

A local deployment has analogous paths. A remote desktop session, shared filesystem, broad log permissions, or a backup agent can expose the same content without any cloud inference request.

Map routine administration and incident response before granting broad access during an outage. Emergency access should have a recorded purpose and a reviewable scope, with cleanup after the incident.

Include post-call processing

The live call may end before recording assembly, summarization, outcome reconciliation, or evaluation. Those jobs can introduce additional providers and retention even after the caller's microphone is closed.

The shutdown semantics guide separates live media shutdown from authorized post-call work. Use the same separation in the boundary map so reviewers know which data remains active after hangup.

If post-call evaluation uses another model provider, record that provider as a separate recipient. Approval for the live voice path does not automatically approve every later content-processing service.

A useful handoff is another data path. The warm handoff guide helps define which confirmed facts reach a human and which sensitive details should stay out of a spoken summary.

Compare operational ownership

Local operation transfers responsibility to your team for the components you run. You need a way to install, patch, monitor, back up, and recover them, with enough hardware capacity for the real workload.

Managed operation transfers some infrastructure work to a provider. Your team still owns application authorization, task policy, application behavior, caller experience, and the data you send to tools or export to your own systems.

Use a responsibility table with named owners. The word shared is incomplete unless it explains which party detects a failure, which party can repair it, and what evidence the other party receives.

Do not assume managed means no operations. Your application can still create duplicate writes, retain excessive logs, or fail to close a call even when the provider infrastructure is healthy.

Compare cost using the same outcome

Local hardware cost should include the capacity required for expected concurrency, headroom, maintenance, and failure recovery. A device that handles one short demo does not establish a production capacity plan.

Managed cost should include usage, telephony, retries, tools, recordings, exports, and operational effort where relevant. Use current invoices or dated prices instead of treating a single per-minute figure as the whole service cost.

The cost-per-success guide provides a common denominator. Compare cost per verified task at the required reliability and boundary constraints, and retain the assumptions that make the two architectures comparable.

Do not invent a break-even volume. It depends on hardware utilization, workload, staffing, model choice, route, and the failure behavior you are willing to operate.

Compare failure ownership before performance

A local microphone assistant can continue during an internet outage only if its required components and task dependencies are available locally. A remote scheduling tool can still prevent completion even when recognition and generation remain healthy.

A managed service can fail through provider availability, network reachability, capacity limits, or application mistakes. Your fallback should distinguish those conditions because repeating the same request may increase load or duplicate an uncertain action.

State what the caller experiences. A visible offline state, an approved human handoff, or a restricted read-only mode can be more useful than repeated apologetic speech with no path to completion.

The workflow enforcement guide keeps those fallbacks within authorization. Failure recovery is not permission to bypass a required confirmation or send data to an unapproved provider.

Verify managed service claims

Start with the current product documentation and the agreement that applies to your account. Marketing language can identify questions, but it cannot fill gaps about recipients, retention, regions, access, or deletion.

Distinguish a documented feature from an enabled workspace capability. An API can exist publicly while access remains gated, and a successful call in one environment does not establish availability or configuration in another.

The 60db Agent documentation describes workspace ownership, recordings and transcripts, browser testing, and call lifecycle behavior. Access can be gated by workspace enablement; verify the route and configuration you intend to use rather than assuming general availability.

This article makes no claim that 60db Agent is locally deployable, has a particular residency guarantee, avoids third-party processing, or carries a compliance certification. Those claims require explicit public or contractual evidence for the selected deployment.

Ask questions that can be answered precisely

For audio, ask which services process live samples and whether recordings are optional. For transcripts, ask whether partial and final text are retained, whether content is used for any purpose beyond the requested service, and which settings change that behavior.

For operations, ask where support personnel can access content and how access is logged. For deletion, ask what the delete operation covers, what remains in backups, and what completion evidence is available.

Keep unanswered questions in the decision record. Unknown does not automatically mean a service is unsuitable, but it prevents you from claiming a guarantee that nobody has established.

Use a requirement-by-evidence table. Each row should contain the needed behavior, the exact source or contractual clause, the applicable product surface, and a test or review result where the behavior is observable.

Verify API boundaries without copying secrets

Read actual request and response contracts before building a proof of concept. Keep persistent credentials on trusted systems, use the documented permission scope, and avoid logging authorization headers or signed webhook secrets.

The 60db tools and webhooks documentation describes signed requests and call events. Signature verification establishes the documented request's authenticity; your backend still decides whether the proposed action is authorized for the task.

Use synthetic task data for qualification. You can verify event delivery, deletion behavior, and object ownership without importing real customer records or recording a real person's conversation.

Capture the test date and relevant configuration. Documentation and service behavior can change, so a boundary qualification should identify what was checked rather than presenting itself as a permanent guarantee.

Read retention statements at their exact scope

A log-specific retention period is not a blanket data-retention policy. For example, 60db documents a limit for tool-event logs, which must not be extended to recordings, transcripts, all events, or data retained by another provider.

Ask about each object in your inventory. If a duration is not documented, record it as a question for the provider or the applicable agreement instead of substituting a nearby number.

A no-training statement is also narrower than a no-processing or no-retention statement. The Ollama cloud documentation separately describes cloud processing and training policy, illustrating why those questions should have separate rows.

Keep that distinction in procurement and technical review. Otherwise a sentence about model training can accidentally become a promise about logs, support access, or every downstream recipient.

Conceptual: Keep training use, object retention, and processing recipients as separate questions.

Protect tools and telemetry

The tool gateway is a data and authority boundary. A voice model can propose an action, while the application verifies identity, scope, confirmation, and the minimum fields needed by the business system.

Local inference does not remove prompt injection or excessive tool authority. OWASP's LLM application guidance covers risks such as prompt injection and excessive agency; the relevant defense is application enforcement at the action boundary.

Use an allowlist of supported operations and validate arguments against the current business rules. A request to retrieve an appointment should not become a broad customer export because the model supplied a different tool name or a larger query.

The speculative tool guide adds another boundary: early read work should remain distinct from committed writes. An interrupted utterance must not create a business record just because the application wanted a faster response.

Minimize fields before sending

Give each recipient only the fields needed for its purpose. A scheduling tool may need a time and a service identifier without requiring the full conversation history.

Prefer a bounded structured result to a raw business record. If the agent needs to know whether a slot is available, return that fact rather than an unrestricted object containing internal notes or unrelated customer details.

Validate tool results too. Error pages, debug traces, and overly broad responses can leak into model context and later appear in spoken output or telemetry.

The outcome metrics guide recommends business evidence without duplicating full records. That same principle keeps the evaluation path smaller and makes deletion easier to reason about.

Keep content out of routine telemetry

Operational questions often require timing, error class, queue age, and response state rather than full text. Define a safe telemetry schema before adding exporters, and review which attributes a library captures automatically.

OpenTelemetry's sensitive-data guidance describes techniques for minimizing and filtering sensitive telemetry. Filter close to the source where possible, because exporting first and redacting later still sends the original content across a boundary.

Use protected samples for investigations that need content, with approved access and retention. Keep those samples separate from routine dashboards so a broad metrics role does not become permission to read conversations.

Test the redaction path with synthetic markers. Put distinctive fake identifiers in a consented fixture and inspect the intended log and export destinations for those markers, recording which paths were checked.

Protect local interfaces

A model endpoint bound to a local interface still needs an access review. Other processes, browser-origin behavior, container networking, or a later configuration change can alter who reaches it.

Inspect listening addresses and firewall rules for the actual deployment. Avoid exposing a local inference endpoint on a broad network merely to make a demo easier, especially when the endpoint has access to conversation context or tools.

Separate inference access from business authority. Even if an unauthorized process can submit text to a model, it should not gain permission to execute a tool write through the agent's service identity.

Use least-privilege service accounts and isolate credentials from model-visible context. A local prompt is still untrusted input, and a secret placed in that prompt can become an output or a log entry.

Test local operation and failure

A credible local claim needs a defined test boundary. Install the required models and assets, identify permitted network dependencies, and run the actual task while observing network behavior under controlled conditions.

A network-disconnected test can show that the tested workload continued without that connection. It does not prove the software never makes network requests in other modes, update paths, or failure conditions.

Combine behavior with configuration and documentation review. Record which cloud features were disabled, which endpoints remained reachable, and which model or voice assets were already present.

Use the regression harness to keep the workload fixed. Run speech input, response playback, interruption, slow tool behavior, and shutdown rather than stopping after a text prompt returns an answer.

Define an executable boundary inventory

The following vendor-neutral self-check uses synthetic endpoint declarations. It verifies that every declared processor has an approved boundary and that a device-only mode contains no remote processor; it cannot discover undeclared network traffic.

processors = [
    {"name": "recognition", "boundary": "device"},
    {"name": "generation", "boundary": "device"},
    {"name": "speech", "boundary": "device"},
]
approved = {"device"}
assert processors
assert all(p["boundary"] in approved for p in processors)
assert all(p["boundary"] == "device" for p in processors)

remote = {"name": "reviewer", "boundary": "external"}
assert remote["boundary"] not in approved

Save the snippet and run it with Python 3. The assertions illustrate a configuration invariant, while packet observation, runtime inspection, and provider contracts remain necessary to verify the deployed system.

Do not mistake a passing assertion for a privacy certification. The value is that adding a remote reviewer becomes a visible configuration decision rather than an accidental exception buried inside a post-call job.

Measure hardware under the real workload

Record device model, processor, available memory, accelerator, operating system, runtime version, and the exact model and voice assets. Keep the same task fixtures when comparing machines.

Test sustained sessions and expected concurrency. Warm-up behavior, memory pressure, thermal limits, and other applications can change the result after the first successful response.

Measure speech end to audible playback using the latency protocol. Tokens per second and synthesis first-byte timing describe components; neither establishes the caller's full response delay.

Keep resource observations separate from performance promises. A result on one machine and model configuration cannot establish that all supported hardware will meet the same delay or task-success target.

Exercise interruption and endpointing

Local processing can still cut callers off or continue speaking after interruption. The interruption state machine and turn detection guide define behavioral tests that apply regardless of where inference runs.

Include background speech, thinking pauses, short acknowledgments, and a caller restarting a sentence. Track false cutoffs and stale playback alongside delay so optimizing one number does not hide a worse conversation.

Use the same consented audio fixtures across local and managed candidates where their input contracts allow it. Record any conversion or transport difference that prevents a strict comparison.

For multilingual tasks, use the language-specific evaluation protocol. A model's language list or a local speech demo does not establish correct recognition of names, numbers, and final business actions.

Test failure without widening boundaries

Disconnect a permitted dependency and observe the result. A local voice loop should follow its declared offline behavior, while a remote tool failure should produce an honest unresolved state rather than an invented success.

Test whether the application silently switches to a cloud model or alternate telemetry endpoint. Such a fallback may be valid when explicitly approved, but it changes the boundary and needs its own evidence.

Also test storage exhaustion and process restart using synthetic data in a controlled environment. The system should preserve required durable action state while avoiding accidental retention of temporary audio fragments or repeated writes.

These tests are bounded qualification steps, not a reason to build a new control platform. Reuse existing network observation, logging, and regression tools, adding only the checks needed to establish the chosen architecture's claims.

Conceptual: An outage does not authorize a new processing recipient; qualify any fallback boundary explicitly.

Design deletion and migration

Deletion begins with the object inventory. Identify the primary call record, recording, transcript, tool-event logs, exported copies, quality labels, and backups that can contain related data.

A delete endpoint may cover only some objects. Read its documented scope, verify the response and subsequent access behavior with synthetic data, and ask the provider about objects that cannot be inspected directly.

A successful API response is one observation. Your acceptance test should also check the visible object state and downstream destinations you control, while acknowledging any contract-based guarantees that cannot be measured from outside the service.

Distinguish deletion from access revocation

Revoking an API key stops future access under that credential according to its contract. It does not necessarily erase stored objects, end every running call, or delete previously exported files.

Likewise, deleting a dashboard record may remove a reference while another system retains a downloaded recording. Keep access revocation, live-session stop, and data deletion as separate operations with separate verification.

The 60db Agent documentation describes a recording and transcript deletion route and workspace ownership. Verify its current exact scope before automating it, and do not extend that route into an undocumented promise about every log, backup, or third-party system.

Use the post-call lifecycle contract to ensure a delayed job cannot recreate content after deletion. A system should know whether an object remains eligible for post-call export or analysis.

Verify migration as a data operation

Moving between local and managed architectures changes more than inference. You may move prompt state, voice configuration, tool credentials, evaluation datasets, and operational records.

Create a migration inventory and decide what must move, what can be regenerated, and what should be deleted. Use synthetic records for the first migration rehearsal and keep production credentials out of exported configuration bundles.

Re-run the task and boundary evaluation after migration. A new recognizer, codec, or output engine can change names, timing, interruption behavior, and caller understanding even when the script text remains identical.

Preserve a rollback path that does not require uncontrolled copying of sensitive data. If fallback routes cross different boundaries, approve and test those routes before an incident makes the choice urgent.

Keep a small evidence packet

The decision packet should contain the data inventory, route diagram, responsibility table, applicable documentation or agreement references, configuration snapshot, and qualification results. Use redacted identifiers and retain the private details only where authorized operators need them.

Record unresolved questions and who owns the answer. A dated unknown is more useful than a broad privacy statement that quietly assumes an answer.

Review the packet after a meaningful architecture change: a new tool recipient, a different speech provider, a new telemetry exporter, a retention change, or an added post-call evaluator. Cosmetic application changes do not require rewriting the entire boundary analysis.

For 60db Agent, begin with currently documented workspace capabilities and a synthetic test call on an enabled route. Request missing contractual details directly, then decide whether the verified boundary meets your task's requirements.

Conceptual: Combine inventory, configuration, observed behavior, and open questions without treating a local self-check as certification.

Frequently asked questions

Does local voice AI mean no data leaves the device?

Only when every required processing and export path stays inside the approved device boundary. A local language model can still use remote recognition, synthesis, tools, telemetry, updates, or post-call evaluation, so verify the complete workload.

Is self-hosted the same as on-device?

No. Self-hosted describes who operates the service, while on-device describes its location relative to the user; a self-hosted cloud service can still process audio remotely and depend on cloud storage and administration.

Is managed voice AI always less private?

There is no universal ranking from the deployment label. Compare actual recipients, access controls, retention, deletion, and operational evidence against your requirements, including the copies and credentials your own application manages.

What should go into a data inventory?

List audio, partial and final transcripts, model context, tool requests and results, recordings, telemetry, summaries, and outcome evidence. For each, identify processing recipients, storage owners, purpose, retention, access, and deletion behavior.

Does encryption in transit prevent provider access?

It protects the connection between its endpoints. A service that decrypts audio or text for processing can access that content according to its architecture, so describe each plaintext processing boundary separately.

Can a local model still make unsafe tool calls?

Yes. Model location does not establish business authorization, and untrusted input can still influence proposed actions; enforce identity, scope, argument validation, and required confirmation in the application-owned tool gateway.

What is the difference between no training and no retention?

No training describes one use of data. Retention concerns storage duration, while processing concerns recipients and purpose; verify each separately rather than treating one statement as proof of the others.

How can I test an offline claim?

Install required assets, document permitted dependencies, and run the actual voice workload under controlled network restrictions while observing behavior. Combine that test with configuration and documentation review because one successful offline session does not cover every mode or update path.

Is a local endpoint safe because it uses localhost?

Local binding narrows reachability but does not replace an access review. Inspect listeners, container networking, permissions, and credential access, and keep the inference interface separate from authority to execute business writes.

Do I need full recordings for evaluation?

Only when the evaluation purpose requires audio and the recording policy permits it. Many operational questions can use timing and state, while pronunciation or interruption review may need protected audio samples with explicit access and retention.

Are transcripts harmless after names are removed?

No. Free text can retain addresses, account details, unusual events, and combinations that identify a person; minimize content and review derived summaries and labels as part of the same data inventory.

Does deleting a call delete every copy?

Only if the documented operation and your downstream cleanup cover those copies. Verify recordings, transcripts, exports, evaluation datasets, and backups separately, retaining clear ownership for anything outside the primary service.

Does revoking a credential end running calls?

That depends on the documented service contract. Treat credential revocation, live-session termination, and retained-data deletion as separate actions and verify each behavior with approved synthetic tests.

What hardware should I buy for local voice AI?

Size hardware from a measured workload with the intended models, languages, concurrency, and delay budget. Record sustained behavior and recovery headroom rather than selecting a device from a single text-generation benchmark or a short demo.

How should I compare local and managed cost?

Use cost per verified task at the required reliability and approved data boundary. Include hardware utilization, operations, usage, telephony, retries, tools, and failure recovery where relevant, using dated prices or observed invoices.

Can fallback change the privacy boundary?

Yes. Switching to another provider, region, or post-call evaluator creates a different processing path; approve and test that route explicitly instead of allowing an outage handler to widen access silently.

What should I ask a managed provider first?

Ask which services process each object, what is retained, who can access content, how deletion works, and which configuration changes those answers. Match every answer to the exact product surface and agreement that applies to your account.

Is 60db Agent locally deployable?

This guide establishes no local-deployment capability for 60db Agent. Evaluate its documented managed surfaces and request explicit evidence for any deployment, residency, retention, or compliance requirement before making a production decision.

Can I assume inbound calling is available?

No. Public documentation describes routes with workspace and environment gates, so qualify the selected route in your workspace; a browser or outbound test does not establish general public inbound availability.

What should trigger a boundary review?

Review meaningful changes to recipients, tools, storage, telemetry, retention, or post-call processing. Recheck task behavior after transport or model changes, and retain dated evidence so the new architecture can be compared with the previous approved boundary.

Choose a boundary you can verify

Choose the architecture whose data path and operational responsibilities meet the task. Your evidence should explain where content is processed, where copies remain, who can access them, and how the system behaves when a dependency fails.

Start with a small inventory and one route diagram. Run a synthetic workload, inspect the permitted exports, verify deletion within its documented scope, and measure task success on the hardware or managed route you intend to operate.

For 60db Agent, use enabled public capabilities and current contracts as the starting point. Keep unverified guarantees open, collect the missing evidence, and make the deployment decision from the boundary you can show.