DEV Community: Merlin

Truthmark for AI Loop Engineering: Keeping Product Behavior Observable

Merlin — Sat, 27 Jun 2026 04:25:36 +0000

AI coding agents are useful because they can make changes quickly. That same strength creates a review problem.

In a typical loop, an agent edits code, runs tests, reads failures, patches the implementation, and repeats. The loop may finish with clean tests and a reasonable diff. But somewhere along the way, a small behavior can change: a timeout becomes longer, an optional field becomes required, a retry policy becomes more forgiving, or an API starts accepting a state that used to be rejected.

None of those changes has to look obviously wrong in isolation. The issue is that the project’s behavior has moved, while the review surface still looks like a normal refactor.

That is the problem Truthmark is designed to help with. It gives an AI-assisted codebase a fact layer: human-readable, Git-reviewable Markdown files that describe what the project believes to be true. Agents can still write code quickly, but before they hand work back, they have to reconcile the code changes against the repository’s maintained truth.

For loop engineering, that is the useful part. Truthmark is not just a documentation tool. It is a way to make product and engineering drift easier to observe.

The real risk in AI loops is quiet behavior change

Most AI coding workflows optimize for a loop like this:

prompt -> edit code -> run tests -> inspect failure -> patch -> repeat

That loop is effective for mechanical correctness. It catches syntax errors, broken imports, failing tests, and many obvious regressions.

It is less effective at preserving intent.

A loop engine continuously modifies and adds code. Each step can be locally reasonable. One patch extracts a helper. Another loosens validation so a fixture is easier to construct. Another changes a default because it removes a flaky branch. Another updates tests to match the new behavior.

By the end, the branch may still be green, but the product may no longer behave quite the way it did before.

Tests help, but they are not a complete product contract. They encode examples the team remembered to write. Code review helps, but large AI-generated diffs are hard to review because the reviewer has to reconstruct intent from implementation details. Chat history is also a weak source of truth because it is usually private, long, and detached from the branch.

The missing layer is durable project truth that lives with the code.

What Truthmark adds

Truthmark keeps project truth inside the repository, usually under a workspace such as:

docs/truthmark/

Those files are ordinary Markdown files. They move through Git with the branch. They can be reviewed in the same pull request as the code. They are not hidden memory, an external database, or a separate spec system that quietly falls out of date.

That gives the team a useful review pattern:

code changed -> check the routed truth docs -> update truth if behavior intentionally changed -> review code and truth together

The important word is “intentionally.”

If an agent changes code but the truth document still describes the old behavior, there may be a mismatch. If an agent updates the truth document to describe new behavior, the reviewer can ask whether that behavior change was actually requested. Either way, the change becomes easier to see.

A concrete example: session timeout drift

Imagine the repository has a Truthmark product document like this:

# Session Timeout

## Product contract

Users are signed out after 30 minutes of inactivity.

A warning is shown 2 minutes before automatic sign-out.

Extending the session requires an explicit user action.

Now an agent receives a normal maintenance task:

Refactor the session timeout logic and fix the flaky auth tests.

During the loop, the agent changes a constant:

-const SESSION_TIMEOUT_MINUTES = 30
+const SESSION_TIMEOUT_MINUTES = 60

It also removes a warning path because that path complicated the test setup:

-if (remainingMinutes <= 2) {
-  showTimeoutWarning()
-}

The agent updates the tests, the suite passes, and the code looks simpler.

Without a fact layer, this can be reviewed as an implementation refactor. The behavior change is present, but it is buried in the code diff.

With Truthmark, the changed auth files can be routed to the session timeout truth document. Before handoff, the agent has to compare the code with the documented product contract. If it updates the truth document, the review now contains a plain-English behavioral diff:

 # Session Timeout

 ## Product contract

-Users are signed out after 30 minutes of inactivity.
+Users are signed out after 60 minutes of inactivity.

-A warning is shown 2 minutes before automatic sign-out.
+No warning is shown before automatic sign-out.

 Extending the session requires an explicit user action.

That diff is much easier for a product manager, tech lead, or reviewer to evaluate.

The right review question becomes:

Was the timeout change intentional?
Was removing the warning part of the request?
Should the truth document change, or should the code be corrected?

This is where Truthmark improves the loop. It turns a hidden semantic change into an explicit review decision.

Tests check execution. Truthmark checks claimed behavior.

A strong AI loop needs more than one feedback mechanism.

Tests answer questions like:

