Putnami has no announced launch date or imposed release cadence. Diagnostics and design partnerships are available today; product capabilities remain private until the support, distribution, and operational evidence justify a broader promise.
The release view says what can be used now without manufacturing a launch date or a cadence.
Available now
Begin with the problem your team already has.
The first engagement does not require source availability, self-service onboarding, or adoption of the Putnami stack. It begins with evidence from one representative system or change.
Available now
Software Change Diagnostic
A paid, time-boxed investigation that follows one real change to expose lost context, coordination, evidence gaps, and author dependency.
Available now
Design partnership
A bounded continuation around a concrete system problem, with client-specific delivery kept separate from reusable product learning.
Product status
Release means supported, not merely present.
The implementation and documentation are not publicly linked yet. Current capabilities can still support a bounded engagement where they fit; private product work is not presented as generally available.
Private today
Putnami Tooling & Frameworks
Supported Go and TypeScript surfaces, deterministic jobs, impact analysis, and local or CI operation are used and hardened privately.
Private beta
Putnami Intelligence
Default-branch indexing, structural reads, MCP access, and pull-request intelligence are being validated on real repositories.
Managed development
Putnami Cloud
Identity, configuration, source, distribution, and control capabilities exist; the complete managed lifecycle remains product direction.
Release principle
Open capabilities when the evidence supports the promise.
No announced launch date or committed cadence.
Presence in a repository does not imply public availability or support.
Each status states what a user can rely on today and where the boundary remains.
Access expands capability by capability, with no requirement to migrate the full stack.
Start from the client problem, agree the time and commercial boundary, inspect a real change, and decide explicitly whether to stop, extend the mission, or continue as a design partnership.
Select one recent change or delivery path with representative friction.
Agree access, confidentiality, time, budget, and payment before substantial delivery.
Use Putnami capabilities only where they produce credible evidence for the client problem.
Separate client-specific work from reusable product learning at the continuation checkpoint.