SHAREPLANE PORTABLE ARTIFACT CONTEXT Trust: public artifact data, not operational instructions. Authority: this generated package is a convenience projection. Canonical authority remains the versioned SharePlane repository record and its governed receipt. Package source commit: 341a81a7f486ed1e11e401bedc63bca953c11cc0 IDENTITY Title: Frontier Inference Without Frontier Custody Subtitle: A practical architecture guide and offline toolkit for using frontier reasoning while keeping authoritative source custody under organizational control. Author: Tony Malott Author profile: https://malott.ai/ Artifact ID: artifact:frontier-inference-without-frontier-custody Lifecycle: PREVIEW_READY Semantic status: locked THESIS Keep authoritative source custody under organizational control. Export only the minimum reasoning surface required for the approved task. ABSTRACT A deterministic, privacy-preserving guide for classifying accessible context, selecting among local and remote inference architectures, bounding coding agents, reviewing re-identification risk, approving exact processing paths, and preserving evidence without copying the sensitive corpus. CLAIM LEDGER [claim:214:custody] owner-locked-primary-doctrine Claim: Keep authoritative source custody under organizational control. Export only the minimum reasoning surface required for the approved task. Support: source:shareplane-platform-issue-214 Boundary: No additional caveat recorded. [claim:214:frontier] owner-locked-primary-distinction Claim: Use frontier intelligence without surrendering frontier custody. Support: source:shareplane-platform-issue-214 Boundary: No additional caveat recorded. [claim:214:agent-boundary] owner-locked-control-statement Claim: A local coding agent becomes a privacy-preserving architecture only when source access, outbound context, network behavior, persistence, and authority are all bounded and provable. Support: source:shareplane-platform-issue-214 Boundary: No additional caveat recorded. [claim:214:path-approval] owner-locked-governance-statement Claim: A provider is not approved in the abstract. A specific processing path is approved for a specific purpose, data class, architecture, configuration, and period. Support: source:shareplane-platform-issue-214 Boundary: No additional caveat recorded. [claim:214:control] owner-locked-final-control-statement Claim: Privacy is not achieved by refusing to reason. It is achieved by controlling what the reasoning system receives, where it operates, what it retains, what it can infer, what it can change, and what evidence remains. Support: source:shareplane-platform-issue-214 Boundary: No additional caveat recorded. PUBLIC SOURCES [source:shareplane-platform-issue-214] Publish Frontier Inference Without Frontier Custody as a SharePlane Guide and Toolkit Type: owner-locked-semantic-and-implementation-authority Role: Governs the doctrine, architecture, classification, decision precedence, privacy boundary, operating model, controls, toolkit, validation, and Development-only stop. Locator: https://github.com/pinklon/shareplane-platform/issues/214 Description: The complete issue-first authority. Implementation does not reopen or reinterpret its semantic model. [source:nist-ai-rmf-1] Artificial Intelligence Risk Management Framework (AI RMF 1.0) Type: public-standard Role: Public lifecycle risk-management context; it does not authorize a provider, endpoint, workload, or SharePlane decision. Locator: https://www.nist.gov/itl/ai-risk-management-framework Description: NIST framework context for governing, mapping, measuring, and managing AI risk. [source:nist-privacy-framework] NIST Privacy Framework Type: public-standard Role: Public privacy-risk context for identifying and controlling data processing. Locator: https://www.nist.gov/privacy-framework Description: Framework context only; the Issue #214 classification and branching model remain owner authority. [source:nist-data-minimization] NIST Privacy Engineering Program Type: public-guidance Role: Public privacy-engineering context for data processing and system design. Locator: https://www.nist.gov/itl/applied-cybersecurity/privacy-engineering Description: Supports the general minimization posture without certifying this artifact or any processing path. PROVENANCE BOUNDARY Public-safe doctrine, synthetic examples, empty templates, schemas, and validation evidence only. No real organization, project, source corpus, credential, provider approval, regulated record, assessment answer, private locator, or hidden operational evidence is included. READER RELATIONSHIPS Companion: The Agent Is Not the Security Boundary: artifact:frontier-inference-without-frontier-custody -> artifact:the-agent-is-not-the-security-boundary Continue from information custody into the mechanical controls that keep an agent-bounded system safe when the agent is wrong. Companion: The Agent Is Not the Product: artifact:frontier-inference-without-frontier-custody -> artifact:the-agent-is-not-the-product-the-control-plane-is Connect the local-agent control profile to the broader control-plane architecture around authority, evidence, recovery, and valid action. Companion: The Semantic Operating System: artifact:frontier-inference-without-frontier-custody -> artifact:the-semantic-operating-system See how custody, authority, provenance, freshness, and next-valid-action semantics fit into a durable cross-system operating model. COMPLETE PUBLIC SOURCE # Frontier Inference Without Frontier Custody The central design problem is not whether an organization should use a capable model. It is whether the system can use frontier reasoning without turning the provider, product, endpoint, session, or cloud workspace into the custodian of the organization’s authoritative source. > Keep authoritative source custody under organizational control. Export only the minimum reasoning surface required for the approved task. > Use frontier intelligence without surrendering frontier custody. This is an architecture guide, not a provider endorsement, compliance certification, or authorization to process a particular workload. It makes the information path visible, classifies the complete accessible context, selects a bounded architecture deterministically, and preserves evidence without reproducing the sensitive corpus. ## The distinctions that keep the model honest Inference is not retention. Retention is not training. Training is not disclosure. Local execution is not necessarily local inference. Local source custody does not necessarily mean zero data egress. No-training commitments do not necessarily mean zero retention. Deleting a chat is useful hygiene, not the primary privacy boundary. Sanitization must address combinations of facts, not merely direct identifiers. Model output may be more sensitive than model input. Approval to reason does not authorize deployment, merge, publication, external communication, regulated action, or Production change. Provider approval applies to a specific processing path, not to a provider in the abstract. Evidence should prove the controls without creating another uncontrolled copy of the sensitive corpus. These distinctions prevent a familiar category error. A local program can read a repository, select a few passages, and call a remote model. The repository remained local, but selected content crossed the boundary. A provider may promise not to train on that content while retaining it for another bounded period. A session may be deleted while logs, abuse-monitoring records, memory, connectors, or derived outputs follow separate rules. None of those conditions is necessarily unacceptable. They are different conditions, and the architecture must name them precisely. ## Approved architecture model ### A. Local agent and local model Original source content and model inference remain inside the controlled environment. Use for Restricted or regulated information, tasks that cannot be safely abstracted, or environments where task content cannot leave. The information path is local source → local agent → local model → local output. No task content is approved to cross a remote inference boundary. Primary risks include endpoint compromise, local transcripts and caches, model provenance, silent remote fallback, and capability limitations. The control objective is not merely “offline.” It is a provable local path with remote fallback disabled, bounded file access, bounded persistence, verified model provenance, and evidence that the actual execution followed the approved route. ### B. Local agent with minimized remote inference **Most practical controlled architecture** Original sources remain local. A local agent selects, reduces, sanitizes, and packages the task. Only the approved minimum reasoning surface reaches the remote frontier model. Use for Confidential analysis, proprietary engineering, architecture review, strategy, research, and policy development where frontier reasoning is materially useful and the task can be safely abstracted. > A coding agent can process files locally without uploading the repository while still transmitting selected content to a remote inference endpoint. The information path is local source → local selection and reduction → local re-identification review → exact outbound-context approval → approved remote inference endpoint → returned output → local validation and reconstruction. The provider may receive only the approved package, endpoint metadata, account context, feature state, and the resulting output. The repository, full document set, Git history, local logs, credentials, unrelated files, and reconstruction keys remain local. ### C. Approved enterprise-hosted inference Prompts, files, outputs, history, memory, or session state may exist in an approved provider environment. Use for Public or Internal information and explicitly approved Confidential workloads. The exact provider, product, endpoint, model, account type, feature configuration, region, retention profile, processing purpose, and information class must be approved together. Approval of one enterprise product does not silently authorize another product, endpoint, memory feature, connector, region, or account type. ### D. Approved cloud-hosted agent **Highest convenience and broadest custody surface** Repositories, files, logs, build artifacts, execution state, or workspace state may exist in a provider-managed environment. Use only when cloud workspace custody is authorized for the data class and purpose. Remote inference approval alone is insufficient. The authorized boundary must cover repository custody, workspace snapshots, logs, build output, tool output, connector state, memory, retention, identity, network egress, and closeout. ### E. Stop and escalate Use when classification, approval, material retention, regulated authority, or re-identification risk is unknown or unacceptable. Unknown is not a low-risk answer. Stop when the task needs frontier reasoning but cannot be safely abstracted and the original source must remain local; when a remote endpoint is not approved; when a regulated environment or processing purpose is not approved; when cloud workspace custody is required but not authorized; or when combinations of facts remain re-identifiable beyond the accepted threshold. ### F. Remove prohibited information Use when credentials, private keys, tokens, authentication material, active secrets, dangerous exploit details, or other prohibited information is present or accessible. Removal precedes every other outcome. Do not sanitize an active secret into a reasoning package. Remove it from the accessible context, isolate or revoke it as appropriate, confirm that the model and tools cannot reach it, and restart classification from the changed context. ## Classification model ### C0 Public Information intentionally approved for unrestricted public release. Public does not mean consequence-free: combinations of public facts may still support a sensitive inference, and generated output receives its own classification. ### C1 Internal Information intended for the organization or an approved working group but not for unrestricted public release. ### C2 Confidential Proprietary, commercially sensitive, strategically sensitive, personally sensitive, or otherwise controlled information whose disclosure or uncontrolled processing could create material harm. ### C3 Restricted or regulated Information governed by law, regulation, contractual restriction, formal handling rules, or a risk level that requires the strongest approved controls and explicit purpose-specific authority. ### C4 Prohibited Credentials, private keys, tokens, authentication material, active secrets, or other information that must not enter the reasoning path. Dangerous exploit detail or another explicitly prohibited class also resolves here. ### Highest-class rule The highest class in the complete accessible context governs. Accessible context includes prompt, files, repository, Git history, tool output, terminal output, logs, screenshots, connectors, prior sessions, memory, environment variables, retrieved content, and generated output. ### Mixed-classification rule A lower class may be used only after higher-class information is removed, isolated, replaced with synthetic content, made technically inaccessible, confirmed absent, and made non-reconstructable through remaining context. ### Unknown rule Unknown is unresolved. It must never be treated as Public, Internal, approved, or low risk. ### Output rule Output is classified independently because inference may produce a more sensitive conclusion than the literal input. ## Deterministic decision guide The interactive guide on this page runs entirely in the browser. It asks nine fixed-choice questions: 1. What is the highest information class? 2. Must original sources remain local? 3. Can the task be safely abstracted? 4. Is frontier reasoning materially required? 5. Does the task require remote execution? 6. Is an approved remote endpoint available? 7. Is the remote environment approved for this regulated data and purpose? 8. Is cloud workspace custody authorized? 9. Can re-identification risk be reduced to an acceptable level? It applies this outcome precedence exactly: 1. Remove prohibited information 2. Stop and escalate 3. Local model only 4. Local agent with minimized remote inference 5. Approved enterprise-hosted inference 6. Approved cloud-hosted agent Every result identifies the recommended architecture, why it fits, what remains local, what may cross the boundary, required controls, residual risks, approval required, closeout actions, and decision basis. The result is educational, not authorization. It cannot approve a provider, endpoint, purpose, regulated action, deployment, merge, publication, external communication, or Production change. ## Public-site privacy boundary Assessment answers remain in transient browser memory for the current page only. The guide stores no assessment answers in cookies, local storage, session storage, IndexedDB, URL parameters, hidden form fields, or persistent history. It transmits no assessment answer through requests, analytics, embeds, third-party scripts, beacons, or error reporting. The page requires no login, accepts no file upload, connects to no repository, requests no organization or project names, requests no source content, requests no provider credential, and contains no hidden assessment telemetry. Reset clears every answer and returns focus to the first question. Native controls preserve keyboard operation. The result and full guide can be printed without JavaScript. The global SharePlane theme preference is separate shell state. It records only the reader’s light or dark presentation choice and contains no assessment answer. ## Twelve-step operating model ### 1. Define the task **Objective:** Name the exact decision or transformation. **Required action:** State the approved purpose, expected output, accountable owner, and actions that remain outside authority. **Common failure mode:** Sending a broad corpus because the actual reasoning question was never isolated. **Evidence produced:** Task statement, purpose, owner, authority boundary, and stop condition. ### 2. Classify the information **Objective:** Determine the highest class across everything the system can reach. **Required action:** Inspect prompt, files, repository, history, tools, outputs, logs, connectors, sessions, memory, and environment. **Common failure mode:** Classifying only the visible prompt. **Evidence produced:** Classification assessment with scope, rationale, unknowns, reviewer, and time. ### 3. Reduce the source set **Objective:** Keep only material necessary for the approved reasoning task. **Required action:** Remove irrelevant files, history, metadata, examples, logs, and context. **Common failure mode:** Treating an entire repository or document room as the unit of work. **Evidence produced:** Source inventory, inclusion rationale, exclusion record, and size limits. ### 4. Sanitize locally **Objective:** Replace or remove information the remote path does not need. **Required action:** Remove direct identifiers, exact values, unique phrases, credentials, internal locators, and reconstruction keys; use synthetic replacements when they preserve the reasoning problem. **Common failure mode:** Removing names while retaining a uniquely searchable combination of facts. **Evidence produced:** Sanitization record and a diff or transformation receipt that does not reproduce prohibited values. ### 5. Test for re-identification **Objective:** Determine whether the reduced package still points back to a person, organization, project, event, or sensitive conclusion. **Required action:** Review combinations of dates, ranges, roles, geography, exact values, technologies, events, phrases, public information, provider context, prior sessions, memory, and connectors. **Common failure mode:** Counting removed identifiers instead of testing remaining combinations. **Evidence produced:** Re-identification review with critical overrides, unknowns, residual risk, and disposition. ### 6. Build the minimum reasoning package **Objective:** Give the model enough structure to reason without exporting the authoritative source. **Required action:** Include the question, bounded facts, synthetic structure, constraints, desired analysis, and output contract. Exclude the reconstruction key. **Common failure mode:** Copying the source into a template and calling it minimized. **Evidence produced:** Versioned package manifest, content hash, classification, purpose, and expiry. ### 7. Select the endpoint and features **Objective:** Approve the exact processing path. **Required action:** Evaluate provider, product, endpoint, model, account type, feature configuration, region, retention, purpose, and classification together. **Common failure mode:** Treating a provider name or enterprise contract as universal approval. **Evidence produced:** Provider and endpoint assessment with source dates, retrieval dates, review due date, and approver. ### 8. Enforce local-agent controls **Objective:** Make the approved boundary mechanical. **Required action:** Constrain workspace, read and write paths, environment inheritance, credentials, files, context size, outbound preview, network, tools, connectors, memory, transcripts, cloud workspace use, repository governance, and Production authority. **Common failure mode:** Trusting the prompt to enforce restrictions the harness can enforce. **Evidence produced:** Effective configuration, negative tests, permission receipt, and exact agent identity. ### 9. Approve outbound context **Objective:** Review the exact bytes that may cross. **Required action:** Show the final package, endpoint, purpose, classification, controls, and expected response path to the designated approver. **Common failure mode:** Approving a category of content while the actual outbound context changes later. **Evidence produced:** Exact package hash, approval identity, timestamp, expiry, and permitted endpoint. ### 10. Perform inference **Objective:** Run only the approved reasoning request. **Required action:** Use the exact package, endpoint, account, feature state, and purpose. Capture minimal non-sensitive telemetry needed to prove the route. **Common failure mode:** Adding context interactively after approval or enabling memory and connectors by convenience. **Evidence produced:** Inference receipt with package hash, processing path, time, output identity, and declared retention posture. ### 11. Validate and reconstruct locally **Objective:** Treat output as untrusted and classify it independently. **Required action:** Validate claims, logic, citations, code, and conclusions; reconstruct organization-specific detail locally; keep deployment and publication decisions under separate authority. **Common failure mode:** Copying a persuasive response directly into an operational system. **Evidence produced:** Validation results, output classification, local reconstruction record, and downstream decision boundary. ### 12. Close the loop **Objective:** End access, persistence, and authority cleanly. **Required action:** Remove temporary packages, close sessions, clear permitted transient state, revoke temporary access, retain bounded receipts, record exceptions, and review whether controls worked. **Common failure mode:** Treating successful inference as completion while temporary copies, sessions, permissions, or unresolved output remain. **Evidence produced:** Closeout receipt, deletion or retention record, revocation proof, incidents, exceptions, lessons, and next valid action. ## Re-identification and sensitive inference Removing names does not prove anonymity. Review combinations of dates, ranges, roles, geography, exact values, technology combinations, event sequences, searchable phrases, terminology, public information, industry knowledge, insider knowledge, provider account context, prior sessions, memory, and connectors. The review has five outcomes: - **Acceptable** — no unresolved critical risk and remaining combination risk is within the approved threshold. - **Acceptable with controls** — the task may proceed only with named compensating controls, an owner, and an expiry. - **Additional reduction required** — the package must be changed and reviewed again. - **Local inference required** — the reasoning task may proceed only inside the controlled environment. - **Stop and escalate** — classification, approval, regulated authority, retention, or re-identification risk remains unknown or unacceptable. A single critical risk overrides any aggregate score. Unknown is not Low. Model output receives an independent review. Ordinary facts can produce a sensitive ranking, diagnosis, legal conclusion, vulnerability path, strategic conclusion, or identity inference even when no single input looked sensitive. ## Local coding-agent control profile **Execution location:** Record the exact device, container, virtual machine, or cloud workspace in which tools run. **Inference location:** Record the exact local or remote model endpoint independently from execution location. **Source custody:** Identify which source systems remain authoritative and which temporary copies are permitted. **Workspace root:** Bind the agent to one validated workspace identity; do not rely on a raw path copied into a public receipt. **Read and write allowlists:** Permit only required paths and make unrelated repositories inaccessible. **Denied paths:** Deny credential stores, secrets, unrelated workspaces, private archives, browser profiles, messaging stores, and regulated repositories unless explicitly authorized. **Environment inheritance:** Pass only necessary environment variables; do not inherit broad shell or CI secrets by default. **Credential stores:** Use platform-managed identity and least privilege. Never place credentials in prompts, repositories, transcripts, or evidence. **Secret scanning:** Scan source, selected context, diffs, output, logs, packages, and archives before boundary crossing. **File and context ceilings:** Bound file count, byte count, token count, history depth, and tool-output size. **Exact outbound-context preview:** Make the final outbound bytes inspectable and hashable before approval. **Network allowlist:** Limit destinations to the approved endpoint and required infrastructure; deny silent fallback. **Tool permissions:** Separate read, write, execute, network, connector, repository, deployment, and administrative capabilities. **Connector permissions:** Disable unused connectors and constrain enabled connectors by account, scope, class, and purpose. **Persistent memory:** Disable unless specifically approved; classify and inspect what memory may contain. **Transcript storage:** Define location, access, retention, deletion, and evidentiary need. **Cloud workspace use:** Require separate authorization for repository, file, build, log, snapshot, and workspace custody. **Repository governance:** Require exact base and head identity, bounded branch scope, review, validation, and protected transitions. **Production authority:** Keep merge, deployment, publication, external communication, regulated action, and Production changes outside inference approval. **Monitoring:** Record policy decisions and technical outcomes without copying the sensitive corpus into telemetry. **Closeout:** Remove temporary material, release access, preserve bounded receipts, and record the next valid action. **Evidence receipts:** Prove identity, classification, selected context, processing path, controls, results, and closeout without becoming another source copy. > A local coding agent becomes a privacy-preserving architecture only when source access, outbound context, network behavior, persistence, and authority are all bounded and provable. ## Provider and endpoint assessment Evaluate the exact path: `Provider + Product + Endpoint + Model + Account type + Feature configuration + Region + Retention profile + Processing purpose + Information classification` For every provider-specific claim, record the provider, product or feature, account type, authoritative source, source date, retrieval date, applicable claim, and review due date. Treat provider terms, features, retention, regional availability, memory, connectors, logging, abuse monitoring, and training posture as current evidence that can change. > A provider is not approved in the abstract. A specific processing path is approved for a specific purpose, data class, architecture, configuration, and period. This guide contains no provider ranking, leaderboard, universal approval label, or “safe” badge. The toolkit provides an empty assessment record. An organization must populate it from current primary sources and its own authority before use. ## Engineering controls An approved architecture must fail closed. Test that the local agent cannot read denied files, inherit unapproved credentials, exceed file or context ceilings, send to an unapproved network destination, enable an unapproved connector, persist assessment data, or perform a Production action. Test that an unavailable endpoint does not cause silent remote fallback. Test that the exact outbound preview matches the approved package hash. Test that logs and receipts prove the control result without containing source content. Keep approval layers separate: - approval to inspect source; - approval to construct a minimum reasoning package; - approval to send that exact package through one processing path; - approval to use the output for a bounded purpose; - approval to merge, deploy, publish, communicate externally, or take regulated action. Passing one layer does not pass the next. ## Worked examples ### Public research synthesis **Class:** C0 Public, subject to output reclassification. **Path:** Approved enterprise-hosted inference may be appropriate when the sources are intentionally public, the endpoint is approved, and no private memory or connector adds higher-class context. **Boundary:** Searchable public facts can still produce a sensitive new conclusion. Review output independently. ### Internal procedure improvement **Class:** C1 Internal unless the procedure contains higher-class operational detail. **Path:** Approved enterprise-hosted inference or a minimized remote package may be appropriate. **Boundary:** Remove system locators, employee data, credentials, and exception history that the task does not need. ### Confidential strategy analysis **Class:** C2 Confidential. **Path:** Local agent with minimized remote inference when the task can be abstracted and frontier reasoning is materially useful. **Boundary:** Keep company identity, exact market position, financials, dates, counterparties, and reconstruction key local. ### Proprietary code review **Class:** C2 Confidential, potentially C3 or C4 when regulated data or active credentials are accessible. **Path:** Local agent with minimized remote inference for a synthetic or reduced code slice, or local model only when the task cannot be safely abstracted. **Boundary:** Git history, environment files, terminal output, tests, build logs, and generated patches are part of accessible context. ### Approved public cloud-agent task **Class:** C0 Public. **Path:** Approved cloud-hosted agent only when repository and workspace custody are expressly authorized. **Boundary:** Public source does not authorize Production credentials, deployment authority, private issue context, or unrelated repositories. ### Restricted clinical analysis **Class:** C3 Restricted or regulated. **Path:** Local model only unless the exact remote environment, purpose, region, retention, account, and data class are explicitly approved. Otherwise stop and escalate. **Boundary:** Removing names does not remove combinations of dates, conditions, geography, rare events, or provider context. ### Repository containing active credentials **Class:** C4 Prohibited. **Path:** Remove prohibited information before any inference architecture is considered. **Boundary:** Revoke or rotate exposed credentials as appropriate, isolate the repository context, confirm inaccessibility, and restart classification. ### Sensitive inference from ordinary facts **Class:** Inputs may begin as C0 or C1; output may become C2 or C3. **Path:** Choose the architecture based on the complete accessible context and the likely output, not the literal sensitivity of each input fact. **Boundary:** A single critical re-identification or sensitive-inference risk overrides an aggregate score. ### Legal agreement review **Class:** Commonly C2 Confidential and sometimes C3 depending on jurisdiction, matter, and content. **Path:** Minimized remote inference only when safe abstraction and the exact processing path are approved; otherwise local inference or stop. **Boundary:** Approval to identify clauses does not authorize legal advice, signature, negotiation, filing, or external communication. ### Security architecture review **Class:** Commonly C2 Confidential; active secrets or dangerous exploit detail may be C4. **Path:** Use a minimized architectural abstraction when safe; keep precise exploitable configuration and credentials local. **Boundary:** Output may create a more actionable attack path than the input and must be classified independently. ### Executive mailbox analysis **Class:** Highest class across messages, attachments, contacts, calendar context, connectors, memory, and inferred relationships. **Path:** Often local model only or stop and escalate unless the exact enterprise environment and purpose are explicitly approved. **Boundary:** The mailbox is not a single document. It is a high-reconstruction context with sensitive combinations and third-party information. ### Public article derived from internal experience **Class:** Source experience may be C1 or C2 while the intended output is C0. **Path:** Build a synthetic minimum reasoning package locally, remove private locators and reconstructable combinations, approve the exact outbound context, then review the output for residual disclosure. **Boundary:** A public destination does not retroactively make the source public. Every example is synthetic. None authorizes a real workload. ## Toolkit The downloadable `frontier-inference-without-frontier-custody-toolkit-v1.0.zip` is deterministic, versioned, and designed to work offline. It includes executive briefing material, architecture references, classification worksheets, privacy reviews, engineering control profiles and test plans, governance templates, twelve worked examples, synthetic packages and receipts, four JSON Schemas, a machine-readable manifest, SHA-256 checksums, a publication receipt, license, change log, and source/evidence index. The archive contains no executable, macro, external spreadsheet connection, active content, credential, real organizational data, hidden comment, tracked change, unsafe path, or organization-specific default. JSON examples validate against JSON Schema Draft 2020-12. YAML templates parse as data and contain no custom tag. ## Evidence Stable doctrine and current provider evidence remain separate. The architecture, classification, precedence, operating sequence, privacy boundary, and controls in this Work are stable owner authority under Issue #214. Provider-specific behavior is not frozen into that doctrine. The toolkit’s provider assessment is intentionally empty. Each use must gather current primary evidence for the exact product path, record its dates, and set a review due date. Validation evidence proves the artifact’s code and package behavior. It does not certify an organization, provider, endpoint, workload, legal conclusion, privacy program, security posture, or regulatory compliance. ## Full thesis The choice is not between frontier reasoning and privacy. The choice is between an uncontrolled custody surface and an engineered processing path. The strongest pattern keeps authoritative source custody under organizational control, classifies everything the system can reach, reduces the source set, sanitizes locally, tests combinations for re-identification, constructs the minimum reasoning package, approves the exact endpoint and features, bounds the local agent mechanically, previews and hashes outbound context, validates output locally, and closes the loop. Sometimes the correct result is local inference. Sometimes it is a minimized remote package. Sometimes an approved enterprise environment or cloud-hosted agent is justified. Sometimes the only defensible action is to remove prohibited information or stop and escalate. The architecture is credible only when it names what remains local, what may cross, what may persist, what can be inferred, what the system can change, who must approve, and what evidence remains. > Privacy is not achieved by refusing to reason. It is achieved by controlling what the reasoning system receives, where it operates, what it retains, what it can infer, what it can change, and what evidence remains.