Does this example still pass?
Does this function return the expected result?
Did this integration path break?

Truthmark helps answer a different class of questions:

Does the code still match the behavior the repository claims to support?
Did this branch change a product promise?
Did the agent update engineering truth because an internal invariant changed?

That distinction matters. CI can tell you that the branch is executable. Truthmark helps make it clear whether the branch still matches the project’s documented intent.

A better loop is not simply:

Did the tests pass?

It is:

Did the tests pass, and did the branch preserve or intentionally update the relevant project truth?

Product truth and engineering truth

One useful design choice in Truthmark is the separation between product truth and engineering truth.

Product truth describes user-visible behavior: capabilities, API contracts, acceptance criteria, security boundaries, plan limits, notification rules, billing behavior, and other promises users or customers can observe.

Engineering truth describes how the system works internally: architecture, data flow, invariants, ownership, implementation constraints, and technical decisions future maintainers need to preserve.

This distinction keeps the workflow practical. Not every code change should update product truth.

If an agent rewrites a cache implementation but the external behavior is unchanged, product truth may not need to move. Engineering truth might need an update if the internal invariant changed.

If an agent changes how expired sessions behave, product truth should be checked. The user-visible contract has changed.

A simple rule works well:

If users can observe the change, check product truth.
If maintainers need to understand the change, check engineering truth.
If neither changed, report that truth was checked and left unchanged.

This gives agents a clearer finish condition. They are not only reporting that tests passed. They are reporting which behavioral surface they touched and how that surface relates to the repository’s maintained facts.

Routing reduces guesswork

Large repositories contain a lot of implicit ownership.

An experienced engineer may know that src/auth/session.ts belongs to authentication, that timeout behavior is part of the session product contract, and that the relevant tests live in the auth test suite. An agent may infer some of that from filenames, but inference is not the same as ownership.

Truthmark routes make ownership explicit. Conceptually, a route might look like this:

routes:
  - area: authentication
    paths:
      - src/auth/**
      - tests/auth/**
    product_truth:
      - docs/truthmark/product/session-timeout.md
    engineering_truth:
      - docs/truthmark/engineering/authentication.md

Now, when the agent edits auth code, it knows which truth documents are relevant. It does not have to create a new explanation in the wrong place or ignore the canonical document because it was not in context.

That improves both agent behavior and human review. The agent gets a better map of the repository. The reviewer gets a clearer relationship between code, tests, and documented intent.

A practical finish-time workflow

For loop engineering, Truthmark is most useful near handoff.

A good agent handoff should include:

1. The code diff.
2. The tests or checks that were run.
3. The Truthmark routes or documents affected by the change.
4. Any truth document updates, or a statement that behavior was checked and did not change.

A practical instruction for an AI agent can be simple:

Before handing off:
- Run the relevant tests.
- Identify Truthmark routes affected by this diff.
- Check the mapped product and engineering truth docs.
- If user-visible behavior changed, update product truth or revert the behavior.
- If an internal invariant changed, update engineering truth if needed.
- Report the code diff, test evidence, affected truth docs, and truth changes.

This does not replace code review. It makes code review more focused.

Instead of asking the reviewer to infer product behavior from a large implementation diff, the handoff gives them an explicit place to inspect behavioral changes.

How to add Truthmark to a repository

A basic setup looks like this:

npm install -g truthmark
truthmark config
truthmark init
truthmark check

Then configure the agent host you use. A minimal configuration can look like this:

version: 2
platforms:
  - codex

truthmark:
  workspace: docs/truthmark
  generated:
    portal:
      enabled: false

The exact folder is less important than the review model. The truth layer should live in the repo, on the branch, and in the same review path as the code.

Where to start

Do not try to document the whole codebase at once. Start with areas where small unintended behavior changes are expensive:

authentication
permissions
billing
public API behavior
data retention
onboarding
pricing or plan limits
notification rules
security-sensitive workflows

Pick one area. Document the current behavior. Route the relevant code to that document. Then require future agent loops to reconcile changes against it.

For example:

Document the implemented session timeout behavior across the auth middleware, session service, and auth tests. Create product truth only for user-visible behavior. Create engineering truth only for implementation constraints future agents should preserve.

That is enough to make the next refactor easier to review.

What Truthmark does not replace

Truthmark does not replace tests, static analysis, code review, product judgment, or architectural decision-making.

It adds another layer.

Prompts express intent. Tests provide executable checks. Types and linters catch mechanical errors. Code review applies human judgment. Truthmark keeps repository truth visible and reviewable while agents continue changing code.

That is the right scope. AI engineering systems work best when each layer has a clear job.

The point is controlled iteration

The goal of loop engineering is not simply to generate more code. The goal is to make repeated AI-assisted changes safe enough to use in real projects.

A controlled loop should move quickly, but it should also preserve product intent, expose behavioral changes, and make handoff easier for humans.

Truthmark helps by giving the project a place to say what is true, then asking the agent to check that truth before the work lands.

That is a practical improvement: fewer hidden behavior changes, clearer reviews, and better continuity between one AI session and the next.

Introducing Truthmark 2.2.0: Product and Engineering Truth Lanes for AI Coding Agents

Merlin — Mon, 15 Jun 2026 12:46:12 +0000

AI coding agents are becoming better at changing software.

That is no longer the hardest problem.

The harder problem is keeping the repository understandable after those changes land.

Code changes quickly. Documentation often does not. Product intent lives in chat history. Architecture notes fall behind. Reviewers can inspect the implementation diff, but they often cannot see whether the product promise, engineering contract, and repository workflow are still aligned.

Truthmark is built for that gap.

It is a Git-native workflow layer for AI-assisted software development. It installs repository-local truth workflows so AI agents can keep canonical truth docs aligned with functional code changes, while humans still review normal Git diffs.

Truthmark 2.2.0 takes a significant step forward: it separates product truth from engineering truth.

That may sound like a documentation detail.

It is not.

It is a workflow boundary for AI coding agents.

Why truth needs lanes

Most documentation systems treat “docs” as one surface.

That works until AI agents start using those docs as operational context.

A product promise and an implementation detail are not the same kind of truth.

A product doc should say what must be true, why it matters, who benefits, what boundary is being protected, and what success means.

An engineering doc should say how the repository currently realizes that promise: the behavior, contract, architecture, workflow, operations, tests, and source-backed implementation facts.

When those two kinds of truth collapse into one file, the result is usually weak in both directions.

Product truth becomes a summary of implementation mechanics.

Engineering truth becomes a detailed version of product rationale.

Neither is ideal for humans. Neither is ideal for agents.

Truthmark 2.2.0 introduces explicit product and engineering lanes so agents can reason about these surfaces separately.

The core rule is simple:

Product truth says what must be true and why.
Engineering truth says how the repository currently realizes it.

What is new in Truthmark 2.2.0

Truthmark 2.2.0 adds lane-separated truth surfaces under the Truthmark workspace.

By default, product truth lives under:

docs/truthmark/product

Engineering truth lives under:

docs/truthmark/engineering

Product truth currently uses product capability docs. These docs capture capability promises, users and value, capability scope, current product behavior, acceptance criteria, product decisions, engineering realization links, non-goals, and source references.

Engineering truth uses more specific engineering kinds:

engineering-behavior
engineering-contract
engineering-architecture
engineering-workflow
engineering-operations
engineering-test-behavior

This gives agents a stronger map of what they are editing.

A functional code change usually updates engineering truth first.

A product-lane change should only happen when the implemented behavior, product promise, capability boundary, or explicit product evidence supports it.

Both-lane work is possible, but it must write separate product and engineering docs and link them.

That is the important part.

The goal is not just to split folders.

The goal is to prevent agents from creating mixed documents that blur intent, implementation, and operational evidence.

Cross-lane traceability

Truthmark 2.2.0 adds explicit relationship metadata between product and engineering truth.

Product docs can declare which engineering docs realize them.

Engineering docs can declare which product docs they realize.

Conceptually:

# product truth
realized_by:
  - docs/truthmark/engineering/workflows/installed-workflow-runtime.md

# engineering truth
realizes:
  - docs/truthmark/product/capabilities/agent-native-workflow-injection.md

This creates a practical traceability layer.

A reviewer can start from a product promise and inspect the current engineering realization.

An agent can start from an implementation change and find the product capability it may affect.

The connection is committed to the repository. It is not hidden in model memory. It is not stored in a dashboard. It is not dependent on a live service.

It is just Git.

Why this matters for AI coding agents

AI agents need context, but context is not enough.

They also need boundaries.

Without boundaries, an agent asked to “update the docs” can easily do the wrong thing:

rewrite product intent as implementation detail
mix architecture with user-facing promises
append behavior to README indexes
create catch-all docs that nobody owns
update stale docs without checking code

Truthmark 2.2.0 pushes against that failure mode.

Before writing canonical truth docs, the workflow asks the agent to classify the work:

product-lane
engineering-lane
both-lane
ambiguous

If the lane is ambiguous, the agent should block or route the task through Truth Structure rather than creating a mixed document.

That is a deliberately conservative design.

Truthmark does not try to decide whether a product decision is commercially correct, valuable, prioritized, or desirable.

That judgment belongs to humans.

Truthmark focuses on a narrower workflow question:

Is the repository truth organized, routed, and evidence-backed enough for agents and reviewers to trust the next handoff?

Product truth is not a feature brochure

A product lane can be misunderstood.

Truthmark product truth is not marketing copy. It is not roadmap speculation. It is not a place for aspirational feature promises.

A product truth doc describes current product capability boundaries that are supported by repository evidence, explicit product instruction, or implemented behavior.

For example, a product capability doc can state:

Truthmark gives supported AI hosts explicit, committed workflow surfaces for Structure, Document, Sync, Preview, Realize, Check, and Portal.

That is product truth because it describes the user-visible capability.

The engineering lane then explains how the repository realizes it through generated skills, prompts, commands, managed instruction blocks, helper manifests, and host-specific workflow files.

The two lanes are related, but neither should be a copy of the other.

Engineering truth is not lower-status truth

The engineering lane is not just “implementation notes.”

It is the source-backed current realization of the product and system behavior.

Engineering truth owns things like:

current implementation behavior
API and CLI contracts
generated host surfaces
workflow execution models
architecture boundaries
operations
tests and invariants

For AI agents, that distinction is important.

When an agent changes functional code, the engineering truth is usually where the immediate sync happens.

When the change also affects a product promise or capability boundary, product truth can be updated too, but that update needs explicit support.

This keeps product docs from becoming automatic summaries of every implementation change.

It also keeps engineering docs from becoming product rationale documents.

The workflow model remains Git-native

Truthmark is still not a hosted service.

It does not add a database.

It does not require hidden memory.

It does not ask a reviewer to trust a chat transcript.

Truthmark installs workflow infrastructure into the repository.

That infrastructure includes:

route files
product truth docs
engineering truth docs
templates
managed instruction blocks
host-native skills
host-native prompts and commands
project agents
optional helper metadata

The CLI prepares and validates the repository.

The installed workflow surfaces are what agents use during work.

This distinction matters.

The terminal command truthmark check can validate repository truth health. But the AI-facing Truth Check workflow is an installed workflow surface that an agent can follow directly by reading the checkout.

Truthmark 2.2.0 continues to favor direct checkout inspection.

If the CLI is unavailable, an agent should still be able to inspect committed config, route files, truth docs, source files, templates, and tests directly.

Token-conscious workflow surfaces

Truthmark 2.2.0 also improves generated prompt and command surfaces for supported AI hosts.

The product direction here is straightforward: agents should not preload everything.

A workflow entrypoint should be small. Detailed procedure files should be loaded only when the workflow actually needs them.

That is why generated prompt and command surfaces now act as lightweight adapters.

They point to the canonical installed skill and support files instead of duplicating the full workflow body everywhere.

For example, a host command can say:

Use this prompt as a light-weight adapter for Truthmark Sync.

To run the full workflow, use the installed skill surface.

For the canonical workflow procedure, report template, and workflow-specific support files, read:
- SKILL.md
- support/procedure.md
- support/report-template.md

This reduces prompt bloat while preserving a complete workflow contract in the repository.

It is a practical tradeoff for real agent environments, where unnecessary tokens can crowd out the actual task context.

Supported agent hosts

Truthmark continues to generate host-native surfaces for multiple AI coding environments:

codex
opencode
claude-code
github-copilot
gemini-cli

Different hosts expose workflows differently.

Some use skills. Some use prompts. Some use commands. Some support project agents or subagents.

Truthmark does not force one runtime shape on every host. It generates the surface that fits the host while keeping the workflow contract consistent.

That is important because AI development teams are not standardizing on a single coding agent interface yet.

Truthmark treats the repository as the stable integration point.

The installed workflows

Truthmark includes several AI-facing workflows.

Truth Sync is the finish-time workflow after functional code changes. Code leads; truth docs follow.

Truth Document is for documenting existing implemented behavior. It is implementation-first and doc-only.

Truth Structure repairs routing and truth ownership. It is used when docs are broad, stale, catch-all, mixed-owner, or unrouteable.

Truth Preview is read-only. It helps an agent preview likely workflow routing, target docs, expected writes, or blocking ambiguity before edits.

Truth Realize is doc-first. Truth docs lead, and the agent updates code to match bounded current truth claims.

Truth Check audits repository truth health, routing, ownership, canonical docs, and evidence hygiene.

Truthmark Portal is a manual presentation workflow for generating a committed static HTML view of the truth docs when enabled.

These workflows are intentionally separate.

That separation is part of the product.

A sync workflow should not silently become a structure repair.

A preview workflow should not authorize writes.

A realize workflow should not rewrite truth docs while implementing them.

A check workflow should not replace normal tests or code review.

Each workflow has a boundary.

Quick start

Install Truthmark:

npm install -g truthmark

Create the repository config:

truthmark config

Install or refresh the workflow surfaces:

truthmark init

Validate the setup:

truthmark check

Then review the generated files before committing.

For an existing repository, the first useful workflow is often a structure pass:

/truthmark-structure split the broad repository area into auth, billing, and notifications

That gives later Truth Sync runs better destinations.

Why Truthmark is different

Many AI tools focus on producing the next answer.

Truthmark focuses on the next handoff.

That is a different product lane.

The question is not only:

Can the agent change the code?

The question is:

Can the repository still explain itself after the agent changes the code?

Truthmark makes that question concrete.

It gives agents committed workflow surfaces.

It gives reviewers normal Git diffs.

It keeps product truth and engineering truth separate.

It makes traceability explicit.

It treats repository state, not hidden memory, as the durable context.

That is the lane Truthmark is building in: Git-native truth infrastructure for AI coding agents.

Closing

AI-assisted development is moving from isolated prompts to ongoing repository work.

That shift changes what teams need.

They do not only need faster code generation.

They need governed handoffs.

They need evidence-backed repository context.

They need agent workflows that can scale without turning into broad rewrites.

Truthmark 2.2.0 is a step in that direction.

Product truth says what must be true and why.

Engineering truth says how the repository currently realizes it.

Agents use both.

Humans review the diff.

The repository carries its own truth.

Try it

npm install -g truthmark
truthmark config
truthmark init
truthmark check

GitHub:

https://github.com/merlinhu1/truthmark

Introducing Truthmark 1.4.0: Git-native truth workflows for AI coding agents

Merlin — Sat, 16 May 2026 15:23:03 +0000

AI coding agents are getting good at changing code.

That creates a new problem.

The code changes, but the repository often stops telling the truth.

The behavior moves ahead of the docs. Architecture notes become stale. Product decisions stay in chat history. Reviewers see the implementation diff, but not the context that changed around it.

Truthmark is built for that gap.

It is a Git-native, branch-scoped workflow layer for AI-assisted software development. It helps coding agents keep repository truth aligned with functional code changes, while leaving humans with ordinary Git diffs they can inspect.

The latest release, Truthmark 1.4.0, adds workflow verifier and writer agents. That makes the installed workflows more useful for larger repositories, where a single agent context can get crowded fast.

What Truthmark does

Truthmark does not try to be another AI model.

It does not host a service. It does not run a database. It does not add an MCP server. It does not ask your team to trust hidden memory.

Instead, it installs workflow infrastructure into your repository.

That infrastructure has two surfaces.

The first surface is the human-facing CLI. Maintainers use it to configure the repository, install workflow files, refresh generated surfaces, and validate the truth setup.

truthmark config
truthmark init
truthmark check

The second surface is AI-facing. Truthmark installs host-native workflow surfaces for coding agents. Depending on the host, these show up as skills, prompts, commands, managed instruction blocks, or project agents.

That distinction is important.

The CLI prepares the repository. The AI-facing surfaces are the runtime that agents use while doing the work.

The normal workflow

The default Truthmark path looks like this:

agent changes functional code
relevant tests run
Truth Sync checks mapped truth docs
truth docs update when needed
human reviews code diff + truth diff

The goal is not to create more documentation.

The goal is to make repository truth harder to skip.

When an AI agent changes behavior, Truthmark gives it a finish-time workflow guard. The agent checks the mapped truth docs before handoff. If the docs need to change, the change appears as a normal Git diff.

That makes the repository easier to review, easier to hand off, and easier to trust.

Why branch-scoped truth matters

A lot of AI tooling focuses on the next answer.

Truthmark focuses on the next handoff.

In real repositories, truth is not global in a simple way. Branches diverge. Architecture changes happen in stages. Product behavior may differ between a feature branch and main. A memory tool can help one user or one session, but it does not automatically give the reviewer a committed record of what the branch currently believes.

Truthmark keeps that context in the repository.

The route files, truth docs, generated workflow surfaces, and instruction blocks live with the branch. They can be reviewed, updated, reverted, and merged like other project files.

That is the point.

AI context becomes repository state.

What is new in 1.4.0

Truthmark 1.4.0 adds project-scoped verifier agents and a leased truth-doc-writer where supported by the host.

This gives the installed workflows a better way to handle bounded evidence work.

For example, a parent workflow can ask a verifier to inspect a specific route, a specific doc claim, or a specific truth-doc shard. The verifier stays read-only. It works inside a bounded assignment instead of wandering through the whole repository.

For document writing, the new leased writer model is intentionally strict. The parent workflow owns the lease, the write boundary, the final report, and the diff validation. The writer does not get broad permission to rewrite the repository.

That is the core idea behind this release:

delegate bounded evidence work
keep parent workflow control
validate the diff before accepting it

This matters because AI workflows often fail by becoming too broad. A task starts as “check this behavior” and turns into a vague repo-wide rewrite. Truthmark 1.4.0 pushes in the opposite direction. Smaller assignments. Clearer leases. Parent-owned acceptance.

Supported agent hosts

Truthmark currently supports generated surfaces for:

codex
opencode
claude-code
github-copilot
gemini-cli

Different hosts expose workflow surfaces differently.

Codex, Claude Code, and supported Copilot IDEs can expose /truthmark-* style workflows. OpenCode uses /skill truthmark-*. Gemini CLI uses /truthmark:*.

The exact files generated depend on your .truthmark/config.yml.

By default, Truthmark includes every supported platform. In a real project, you should remove the platforms you do not use, then rerun:

truthmark init

The workflows

Truthmark installs several AI-facing workflows.

Truth Sync is the normal finish-time workflow after functional code changes. It is code-first. The code leads, and mapped truth docs follow.

Truth Document is for implemented behavior that already exists, but is not documented well enough. It is implementation-first and doc-only. It should not change functional code.

Truth Structure repairs or splits broad routing. This is useful after initialization, because a new repository often starts with one broad route that needs to become real product, service, or domain areas.

Truth Preview is read-only. It lets an agent inspect likely routing before edits.

Truth Realize is doc-first. A truth doc leads, and the agent updates code to match it.

Truth Check is the AI-facing audit workflow. It is separate from the terminal command truthmark check, even though the names are related.

That boundary is deliberate. Humans run the CLI. Agents run the installed workflow surfaces.

Quick start

Install Truthmark in the repository you want to initialize.

cd /path/to/your-repo
npm install -g truthmark

Create the repository truth contract.

truthmark config

Review the generated config.

.truthmark/config.yml

Then install the workflow surfaces.

truthmark init

Validate the setup.

truthmark check

After that, review the generated files before committing. You will usually see route files, truth-doc scaffolding, templates, managed instruction blocks, and host-specific workflow surfaces.

On an existing repository, the first useful agent task is often a structure pass:

/truthmark-structure split the broad repository area into auth, billing, and notifications

That gives Truth Sync better destinations later.

Why I think this matters

AI-assisted development is moving from novelty to daily practice.

The hard part is no longer whether an agent can produce a change. The hard part is whether the team can still understand the repository after many agent-produced changes.

Truthmark is an attempt to make that problem concrete.

Not by adding a dashboard.

Not by adding another memory layer.

Not by asking reviewers to trust the chat transcript.

The repository should carry its own truth. Agents should read it. Agents should update it when their work changes it. Humans should review the result in Git.

That is what Truthmark is for.

Truthmark 1.4.0 takes another step in that direction by making the workflow surface more scalable. Verifier agents can inspect bounded evidence. Leased writer agents can handle bounded doc shards. Parent workflows still own the final judgment.

That balance matters.

AI agents can move fast, but the repository still has to be governable.

Try it

npm install -g truthmark
truthmark config
truthmark init
truthmark check

GitHub: https://github.com/merlinhu1/truthmark

If you try it on an existing repository, start small. Initialize the repo, review the generated config, split the default route into real ownership areas, then let Truth Sync handle the next functional code change.