Concepts ​

The governance model behind Tenetora: what the project record is, how lifecycle entries, deterministic control, and evidence fit together, and where the model deliberately stops.

Audience ​

Users who want to understand what Tenetora governs — and what it refuses to do — before trusting it with a real project.

Task path ​

1. Start with the four parts below: record, lifecycle, control, evidence.
2. Read the three machine-side boundaries: explicit enablement, local-environment protection, and registry hygiene.
3. Read how one conversation safely moves across models without splitting the goal.
4. Learn what a completion claim proves and what invalidates it.
5. Close with the explicit non-goals, so the boundary is known before the first task.

The four parts ​

1. Project record ​

Problem: tool-specific instruction files describe fragments of the project; a new agent cannot tell current rules from historical notes.

Mechanism: tenetora-init extracts existing instructions and project evidence into .tenetora/ — stable rules, workflows, project facts, executable guardrails, current state, and evidence pointers, with current guidance separated from history and temporary candidates.

Observable result: tenetora validate --path . resolves the runtime contract, required structure, source evidence, and tool entries.

Boundary: initialization installs no plugins, decides no product policy, and never presents inferred architecture as confirmed fact; unknowns stay labeled.

2. Lifecycle entries ​

Problem: every tool invents its own task-start and completion habits.

Mechanism: skills route the model into the same project workflow — tenetora routes unclear requests, tenetora-init builds the baseline, tenetora-update refreshes governance after change, tenetora-align runs explicit decision alignment, tenetora-loop runs one bounded check-fix-verify cycle, tenetora-audit evaluates stability and evidence quality, and tenetora-prompt-guard inspects untrusted content.

Observable result: the agent can name which lifecycle boundary a task passed through, and the governance trail records it.

Boundary: the lifecycle makes boundaries explicit; the model still reasons about the product and writes the implementation.

3. Deterministic control ​

Problem: checks that depend on the agent remembering a sentence get skipped under pressure.

Mechanism: the tenetora CLI routes tasks to rule slices, validates the record and its evidence, runs guardrails, records shared-contract impact, checks action boundaries (commit, external input, rules, alignment, claim), and inspects effective plugin, hook, runtime, version, and ownership sources.

Observable result: tenetora status and tenetora doctor report evidence levels — a file existing is never reported as a runtime being active.

Boundary: the CLI reports capability and remaining uncertainty; it does not authorize high-risk actions.

4. Evidence and recovery ​

Problem: a "done" report cannot be reproduced, and an upgrade destroys user-owned state.

Mechanism: verification claims record which command passed, for which project, session, and goal; project-record updates leave reviewable change artifacts; installation and migration keep backups with bounded rollback.

Observable result: a passed completion returns an ah-claim-... proof; a newer failure or a changed worktree invalidates it.

Boundary: a claim proves the declared command and its bindings — not that the command was a complete test strategy.

Governance is explicit per project ​

Problem: a globally installed hook runtime should not impose project rules on scratch workspaces used for notes, chat, or plain documents.

Mechanism: a global install provides the hook runtime only; project governance is enabled explicitly. A Git worktree is governed solely by the .tenetora/ at its own root, and the machine home never counts as a project harness. A legacy .harness/ still triggers a migration reminder; an explicit decline records only bounded machine-local state and deletes nothing.

Observable result: a workspace with neither .tenetora/ nor .harness/ receives no route/rules context, no initialization reminder, no commit gate, and no external-input gate. Entering a submodule or an independent nested repository establishes a fresh boundary — parent rules never govern the child's source.

Boundary: a global install never initializes projects automatically and never weakens governance inside an explicitly initialized project.

Local environment protection ​

Problem: a project depends on .env, local configuration, certificates, or other machine-only files that must never enter Git or shared evidence.

Mechanism: tenetora local-env --allow registers a project-relative path without storing its contents. status and doctor check existence only; the commit guard merges the registry with its built-in sensitive-path rules; and when the host supplies structured PreToolUse data, the hook also denies high-confidence delete, move, truncate, write, or edit operations against registered paths.

Observable result: a missing registered path produces an explicit diagnosis with a checkpoint next step, and a destructive tool call receives a deny instead of silently removing the file.

Boundary: protection applies to registered paths only. A host that cannot reliably resolve a tool name and path is never blocked speculatively; the built-in staged-sensitive-file checks still apply everywhere.

Registry hygiene ​

Problem: machine-level observations can outlive the projects they describe after an uninstall or a move.

Mechanism: tenetora installations list marks entries stale, and stale entries past the bounded retention window become expired. tenetora installations prune --expired is always an explicit action.

Observable result: stale and expired states are visible before any cleanup, and pruning removes registry metadata only.

Boundary: nothing deletes project directories, .tenetora/, local environment files, or third-party configuration in the background.

One conversation, several models ​

A provider can rate-limit one model mid-task while the user keeps the same conversation; the host may also route the next execution to another provider. Tenetora separates model continuity from conversation isolation:

• One conversation_continuity_id identifies the conversation allowed to continue the goal — one durable goal per continuity.
• Each provider or model run is recorded as a separate execution_attempt_id with its own provider, model, and status (running, completed, failed, cancelled, or rate-limited).
• A rate-limited attempt does not close the alignment session; the next model appends a new attempt instead of creating a second goal.
• Another conversation cannot inherit the goal or reuse its completion claim.
• A stale concurrent write is rejected by the session revision check, never silently overwritten.
• Missing continuity ends read-only blocked; ownership is never guessed.

tenetora alignment --execution-list --conversation-continuity-id <id> --json shows the ordered attempts. Continuity preserves governance identity, not hidden model reasoning — the next model still reads the current goal, state, verification result, and next action.

What a completion claim proves ​

Claims come in four kinds: partial-verification, completion, blocked, and failed. A completion claim binds the declared full verification command to the project, the owner-bound session and conversation, the goal fingerprint, and the Git worktree state. A different goal, identity, project, or command — or a newer failure or a changed worktree — invalidates the evidence. A local check stays a partial claim and can never satisfy the completion gate.

What Tenetora does not do ​

• It is not a coding model and does not replace the host agent.
• It is not a project-management system or an issue tracker.
• It does not make ambiguous product decisions for the user.
• It does not execute instructions embedded in an external report merely because they look authoritative.
• It does not claim every host has identical runtime hook capability.
• It does not turn a passing subset of tests into proof of a complete task.
• It does not delete third-party hooks, plugins, rules, or legacy directories without ownership evidence.
• Its CLI and hooks do not spawn subagents; the host owns actual dispatch.

Limitations ​

• Tenetora cannot transfer a model's hidden reasoning across a handoff; the next model re-reads the goal, state, and evidence.
• Impact evidence is bounded by the analysis tools available; references no tool can see are never presented as proven.
• Prompt guard is a mechanical first line; novel social engineering still needs a qualified reviewer or an explicit human decision.

Next steps ​

• Apply the model in Quickstart.
• See the trust-boundary detail on Security.