Putnami
Company

Software should be operable by something that did not author it.

That non-author may be a new teammate, an auditor, an operator during an incident, an AI agent, or the original author months later. They should be able to understand, change, verify, operate, and recover the system without tribal knowledge.

Operating thesis

Move critical knowledge from the author into the system.

putnami / flowone change · revision-specific
  1. 01Author knowledgeimplicitIntent, constraints, recovery
  2. 02Change recordconnectedRevision-specific facts and evidence
  3. 03Bounded authorityexplicitPeople and agents share contracts
  4. 04Non-author outcomeoperableUnderstand, change, verify, recover
Putnami treats non-author operability as a system property that must hold through change and recovery.
Mission

Make every software change understandable and trustworthy.

Reduce the total time and coordination required to turn shared intent into a safe, verified, and operable outcome. Faster generation only matters when the whole change reaches the right result.

Why now

Generation scales faster than understanding.

Agents increase the number and speed of changes without increasing reviewer capacity at the same rate. The old costs—lost intent, unclear impact, weak evidence, and author dependency—become the limiting system.

The category

Trust engineering: how teams remain responsible for software they did not fully write and cannot fully read.

Vision

Software should be able to explain itself.

What it is. Why it changed. Which constraints applied. What evidence supports the result. What is running now. And how to recover if reality diverges from intent.

Observable
A system that cannot explain its state and behavior is not operable by a non-author.
Deterministic
Versioned intent and reproducible operations keep behavior reviewable and recovery possible.
Secure
Authority and unsafe paths stay explicit; the system fails closed rather than guessing permission.
User-owned
Customers retain authority over their data and can leave the managed platform.
Automation-ready
People and machines work through the same bounded, machine-readable contracts.
Business model

Lower the cost of adoption. Charge for shared and managed guarantees.

Adoption

Open and local foundation

Contracts, conformance, adapters, and local tooling reduce the cost of proving initial value.

Core revenue

Shared control plane

Teams pay for durable history, collaboration, policy, governance, audit, and enterprise integration.

Expansion

Managed lifecycle

Artifacts, previews, delivery, runtime, observability, and recovery add consumption-based depth.

Early learning

Design partnerships

Bounded paid diagnostics create client value while isolating evidence that can improve the product.

Explore the Software Change Diagnostic →

Operating discipline

Every new concept spends a finite friction budget.

  • Author one intention and derive many reliable consumers from it.
  • Prefer facts from native declarations over copied models.
  • Keep loops short, observable, reversible, and evidence-led.
  • Remove abstractions and gates that create more work than they prevent.