No Strings Attached Is an Architecture

No supplier can remove every dependency from an enterprise system.

Software has components, licences, operators, interfaces, and upgrade paths. The useful question is whether those dependencies are visible, governed, replaceable where required, and accepted by the organization.

"No lock-in" is therefore a weak promise on its own.

It becomes credible when the architecture and delivery agreement give the client specific rights that operators can test.

This is what we mean by:

BAMS: governed enterprise AI, deployed with no strings attached.

The phrase is not a claim that the client owns every model, connector, or line of third-party software. It is a standard for infrastructure control, model choice, organizational context, software authority, evidence, operations, and exit.

BAMS governance control plane. All displayed data is simulated.

Eight Tests for No Strings Attached

The standard can be expressed through eight tests.

1. Infrastructure Control

The client can run the governed system in an environment it selects and controls under the agreed deployment model.

Infrastructure control includes more than a server location. The client needs documented procedures for deployment, configuration, monitoring, backup, recovery, update, and stop.

Test it by asking a client operator to show where the required components run, how health is inspected, how the system is stopped, and how service is recovered.

BAMS has a layered reference architecture with application, orchestration, memory, inference, storage, and security services. The commercial beta work packages those layers for repeatable client-controlled deployment.

The boundary is explicit: the internal reference deployment exists; repeatable customer appliance packaging is not yet a GA claim.

2. Model-Layer Control

The client determines which permitted model route serves each workload.

The policy can account for data classification, task type, quality, cost, availability, and provider terms. Authorized operators can inspect routes, change them, disable a provider, and see the impact.

BAMS provides provider configuration, route bindings, health, quota, budget, usage, spend, and enable or disable controls in its reference implementation. It also supports local inference paths.

Test it by showing the route for one workflow, disabling the provider, and verifying the expected fail-closed or fallback state.

This is control of the model layer. It is not ownership of third-party model intellectual property.

3. Governed Context

The client's organizational knowledge remains under its access, classification, retention, correction, and export rules.

Context is not portable if the organization receives text without the provenance and access metadata needed to interpret it. It is not governed if relevance can bypass permission.

BAMS includes memory search, long-term memory, writers, access controls, and filtering for sensitive contexts in the reference implementation.

Test it by retrieving approved context, denying a restricted identity, correcting a memory, removing a source, and exporting the agreed content with its metadata.

Customer-safe isolation and connector hardening remain commercial beta acceptance items.

4. Bounded Agent Authority

Every agent is a software identity with a purpose, human owner, permissions, tools, routes, budget, approval boundary, lifecycle state, and evidence requirement.

The organization can pause, restrict, recover, and decommission one identity without treating the fleet as a shared account.

BAMS represents distinct agent identities and lifecycle controls. Its provisioning path joins access, credentials, memory, workspace, inference, and operating configuration.

Test it by showing an agent's authority envelope, attempting denied access, changing one permission, pausing the identity, and following the decommission procedure.

The accountable human and organization remain responsible for the deployment.

5. Human Authority and Evidence

Consequential actions cross an explicit approval boundary. The request includes enough decision context for an authorized person to approve or reject it. The result remains connected to the work record.

BAMS includes approval queues, governance activity, and audit records. It represents decisions as operating state rather than a message outside the workflow.

Test it by triggering an approval, rejecting it, showing the resulting workflow state, and reconstructing the decision later from evidence.

Approval is not a decorative safety step. It is the organization's authority model expressed in the system.

6. Named Integrations

Every external connection has an owner, credential path, permission scope, health state, failure behaviour, and acceptance test.

No-strings-attached architecture does not depend on a supplier claiming every connector. It requires the scoped connectors to be visible and operable.

BAMS displays integration configuration and health, including connected, degraded, and disabled states. The current reference implementation includes a mixture of working and deployment-specific adapters.

Test each connector by verifying source permissions, failure state, credential revocation, and the effect on the workflow.

Universal connector coverage is not a BAMS claim.

7. Operational Transfer

The client can perform routine operations and agreed changes without the supplier acting as permanent interpreter.

This is where the Forward Deployed Engineer matters.

The FDE maps one workflow into BAMS, implements the controls, records the decisions, trains the operators, and transfers the runbooks. The role is measured by decreasing client dependency.

Test the handover by asking client operators to change a scoped permission, disable a provider, resolve an exception, pause an agent, inspect context, recover service, and export evidence.

Documentation is accepted when the client can use it.

8. Exit and Continuity

The client can stop new activity, preserve state and evidence, revoke supplier access, export the agreed assets, and follow a documented recovery or transition path.

BAMS includes circuit breakers, provider controls, agent lifecycle operations, governance state, and audit activity relevant to this test.

Test it with a scoped five-minute disconnect drill. Measure the actual result. Record failed steps and open dependencies.

The complete end-to-end drill has not yet been verified across a packaged client deployment. It is an acceptance test for the commercial beta engagement, not a performance number we claim today.

Product Evidence and Delivery Commitments

The standard contains two types of obligation. They should not be mixed.

Product evidence

The working BAMS reference implementation demonstrates that projects, approvals, agent identities, memory, model administration, integrations, governance, audit, circuit breakers, and infrastructure state are part of the operating system.

