The Ownership Standard.

The Conti Digital Ownership Standard, Version 1.1. Effective August 2026.

This page describes the Ownership Standard by which all Conti Digital solutions are delivered. This is attached to every build agreement I sign. Download the exhibit copy: conti-ownership-standard-v1.1.pdf. The version history and my signature are at the bottom of the page.

Why this page exists

There is a conflict of interest in this industry. The vendor builds the solution inside their own accounts, on their own platform, under their own credentials. The monthly fee is framed as service, and some of it may be. But strip the service away and a hard residue remains: you are paying, forever, to retain access to something you cannot take with you. The system and relationship both may work, but every month the cost of leaving grows, because the workflows, the data, the tuned configuration, and the institutional knowledge all live somewhere outside of your control.

In many ways, the success of the solutions these vendors provide may be their undoing. If a business with real revenue flowing through it buys a vendor-managed solution, consider what happens if that solution ends up being particularly successful. If the business becomes reliant on the solution for meeting its operations and KPI goals, that business is now in a disadvantageous lock-in relationship with the vendor. This ownership standard helps to eliminate such risk while providing real, custom production systems as permanent operational assets to high-value businesses. It governs every engagement I take, from a legacy replacement to a commerce platform to a production AI agent. It is not marketing copy that lives on this page and nowhere else. It is the acceptance criterion for the build.

The Exit Test

At any point in the relationship, the client controls the accounts, code, data, billing, and deployment path. If the operating relationship ends, another qualified engineer can operate and maintain the system without buying anything from Conti Digital or migrating off a proprietary runtime.

This is a continuity test, not the proposed end state of the relationship. Many clients keep me responsible for operations, maintenance, incidents, and forward development because I already know the system and the business requirements. The test exists so that a long relationship stays voluntary. No proprietary component, vendor-owned account, or private control plane can make the system disappear when access changes.

Ask any vendor you are evaluating to write their version of the exit test sentence and sign it. The ones who will are worth talking to. The ones who talk about partnership instead have told you what the partnership is for. Mine is signed at the bottom of this page.

The standard: thirteen items, four groups

The standard is a checklist. Every engagement closes against it, item by item, and each item names something that is yours: in your accounts, under your credentials, on the day we make the agreement. The items are numbered so they can be referenced.

Accounts and infrastructure

• OS-1. AWS organization and accounts: created in your name, root credentials held by you. I work through scoped roles you can revoke in one console session.
• OS-2. Infrastructure as code: every resource defined in Terraform, in your repository. The environment is not a pile of console clicks; it can be reviewed, diffed, reproduced, and recovered without reverse-engineering console state.
• OS-3. IAM and permissions: least-privilege roles defined in code you can read. Nothing in production depends on my personal access existing.
• OS-4. Secrets: in your AWS Secrets Manager. I never hold the only copy of a credential, and rotating me out is a straightforward procedure.

Code and delivery

• OS-5. Source repositories: in your GitHub organization, full history, no private forks held back. The commit log is part of the deliverable.
• OS-6. CI/CD pipelines: defined in your repositories, running on your accounts, with health checks and rollback. Deploys do not route through my machines.
• OS-7. Documentation and runbooks: written for the next engineer. Deployment, operations, and incident procedures, kept in the repository where they age with the code.

Data and operations

• OS-8. Production data: in your databases, in your account, exportable at will, with backups and encryption configured as code.
• OS-9. Observability and logs: dashboards, alarms, and structured logs in your account. The operating history stays under client control while I run the system and if responsibility later changes.
• OS-10. Model usage and billing: AI model calls metered in your account at published prices. You see the bill I see, down to the model and the day.
• OS-11. Third-party accounts: Stripe, DNS, email, analytics: registered to your business, administered by you. I request access; I do not own the relationship.

The exit itself

• OS-12. Exit path: a named transition procedure in the documentation. Changing operators is a documented engineering transition, not a forced replatform.
• OS-13. Ongoing operation: the client decides who operates the system. Conti Digital can remain accountable for AWS and application operations, maintenance, incident response within defined coverage, reliability, cost, vendor integrations, and continued delivery under a separately scoped Ongoing Platform Engineering. The accounts, code, data, pipelines, logs, and third-party relationships remain under client control while I do the work.

Acceptance: what happens when a build fails this standard

A build is complete when it passes this standard, item by item, not when the software works. If any item fails at the ownership audit, I remediate it at my own expense before final payment is due.

