Skip to main content

Zero Lock-In Audit (Milestone / Release)

1. Universal Architecture Checks

Memory and Data Ownership

  • Durable owner value still lives in Your Memory, not in provider-specific systems (D43, D135).
  • Data written by the system remains inspectable with standard tools (D138).
  • Export/import of owner data remains feasible without lossy conversion.
  • No hidden metadata or proprietary format is required to understand owner data.

Boundaries and Contracts

  • Component boundaries remain contract-driven — Gateway API, Model API, Gateway-Agent Loop contract (D64, D137).
  • No new dependency on another component's internals has been introduced (Principle 3).
  • Framework/library choices remain internal implementation details (Principle 2).

Configuration and Swappability

  • Provider/model/tool choices remain runtime configuration concerns, not hardcoded decisions (D147).
  • Adapters remain thin translation layers, not policy/logic hubs (D139).
  • Swap cost remains localized (adapter/config), not cross-component rewrites.

Deployment and Network Posture

  • Local owner-controlled deployment path remains valid (D148).
  • Offline operation path remains valid with local model and local tools (D148).
  • Default bind posture remains localhost-only unless explicitly configured otherwise (D148).
  • No automatic discovery, port-forwarding, or silent outbound network behavior was added.

Security and Change Safety

  • No secrets were introduced into source-controlled files or owner memory content.
  • Auth data and policies remain portable with owner-controlled export path.
  • Update flow preserves existing owner data and remains reversible in failure scenarios.

2. Component-Specific Checks

Run the sections that match changed areas.

Agent Loop

  • Agent Loop remains generic — no product-specific behavior in core loop (D39).
  • Agent Loop behavior continues to emerge from memory content + tools + config (D40).
  • Agent Loop remains provider-agnostic behind Model API adapters (D139).
  • Tool execution path remains protocol-agnostic in the architecture — MCP default is allowed, not mandatory (D32, D53).

Gateway

  • Gateway remains client-agnostic and content-agnostic in the architecture (D57, D58).
  • Conversation lifecycle stays in Gateway without coupling Gateway to Agent Loop internals (D58).
  • Gateway-Agent Loop interaction remains within the internal contract scope (D137).

Auth

  • Auth remains a cross-cutting layer independent of Gateway/Agent Loop implementation internals (D60).
  • Permission model changes remain additive and backward-compatible where practical.
  • Auth implementation choices do not create a single inescapable identity-provider dependency.

Your Memory Tooling

  • Storage/tool abstractions remain stable if storage backend changes — tools define the contract, not the storage (D135).
  • Memory organization conventions remain transparent and owner-readable (D43).
  • Version/history behavior remains portable and inspectable.

Clients

  • Clients remain thin against Gateway API — no server-coupled business logic introduced client-side (D57).
  • Client changes do not require server architecture changes unless contract/versioned intentionally.

Models and Provider Integration

  • Model choice remains configuration-driven (D63, D147).
  • Provider-specific request/stream/tool-call details remain adapter concerns (D139).
  • Fallback routing strategy remains possible via config/adapters.

Tools

  • Tools remain independently addable/removable without core code changes (D51).
  • Tool discovery remains source-driven and self-description based (D146).
  • Non-default tool protocols, if used, remain isolated behind clear adapter/execution boundaries (D32).

3. API and Interface Checks

Gateway API

  • Gateway API remains based on open, documented conventions (D16).
  • Adapter layer can absorb external API shape changes without core component rewrites (D139).

Model API

  • Model API remains stable for Agent Loop-side usage.
  • Provider-specific quirks remain outside Agent Loop core.

Gateway-Agent Loop Contract

  • Internal contract remains explicit and versioned as needed (D137).
  • New fields/behavior are backward-compatible or version-gated.
  • Interface remains internal — not promoted into a third public API by accident (D137).

4. D147 Anti-Lock-In Verification

Run this for milestone/release and for major adapter/config changes.

Provider Swap

  • Run baseline scenario with Provider A.
  • Switch provider adapter/config to Provider B.
  • Re-run same scenario.
  • Verify no cross-component code edits were required.

Model Swap

  • Change model selection in config/preferences only.
  • Re-run same scenario.
  • Verify no code edits were required.

Tool Swap

  • Add a tool through configured tool source(s) and verify usage.
  • Remove a tool and verify graceful capability reduction.
  • Verify no core code edits were required.

Audit Verdict

  • Swaps stayed localized (config/adapters/tools) with no architecture drift.
  • Any exception is documented with owner-approved rationale and follow-up plan.

5. Evidence Capture

  • Link test run IDs / logs for provider/model/tool swap checks.
  • Link network verification evidence (offline run and no-unexpected-egress check).
  • Link export/import or inspectability evidence for memory/auth data.
  • Link release/update safety notes where storage/schema/auth changed.

Quick Reference: The Swappability Chain

Everything in the architecture has an intermediary that absorbs change (D139):

ThingSwappable viaSwap cost
Your Memory storageToolsZero — tools absorb it
ComponentsContractsOne component swap
ContractsAdaptersOne adapter swap

If you're auditing something and can't identify which intermediary protects it, something is missing.