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.
Yes.
While Dennis is designed as a developer tool, its core workflow is simple: generate a plan, review it, and apply it.
This makes it suitable for environments such as compliance audits, legal workflows, or any situation where changes must be reviewed before execution.
The technical details are optional. The plan itself is human-readable.
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.
Dennis includes a deterministic diff system that compares the original state of a project with the result after applying a transformation.
When used in Git repositories, Dennis focuses on tracked files and filters out irrelevant noise such as internal metadata or binary files.
The result is a clean, structured diff that reflects only meaningful changes. Because the diff is deterministic, it can be reproduced and verified reliably.
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.
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.
The Forge stores DEX artifacts and indexes metadata to enable search and discovery.
Artifacts are treated as immutable units. The system does not modify their contents.
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:
No.
Git tracks the state of your codebase. Dennis tracks and verifies the transformations applied to it.
Dennis can integrate with Git projects (for example by reusing .gitignore rules), but it does not depend on Git and can operate in environments where version control is not available.
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.
Yes. Dennis The Forge is the hosted platform for storing, sharing, and inspecting DEX artifacts. It lives under: https://dennis-forge.com/repo/
It provides a structured environment with Workspaces, Projects, and artifact visibility controls (private, organization, public).
However, the CLI and artifact format remain fully independent and can be used without the hosted service.
Dennis The Forge is a hosted repository for DEX artifacts.
It allows users to upload, organize, inspect, and share transformations through a structured model of Workspaces, Projects, and Artifacts.
It is not required to use Dennis, but provides a collaborative layer on top of the CLI.
Workspaces are containers for organizing related work.
Projects live inside Workspaces and group related DEX artifacts.
This structure allows transformations to be organized in a meaningful and scalable way.
Each artifact has a visibility level:
Only artifacts marked as public are visible to guest users and the public index.
No.
Artifacts are identified by their hash, ensuring that the same DEX artifact cannot be uploaded multiple times.
This preserves integrity and avoids duplication across the system.
Yes. Guest access allows browsing and downloading of public artifacts.
However, uploading, organizing, and managing artifacts requires a registered account.
No.
Artifacts are stored as-is. The Forge only indexes metadata to allow searching and discovery.
The contents of DEX artifacts remain untouched.
Yes.
Dennis is designed as an extensible system where transformation logic is implemented through plugins.
Currently, the available implementation focuses on Python. Additional language support (such as JavaScript, PHP, Java, C/C++, and others) will be introduced through dedicated plugins.
The goal is to provide a consistent deterministic model across different ecosystems.
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.