This clause converts thirteen promises into one commitment: final payment is gated on the ownership audit passing, which you can have run by your own team. I can afford to publish it for one reason: I already build this way. Ask the next vendor you evaluate to put the equivalent sentence in writing.

The Exit Test as a checklist: eleven checks, one focused technical review

The Exit Test above is one sentence. This is the same test as a procedure, written so any engineer can run it in an afternoon, against my work or against any vendor you are evaluating. Each check cites the items it verifies.

1. Sign in to the AWS management account with root credentials your business holds, without contacting the vendor. (OS-1)

2. Run terraform plan from a repository your organization owns and read a clean, explainable diff of production. (OS-2)

3. Revoke the vendor's access in a single console session. Production keeps running. (OS-1, OS-3)

4. Rotate every secret from your AWS Secrets Manager using the documented procedure. (OS-4)

5. Ship a one-line change to production through CI, from your repositories, with the vendor's machines involved nowhere. (OS-5, OS-6)

6. Export the production database, today, to storage you control. (OS-8)

7. Hand the runbooks to an engineer who has never seen the system and have them walk through the three most likely incidents. (OS-7)

8. Inventory production for anything that requires a license, account, or runtime the vendor controls. The correct length of that list is zero. (OS-12, OS-13, and the Exit Test's no-proprietary-runtime clause)

9. Read this month's model and API usage in your own billing console, at published prices, down to the model and the day. (OS-10)

10. Confirm the domain registrar, the DNS zones, and every third-party account, payments, email, analytics, are registered to your business. (OS-11)

11. Open the dashboards and alarms in your own account and trace last week's deploy through the logs, with no vendor login involved anywhere. (OS-9)

This checklist is deliberately vendor-neutral, and it is free. I release it under CC0: no attribution required, no permission needed. Copy it, rebrand it, hand it to your attorney, run it against your current vendor, run it against me. If another firm adopts it, good. The test does not care who administers it, and neither should you.

The standard, applied to me: the reference build, audited

My position is to hold business-critical software proposals from any vendor to this standard, including me. That is only accurate if I publish my own audit. Three kinds of evidence appear: public, meaning you can check it from this page right now; client-verifiable, meaning the evidence lives in the client's accounts; and attestable, meaning I will walk the designated reviewing engineer through it upon request.

• OS-1, accounts: client-verifiable. Root credentials are held by the owner; my scoped roles are visible in their IAM console. The account model itself is public in the sovereign infrastructure blueprint.
• OS-2, infrastructure as code: client-verifiable by check 2. The Terraform estate is described publicly in the platform engineering write-up.

• OS-3, IAM: client-verifiable. The lane separation, including a sales agent that structurally cannot read the accounting and HR trees, is documented in the agent case study.
• OS-4, secrets: client-verifiable by check 4.
• OS-5, repositories: client-verifiable in their GitHub organization. The repositories are private, so this row is attestable on request rather than publicly checkable.
• OS-6, CI/CD: client-verifiable by check 5. The same delivery discipline is public in the open-source work, where anyone can read the pipelines.
• OS-7, runbooks: client-verifiable by check 7; attestable on request.
• OS-8, production data: client-verifiable by check 6.
• OS-9, observability: client-verifiable by check 11. The dashboards and alarms live in the client's account, which is the point.
• OS-10, model billing: client-verifiable by check 9. The metering arithmetic is public in the cost article.
• OS-11, third-party accounts: client-verifiable by check 10.
• OS-12, exit path: client-verifiable; the transition procedure lives in the repository with the rest of the documentation. Attestable on request.
• OS-13, ongoing operation: public. Ongoing Platform Engineering pricing is on the pricing page, and the client retains control while delegating operation.

Most rows can only be verified by the client, because that is where ownership evidence lives. A vendor who grades themselves perfectly in public is doing marketing. This is an audit trail, and the parts I cannot show you are clearly labeled.

The standard at its hardest case

Ownership claims are easiest to fake in AI. An agent platform is where a vendor can most plausibly say trust me, and where a buyer can least plausibly check. So that is where this standard has to earn its keep. The figures below show the standard enforced at its most difficult surface: separate IAM roles per agent lane, permissions attached from code, sensitive data denied at the storage layer, and a human approval gate in front of production writes. Prove the standard where it is hardest and you have proved it everywhere else.

How I build

The standard is enforceable because of how the systems are built. These are the capabilities under every door on this site.

Infrastructure as code. Every environment starts as Terraform. This is why the Exit Test is possible at all: an environment defined in code can be reviewed by a qualified engineer, reproduced without reverse-engineering console state, and audited line by line.

Security by construction. Least-privilege IAM, secrets in Secrets Manager, encryption at rest, deny rules at the storage layer for data that certain workloads must never read. In the reference deployment, the sales agent structurally cannot read the accounting and HR trees of the company archive: not because a prompt says so, but because the permission does not exist.

Delivery discipline. CI/CD with health checks and rollback, deployment circuit breakers, and observability shipped with the application rather than bolted on after the first outage: dashboards, alarms, and logs that land in your account.

Data work that survives scrutiny. Migrations rehearsed against full copies of real data, verified by record count and by content, and cut over without downtime. The reference migration moved 28,062 invoices from a 20-year FileMaker system with zero operational downtime, and the engineering write-up is public.

The three objections, answered on the record

Does owning it mean I need my own engineers? No. Ownership defines control, not staffing requirements. I can remain the primary operator for the AWS infrastructure and application, including maintenance, incidents within defined coverage, reliability work, and continued delivery. Your business keeps control of the accounts and assets while delegating the operating work to me.

Why would a vendor agree to this? What is your angle? I charge for building, at prices published on the pricing page. I also charge for ongoing operation, maintenance, incident response within defined coverage, and continued delivery. Long relationships should last because the engineering remains valuable, with the ownership controls on this page intact throughout. This document lets you verify that without having to trust my marketing material.

What happens when it breaks at 2 a.m. and you are gone? I am AWS Certified to design cloud solutions with enterprise-level disaster recovery and multi-region or global availability, and can provide real RTO and RPO metrics for applications and critical datastores. I can guarantee as much operational uptime as your solution and budget require using well-architected cloud principles, and I have enough production release experience to keep critical applications stable. I can define response times for support requests; failover to primary restorations, regional outages, and other emergency procedures; and deliver agency-level results without exposing a team of juniors, or - worse - a team of juniors using AI coding agents, to your critical business systems.

One argument, three documents

This page is the middle of a system. The evaluation framework, the standard, and the proof are published separately so each can be used without the others: the six questions are what to ask any vendor before you sign. This page is what the answers must be. The verification page is me, held to my own bar. Each question maps onto numbered items here:

• Question one, who owns the account: answered by OS-1 and OS-11.

• Question two, who holds the keys: answered by OS-3 and OS-4.

• Question three, what happens when you leave: answered by OS-12 and OS-13.

• Question four, what does the compute cost versus the fee: answered by OS-10, with the arithmetic published in the cost article.

• Question five, what changes after launch and who owns it: answered by OS-2, OS-6, OS-7, OS-9, and OS-13. Dependencies, APIs, models, threats, and business requirements change. The operator maintains them in the client's accounts against written runbooks, monitoring, and an explicit operating scope.

• Question six, can you verify the work at the depth you are buying: answered by OS-5 and the scorecard above.

If a vendor's answers cannot be mapped onto numbered items in a standard they publish, that is itself the answer.

Hold every vendor to this, including me

I am not inherently against managed solution or SaaS in general. This was written in an attempt to help owners or decision-makers at established businesses protect themselves against misleading marketing material by agencies who promote client ownership and data sovereignty, while selling solutions that require a permanent agency involvement for continued access to the system. Where your critical business data flows through their platform, and your workflows exist on their infrastructure. An honest managed solution may be the right call for a smaller business, or if the workflow is non-critical. Renting outcomes from agencies that are represented as sovereign, client-owned assets is never the right call.

Version history

• Version 1.1, August 2026: clarified that client ownership does not assign operations to the client. Reframed OS-13 around continued Conti Digital operation, explicit coverage, maintenance, incident response, and continued delivery. Repositioned the Exit Test as continuity protection for a long operating relationship. Tightened the reproducibility, transition, and evidence language so the standard does not promise an arbitrary recovery time or treat contractual ownership and operational control as the same thing.

• Version 1.0, August 2026: initial public release. Thirteen items in four groups, the acceptance clause, and the Exit Test checklist as first published.

Changes to this standard are recorded here, with what changed and why. A build closes against the version in effect on the date its agreement was signed. An empty changelog under a single entry is not an omission; it is a claim that this document is maintained, and you are welcome to hold me to that too.

Signed

The Exit Test section asks every vendor to write their version of the sentence and sign it. It would be a strange document that made that demand and stayed unsigned.

/s/ Peter T. Conti

Principal, Conti Digital LLC. Naples, Florida.

Signed against Version 1.1 of this standard, August 2026.