These interfaces and controls are visible now.

Delivery commitments

The commercial beta engagement must package the system for the client's environment, connect named sources and tools, apply the client's authority model, verify the scoped workflow, produce the handover packet, and run the agreed exit tests.

These outcomes require client prerequisites and a signed scope. They should be accepted from evidence, not inferred from a product screenshot.

This separation makes the proposition stronger. Buyers can see what exists and know what the engagement still has to prove.

What the Contract Should Name

Technical design can be undermined by vague commercial terms.

A no-strings-attached agreement should name:

• target deployment environment and continuing-use rights
• client and supplier responsibilities
• source-code, configuration, and component rights as applicable
• model and provider account ownership
• credential ownership and revocation
• data, memory, and evidence export contents
• documentation and handover requirements
• client operator acceptance tasks
• supplier access removal
• support and upgrade boundaries
• exit assistance and transition conditions
• known commercial beta limitations

Exact wording requires legal review. The architecture supplies the tests that make the wording operational.

Why BAMS Includes the FDE

An organization does not become independent because software was installed in its environment.

It becomes independent when its people can operate the workflow, change the permitted configuration, understand the dependencies, recover from failure, and exercise the exit rights.

The FDE comes with BAMS because the last kilometre contains client-specific work. The FDE's objective is to finish that work in a form the client can own.

This is not a promise of endless customization. The first deployment is bounded to one production workflow with a defined acceptance condition. The work that improves repeatability should return to the product. The work that expresses client policy should remain under client ownership.

Current BAMS Position

BAMS is a strong internal reference implementation being productized as a commercial beta appliance.

The architecture and operating surfaces exist. The repeatable client package, customer-safe isolation, connector hardening, first-class module boundaries, and buyer evidence exports remain active productization work.

We state that boundary because no strings attached also applies to the sales process. A buyer should know which controls are present, which acceptance tests remain, and which claims require evidence from the deployment.

Turn the Promise Into a Test

Ask the supplier to show where the system runs. Change a model route. Deny context access. Pause one agent. Reject an approval. Disable a connector. Reconstruct a decision. Hand the runbook to the client's operator. Revoke supplier access. Export what the organization needs to continue.

These operations reveal the strings.

Some dependencies will be accepted. Some will be replaced. Some will become explicit conditions in the agreement. What matters is that the organization can see and govern them.

BAMS is our answer to that requirement: a governed enterprise AI operating layer, deployed with an FDE whose objective is client ownership.

No strings attached is not the absence of architecture.

It is architecture designed for control, transfer, and exit.

A No-Strings-Attached Acceptance Sheet

The eight tests should end in one acceptance sheet that both parties can read without translating product language.

For each test, record:

• scope
• client owner
• BlackUnicorn owner during delivery
• procedure
• expected result
• actual result
• evidence location
• limitation or failed step
• disposition and due owner

The sheet should use three statuses: passed, failed, or not in scope. "Partially ready" is too vague unless the accepted and failed parts are named.

The client can then see whether infrastructure control passed while evidence export remains open, or whether model disable passed while connector revocation still requires manual work.

This is more useful than a single deployment-complete label.

Independence Is Not Isolation

Client ownership does not require building every component alone or refusing external services.

The client may choose hosted models, managed infrastructure, commercial connectors, and continuing BlackUnicorn support. The requirement is that each dependency has a clear owner, right, policy, operating procedure, and exit condition.

This makes the system composable without making the organization passive.

It also changes the supplier relationship. BlackUnicorn remains valuable by improving the product, supporting the deployment, and helping with new governed workflows. Continued work is a client choice, not the result of undocumented operating knowledge.

Review the Standard Over Time

An accepted architecture can gain new strings.

A new provider can introduce different data terms. A connector can gain write access. An agent can receive another tool. A memory source can change classification. A runbook can become stale after an update.

The organization should review the eight tests when a material dependency or authority boundary changes.

BAMS provides the operating surfaces. The ownership standard is maintained through change records, targeted acceptance tests, and client operators who remain able to exercise the controls.

No strings attached is therefore not a one-time procurement statement.

It is a property the organization keeps verifying.

The Standard in One Workflow

The architecture becomes concrete when all eight tests meet one piece of work.

For a supplier-review workflow, BAMS runs in the agreed client environment. The review identity retrieves only approved agreements and policy context. The route policy keeps restricted material on the permitted inference path. The agent drafts a recommendation but cannot approve or send it. Legal receives the decision evidence. Connector state remains visible. The client's operator can pause the identity, disable the provider, inspect the record, and export the agreed state.

The FDE helps create that path and then asks the client's operators to exercise it.

Each action produces a result for the acceptance sheet. Infrastructure can pass while a connector remains open. Identity can pass while an export needs work. The workflow can enter production only under the limitations the client has explicitly accepted.

This is the practical difference between a broad independence claim and a no-strings-attached architecture.

The first asks the buyer to trust an intention.

The second gives the operator a procedure, a control, and an evidence record.

<!-- Editorial evidence: E10 and E11 in series/bams-no-strings-attached/EVIDENCE-LEDGER.md -->