The method
How Solcogito tools are designed, constrained, and shipped.
Deterministic
Given the same input, the same output. Always. Without exception.
A tool that produces different results depending on environment, timing, calling order, or hidden state is not a tool — it is a liability. Every function in this suite is constrained to deterministic behavior. Side effects are explicit. State is visible. Nothing depends on what is not passed in.
Determinism is not a quality we aspire to. It is a constraint we enforce.
Auditable
Every release produces a ratified version, a clean changelog, and traceable provenance. The record is not decorative.
If a release cannot be reconstructed from its record — if the version is ambiguous, the changelog is incomplete, or the artifact cannot be traced to a specific commit — then the record has failed. Auditability means the history of the software is as trustworthy as the software itself.
This is why AutoChangelog exists. And why BuildStamp attaches provenance to artifacts rather than trusting that the build environment will remain legible after the fact.
Bounded
Each tool has a precise domain. It does not absorb neighboring concerns.
AutoChangelog manages changelogs. AutoVersion manages version state. BuildStamp attaches provenance to artifacts. None of these tools does what the others do. The interfaces do not overlap. The responsibilities do not drift.
This is not a limitation — it is a feature. Bounded tools are composable. They can be combined, replaced, or audited in isolation. A tool that absorbs its neighbors becomes opaque and brittle. Small, composable, explicit surfaces age better than integrated systems that do everything.
Explicit
Nothing is inferred. Nothing is implicit. Nothing is hidden.
The surface area of each tool matches what is documented. Behavior that cannot be observed through the published interface is not behavior we intend to support. If a tool appears to do something undocumented, that is a defect to resolve, not a feature to preserve.
Explicit does not mean verbose. It means that what the tool does is directly inspectable from what it accepts and what it returns. No magic. No environment-dependent defaults. No behavior that only becomes visible under pressure.
In practice
These four principles are not aspirational statements. They are encoded as operational constraints on every tool in the suite.
Every interface is designed to make the correct behavior explicit and the incorrect behavior difficult. Every release is subject to the same validation the tools impose on the software they serve. Every failure mode is documented before a tool ships.
The result is a suite of tools that behave exactly as described, maintain a clean record of how they have changed, and can be used with confidence in environments where correctness is not optional.