Dennis Forge introduces a different way of thinking about software transformations. Instead of executing changes immediately, Dennis generates deterministic plans that can be inspected, exported, signed, verified, and applied safely.
The guiding principle is simple: plans first — changes later.
Large code transformations are inherently risky. Traditional scripts, codemods, or migration tools often modify files immediately, making it difficult to understand what will actually change before execution.
Dennis separates planning from execution. It generates a deterministic transformation plan that can be reviewed and verified before any change is applied.
The plan becomes the source of truth.
Not exactly. Dennis is better described as a deterministic transformation engine.
It allows teams to define, inspect, share, and safely apply structured changes across codebases.
Deterministic means the same input produces the same output. Given the same project and dictionary, Dennis will generate the exact same transformation plan.
This guarantees reproducibility and allows plans to be reviewed, stored, and verified safely.
Before generating a transformation plan, Dennis evaluates whether extracted content is meaningful. This decision layer filters out noise such as SQL fragments, CSS classes, identifiers, and code artifacts.
This ensures that DEX artifacts represent meaningful transformations, not raw extraction.
Lineage is the chain of transformations recorded across artifacts. Each step includes hashes and metadata linking it to the previous state.
This creates a verifiable history where transformations can be traced, audited, and validated over time.
A forge is a place where things are crafted deliberately. Nothing happens accidentally. Every step is visible. And the final product is immutable and verifiable.
Dennis follows the same philosophy: transformations are planned, reviewed, and executed intentionally.
The name also honors Dennis Ritchie, co-creator of the C programming language and one of the architects of modern computing.
Yes.
Because plans and artifacts are deterministic, they can be generated, verified, and applied in automated environments.
This enables workflows where transformations are validated before being applied in production systems.
DEX stands for Deterministic EXchange artifact.
A DEX artifact is a portable container that describes a transformation. It includes the plan, metadata, and optional cryptographic signatures.
DEX artifacts allow transformations to be shared, verified, and executed safely across machines and teams.
Internally a DEX file is a deterministic tar.gz archive
containing:
Yes. DEX artifacts are intentionally transparent. They can be inspected using standard tools.
tar -tzf artifact.dex
XDEX is an extension of the DEX format designed for situations where the transformation payload must remain confidential.
In an XDEX artifact, the transformation plan is encrypted while the manifest and metadata remain visible. This allows the artifact to preserve verifiability, signatures, and provenance while protecting sensitive transformation details.
This makes XDEX suitable for environments where transparency of the artifact is required but the transformation logic itself must remain private.
Transparency is a design goal of the format.
Traditional codemods and AST tools focus on executing transformations directly. They operate on code structures but typically lack a formal planning layer.
Dennis introduces a separation between planning and execution. It generates a deterministic plan first, which can be reviewed, verified, and shared before any change is applied.
The focus is not only on how to transform code, but on making transformations inspectable and reproducible.
DEX artifacts are portable files.
They can be stored in Git repositories, artifact registries, local storage, or shared directly between teams.
Dennis does not require a central service to function.
All users' artifacts for http://dennis-forge.com/repo/ are uploaded and stored in the Dennis cloud storage service. We have no access to the contents of the DEX artifacts themselves, just an Index for easy search & download of those Artifacts marked as "Public"
No.
The CLI remains the primary and fully capable interface. The hosted service, https://dennis-forge.com/repo/ is an additional layer for collaboration, inspection, and artifact sharing.
All core functionality remains available locally.
Signatures allow teams to verify that a transformation plan has not been altered and that it originates from a trusted source.
No. Signatures are append-only.
Each new signature is added to the artifact without removing the previous ones. This preserves a full historical record of approvals.
This design creates a verifiable chain of custody for transformations.
Artifacts can accumulate signatures over time — for example from developers, teams, auditors, or organizations — without losing the previous record.
DEX artifacts contain metadata, hashes, and signatures that allow the origin and integrity of a transformation to be verified.
This makes Dennis suitable for environments where traceability and accountability are important.
Yes.
DEX artifacts are portable files and do not depend on a specific service or platform. They can be distributed independently, stored in Git, shared between teams, or published through registries.
This also allows independent researchers or auditors to publish verifiable artifacts describing transformations or evidence without relying on centralized infrastructure.
Dennis focuses on deterministic transformations. It does not attempt to interpret runtime behavior or dynamic execution.
Its effectiveness depends on the quality of the scanner and the transformation definitions provided.
Like any tool, it should be used with review and validation, especially in critical systems.
Dennis is designed for engineers and teams working with large or complex codebases where changes must be controlled, reviewable, and reproducible.
It is especially useful in environments involving:
scan → plan → pack → sign → verify → apply
Each step is explicit and inspectable.
No. Dennis first generates a plan describing the transformation.
Only after reviewing the plan do you decide whether to apply it.
Yes. Plans are reversible by design and can generate inverse operations when appropriate.
Yes. Dennis is released under the MIT license. The CLI and deterministic core will remain open source.
Possibly. A hosted forge may exist in the future for collaboration and artifact sharing.
However, the CLI and artifact format remain independent of any hosted platform.
Yes. The CLI works entirely locally.
Projects can be scanned, plans generated, artifacts created, and transformations applied without network access.
Yes. The architecture is designed to support scanners for additional languages and ecosystems.
Future versions may support plugins for ecosystems such as PHP, JavaScript, or React.
The deterministic principles and artifact model are designed to remain stable over time so that artifacts remain verifiable years into the future.
“An archive is not merely a place where truths are stored. It is a machine built so that tomorrow may still trust yesterday.”
Dennis exists to make large software transformations transparent, reproducible, and accountable.