Manifesto · seven principles
How we engage.
These are the commitments that govern how we deploy the platform, onboard your team, and stay through enablement. Each is reflected in how we sell, how we staff, and the substrate we ship.
Start at the business, not the stack.
Most technology purchases are framed at the tool layer: platform selection, feature checklist, vendor shortlist. The outcome the software is supposed to produce is assumed, never stated. That assumption is where shelfware is born.
Every Subnet345 deployment opens at the business. Before the platform goes in, we agree the specific, testable outcomes that define success: dollars saved, risk retired, capability installed, or time recovered. We stand Plexus up against that outcome, not against a feature list.
This one commitment reorganizes every other decision: what we configure first, how we onboard, when we step back.
Immerse before we onboard.
Discovery in traditional software sales is performed for free, disguised as a demo, and optimized for the contract that follows. The buyer learns whether the product actually fits only after it has been bought.
We stand the platform up inside your environment first, with your operators, against your telemetry, under your constraints, before you commit to a full rollout. You see the substrate running on your own systems. We will tell you what we find. Even if what we find is that you do not need it.
If we cannot see your systems in operation, we will not stand the platform up against them. Software bought from a deck is how organizations end up onboarding the wrong thing, twice.
Map the path before we deploy.
A rollout with no defined end is not a rollout. It is a dependency wearing a better uniform. The structural fix is to draw the route before anyone commits to travel.
Architecture, sequencing, dependencies, onboarding gates, and the conditions that end our hands-on involvement are written before the rollout begins. You receive the deployment plan we will execute, not a roadmap we will develop later at your expense.
We consider our finest delivery the rollout that lands on time, on scope, and leaves your team operating the substrate without us. We tell you this in writing.
Prove on the smallest surface that matters.
Big-bang rollouts are how programs fail. The same holds for unvalidated configurations, unexercised runbooks, and platforms adopted on the strength of a reference call. Evidence is cheap early and expensive late.
Every Subnet345 rollout contains a bounded pilot: the substrate onboarded onto the smallest workflow that proves the value, under production-grade conditions. Pilot gates require a disproof attempt, not a success demo. We commit to a full rollout only when the pilot has survived an honest attempt to break it.
If the pilot fails, the plan changes. That is the point of running one.
Launch with a senior engineer on your account.
In traditional software, sales promises one thing and a support queue delivers another. Senior people win the deal; a ticket system runs the relationship. The gap between what was sold and what is operated is where the value leaks out.
Subnet345 assigns a dedicated AI engineer to your account: a senior person who stands the platform up, onboards your operators, and stays through enablement and training. The person who sets it up is the person who trains your team. Our bench is small, selected, and deep.
This is a deliberate scaling constraint. We are building a product with people attached to its delivery, not a download and a help center.
Evolve the operator, not the dependency.
Most software relationships are designed, consciously or not, to keep you dependent. Knowledge stays with the vendor. Runbooks are absent. You cannot operate without support. The subscription becomes the lock-in.
We consider transfer the deliverable. Documentation, runbooks, role-based training, and measured competency gates are built into the rollout from day one, not appended at the end. Your assigned engineer trains your team to run the substrate themselves. What grows after we step back is your team's capability, not your invoice.
You should be able to operate the platform without us at any time. That is the condition we build toward, and the condition we prove before we step back.
Honest scope. Operated posture. No claimed compliance we have not delivered.
The most consequential work sits under regulation, governance, and sovereignty constraints. Tools built for the open web are structurally incompatible with it. Vendors claim compliance they have not operated under. Teams claim clearances no one on the team actually holds. The gap surfaces at audit, not at signature.
Subnet345 claims only what our team has actually delivered, regulated or otherwise. The product is built to meet SOC 2, HIPAA, and GDPR expectations, and deploys on infrastructure partners whose published posture covers those standards. The delivery history includes federal-adjacent programs executed under prior global-transformation practices serving enterprise, military, and government clients. Where our posture does not yet cover something, such as active clearance or regulated attestation, we say so upfront.
This is not a selling point. It is the entry ticket for everything we build.