# RENAR — Operational Standard for the AI Agent

**Version 1.0** | Authors: Vadim Soglaev, Andrey Yumashev | [renar.tech](https://renar.tech) | CC BY-SA 4.0

> **What this file is.** This is a **self-sufficient** working edition of the RENAR standard for an AI agent. It collects everything the agent needs to do requirements engineering by RENAR at 100% — without consulting any other document. Download this file, place it beside the agent, and say: "study this standard and work by it."
>
> Chapters the agent does not need at work (history, maturity metrics, comparisons with other methodologies, substrate details) are omitted; the needed ones are reworked and compressed to an operational minimum. For a formal dispute over the exact wording of "MUST / SHOULD / MAY", the primary source is the full normative corpus at [renar.tech](https://renar.tech); but for everyday work this file is enough.

---

## 0. How to use this file

1. Read sections 1–2: the principle and the artifact map. This is the coordinate system.
2. When you receive a TZ from the client, follow the workflow (section 4).
3. Do not break the hard rules (section 12) or the closed lists (section 11) — they are not subject to local extension.
4. Take the recording forms (frontmatter) from section 13 — they are normative.

You are an **executing agent**: you produce and maintain artifacts, but you do not own them and you do not sign. The owner and signatory is a human (section 10).

---

## 1. The core principle: the source of truth is the requirements, not the code

RENAR inverts the usual order: **the source of truth (SoT) about system behavior is the requirements hierarchy**, while code is a derived implementation artifact. Requirements define behavior → the agent produces the implementation from the requirements → tests verify the implementation against the requirements. Not the other way around.

It is **forbidden** to reconstruct the meaning of a requirement from finished code and retroactively fit `SR`/`SPEC` to the implementation (source-of-truth inversion). The exception is a justified bug-fix, where the code is repaired to match the requirement, not the requirement to match the code.

From this follows a **double inversion**: the contractual source (TZ) → SoT (the RENAR description of `BR`/`SR`/`SPEC`/`TR`/`TC`) → code.

---

## 2. Artifacts and hierarchy

```text
                      internal circuit (interpretation)
client TZ ──► ADAPT ──► BR ──► SR ──► SPEC ──► TC ──► QG ──► release
(immutable) (as needed)  └──────► TR ─────┘   (tests)
     │          ▲
     │          │ decided-in
     ▼          │
   ACTZ ────────┘        contractual circuit (commitments)
(protocol, 2 signatures)
     │
     ▼
Effective TZ = TZ + all signed ACTZ ──► AT (acceptance against the contract)
```

| Artifact | What it is | Key point |
|---|---|---|
| **TZ** | The client's contractual input in business language | **Immutable** after registration |
| **ADAPT** | The **internal** interpretation of the TZ (forward interpretation + backward findings) | Created **reactively** (section 5), 0..N per TZ; signed by the **architect only** |
| **ACTZ** | The TZ clarification protocol: decisions put to the client | **Dual** signature, contractual weight (section 5A); 0..N per TZ |
| **Effective TZ** | The initial TZ (with annexes) + all signed ACTZ | The benchmark for delivery and acceptance (section 5A.4) |
| **BR** | Business Requirement: who, what, **why** (business goal) | Has a lifecycle and provenance |
| **SR** | System Requirement: what the system does | `parent` — exactly one BR |
| **TR** | Task Requirement: an implementation task (Goal + acceptance criteria) | Lives in the tracker, not a separate file; references SR/SPEC |
| **SPEC** | Specification — an axis parallel to the requirements | **11 types, closed list** (section 7) |
| **TC** | Test Case as a standalone artifact | A pos/neg pair is mandatory (section 8) |
| **AT** | The acceptance test **against the contract**: derived only from the effective TZ | Isolated generator agent (section 8A) |
| **AR** | The adversarial-review record (evidence) | Not a node of the requirements graph (section 5.2) |

**Two circuits and the boundary between them.** Everything shown to the client and approved is a **commitment** (ACTZ). Everything not shown is **interpretation** (ADAPT). The boundary is drawn **by audience**, not by the content of an entry; the criterion is binary and checkable: the fact "put to the client and signed" either exists or it does not.

**Provenance is mandatory.** Every `BR`/`SR`/`SPEC` has a `source`: either through ADAPT (`source.adapt` + `source.adapt-section`) or directly (`source.tz-section` + `source.adversarial-review-ref`). The `source.tz-section` field is **always** mandatory. An artifact without a source is forbidden.

**A RENAR description is always complete, never incremental.** Before changing the system, a new complete version of the RENAR description is created, and only then does the agent change the implementation. Only the TZ is incremental (delta-TZ); the full picture is reassembled by the agent in whole.

---

## 3. Minimum Viable RENAR (MVR) — seven mandatory statements

An implementation that breaks even one of them **does not conform** to RENAR. The list is closed.

1. **MVR-1 — SoT inversion.** Requirements are the source of truth; reverse-engineering behavior from code into SR without a bug-fix is forbidden (section 1).
2. **MVR-2 — substrate V1–V6.** The substrate MUST provide: immutable history (V1), atomic change unit (V2), diff & review (V3), branching/change-set (V4), cross-substrate version pin (V5), author + timestamp (V6).
3. **MVR-3 — reactive stage-independent ADAPT (0..N per TZ).** ADAPT is created if and only if converting the TZ → requirements at any stage produces a gap between the client's language and the language of the requirements (section 5). When a gap exists, the ADAPT MUST reach `approved` with the **architect's signature**; the client's decisions are recorded in **signed ACTZ** (section 5A), and the benchmark for delivery and acceptance is the **effective TZ** = the initial TZ + all signed ACTZ.
4. **MVR-4 — 11 SPEC types, closed list** (section 7).
5. **MVR-5 — pos/neg TC pairing** for every normative statement (section 8).
6. **MVR-6 — closed list of Quality Gates** QG-0..QG-2 as `required`; QG-3/QG-4 — `declared` or `absent` (section 9).
7. **MVR-7 — conformance manifest** with simultaneous `renar-version` + `senar-version` + `level` + confirmation of the mandatory clauses (section 14).

---

## 4. Workflow

### 4.1 Initial TZ

1. **Import the TZ.** Register the TZ as an immutable document (`TZ-YYYY-NNN`), capture the client's signature (author + timestamp).
2. **Adversarial review of the TZ — always mandatory.** A reviewer (a separate agent on a **different model**) issues a formal verdict: "findings present" or "no findings, no clarifications." Silent skipping is forbidden; the verdict is recorded as evidence.
3. **ADAPT — per the review result** (section 5). Findings present → an ADAPT is created and approved by the **architect's signature**. No findings → no ADAPT is created.
4. **ACTZ — for every finding that needs the client's word** (section 5A). The Architect puts a clarification protocol to the client; after the **dual signature** the finding gets `decided-in: ACTZ-NNN §M` and moves to `resolved`. Without a signed ACTZ the ADAPT is not approved.
5. **Decomposition:** ADAPT/TZ → `BR` (business goal) → `SR` (system behavior). Each requirement states its `source`.
6. **Specifications:** `SR` → `SPEC-<TYPE>` with `constrained-by[]` links.
7. **Tasks:** `SR`/`SPEC` → `TR` (Goal + acceptance criteria) in the tracker.
8. **Tests:** for every normative statement — a `TC` pair (positive + negative). A test is frozen (`ready`) **before** implementation and is written by an agent **other than** the one writing the code (section 8.2).
9. **Acceptance tests:** an isolated agent derives `AT` from the **effective TZ** (section 8A).
10. **Gates:** run `QG-0 → QG-1 → QG-2`; before delivery — the release acceptance gate "all AT `passing`" (section 9).

At stages 5–8 the adversarial review MAY fire **again**: if decomposition surfaces a question rooted in the TZ, a **new** ADAPT is created at that stage (stage independence, section 5). ACTZ is stage-independent too: a late protocol (for example, from working through the client's remarks after a demonstration) is the normal case.

### 4.2 Delta-TZ (incremental change)

1. The client registers and signs a delta-TZ (`TZ-YYYY-NNN-delta-N`) as a new immutable document.
2. Adversarial review of the delta-TZ → verdict.
3. Findings present → a delta-ADAPT (`ADAPT-NNN-delta-N`, `parent-adapt`), signed by the architect; the client's decisions on the findings — in new ACTZ with a dual signature. No findings → no delta-ADAPT is created.
4. Reassemble a complete new version of the RENAR description of the affected area; make the changes in the implementation.
5. Regenerate the `AT` from the new revision of the effective TZ (section 8A.3).

**Example of a trivial delta** (rename the field `username` → `email` on a form): the term is unambiguous, the scope is clear, there are no questions for the client → verdict "no findings" → no delta-ADAPT is created; the affected `SR` gets `source.tz-section: TZ-...-delta-1 §1`, the `parent` BR is unchanged.

### 4.3 Points of human approval (delegation to the agent)

The agent performs most steps itself, but **does not approve** — delegation has fixed points where a human is required:

| Step | What the agent does | What the human approves |
|---|---|---|
| Adversarial review | A critic agent (a different model) issues the verdict | The Architect records the verdict as evidence |
| ADAPT | The agent prepares a draft (forward interpretation + findings) | **The Architect's signature** (QG-3). There is **no** client signature here |
| ACTZ | The agent prepares the draft decisions; the Architect puts them to the client | **Dual signature:** client + vendor |
| QG-0 Approval | The agent creates `BR`/`SR`/`SPEC` with provenance | The Architect approves the transition to `approved` |
| `implementation-originated` | The agent marks the internal technical detail it added | A human supervisor explicitly approves the addition (section 6.3) |
| Release acceptance gate | The agent presents all `AT` in `passing` | The Architect admits the product to the trials |
| QG-4 Acceptance | The agent presents the result | The Stakeholder accepts the business outcome |

The agent never signs and never declares itself the owner of an artifact (section 10). If human approval is not obtained, the artifact stays in `draft` and transitions are blocked by the substrate.

---

## 5. ADAPT in full

### 5.1 Why

A TZ is written in business language and signed as a contract — it cannot be edited. Turning it into precise requirements directly often does not work out: the TZ is silent about something important, contradicts itself, or uses a term with a double meaning. Silently filling in for the client is also not allowed — that is the leakage of someone else's guesswork into the requirements. ADAPT is the bridge across this gap: a **forward interpretation** ("we understood section §4.2 of the TZ this way") and **backward findings** ("§4.3 sets no deadline — please clarify").

**ADAPT is an internal artifact.** Its audience is the engineer, the AI agent, the adversarial reviewer, and the verifier. The client does not see an ADAPT and **does not sign** it. Questions go to the client and come back as decisions **not through ADAPT but through ACTZ** (section 5A) — a separate document of the contractual circuit.

### 5.2 When to create one and when not (reactivity)

An ADAPT is created **if and only if** at least one holds:

- a **backward finding** in one of the 7 categories is discovered (section 5.3);
- a **term** needs clarification (no unambiguous engineering reading);
- the **scope** of work needs clarification.

If the review verdict is "no findings, no clarifications", no ADAPT is created: `BR`/`SR`/`SPEC` reference the TZ directly via `source.tz-section`, and the verdict is recorded as evidence (`source.adversarial-review-ref`).

**AR — the adversarial-review record.** In **both** outcomes the review result is issued as an AR (`AR-NNN`) — an evidence record, immutable once issued. Mandatory fields: `tz-ref`, `trigger-stage`, `reviewer` (the model MUST differ from yours), `verdict` (`findings-present` | `no-findings`), `produces-adapt[]` (non-empty when `findings-present`), `status` (`draft` -> `issued` -> `superseded`), signature. `source.adversarial-review-ref` MAY reference **only** an AR in status `issued` with the `no-findings` verdict. AR is not a requirement and not a graph node: it is not decomposed and not covered by TC.

### 5.3 The seven backward-finding categories (closed list)

| ID | Category | What is recorded |
|---|---|---|
| `contradiction` | Contradiction | Internal contradictions of the TZ (§A vs §B) |
| `gap` | Gap | The TZ is silent about something without which implementation is impossible |
| `hidden-assumption` | Hidden assumption | An engineer's assumption that may be wrong |
| `feasibility` | Feasibility | Technically infeasible or disproportionately expensive |
| `regulatory` | Regulatory | Touches legislation / compliance |
| `terminology` | Terminology | An unclear term with several meanings |
| `scope` | Scope | An unclear boundary of work |

Each entry has a stable `B-NNN`, immutable after creation.

### 5.4 Stage independence and multiplicity (0..N)

The ADAPT trigger is **not tied to TZ import**. A question for the client rooted in the TZ may surface later — during `BR → SR → SPEC` decomposition or `TC` development. Then a **new** ADAPT is created at that stage (the `trigger-stage` field). A single TZ has **zero or more** root ADAPTs — this is the normal case.

If the uncertainty is rooted **in the decomposition** (and not in the TZ), it is resolved by clarifying `SR`/`SPEC` **without** an ADAPT. An ADAPT arises only when the root is in the language or intent of the TZ.

### 5.5 Entry lifecycle and approval

Every backward finding goes through: `open → asked-to-client → answered → resolved → frozen` (with a possible return `revised → asked-to-client`). The meaning of the statuses is tied to ACTZ:

| Finding status | What it means |
|---|---|
| `open` | Recorded; not put to the client |
| `asked-to-client` | Put to the client **as part of an ACTZ** (`status: sent`); awaiting signature |
| `answered` | The client made a decision; it is recorded as a clause of a **signed** ACTZ (`status: signed`) |
| `resolved` | The decision is integrated into the forward interpretation; the entry carries `decided-in: ACTZ-NNN §M` |
| `revised` | The decision is vague; the repeat question goes out as a **new** ACTZ; return to `asked-to-client` |
| `frozen` | After ADAPT approval — no changes are possible |

**`decided-in` is mandatory.** Every finding that needs a client decision MUST carry `decided-in: ACTZ-NNN §M` — a reference to a clause of a **signed** ACTZ. A reference to an unsigned ACTZ (`draft`/`sent`), as well as a dangling reference, is **fatal**. Approval of an ADAPT (QG-3) is forbidden while any entry is in `open`/`asked-to-client`/`answered`/`revised` — all MUST be `resolved`, that is, each MUST have a signed client decision.

**The reverse direction is mandatory too.** A decision taken by the client on their own initiative (an ACTZ with no parent finding) MUST be **reflected in the ADAPT**. A signed ACTZ not reflected in any ADAPT is **fatal**: it is a commitment absent from the requirements.

**The ADAPT signature is the architect's only.** An ADAPT moves `answered → approved` on the Architect's signature: all findings are worked through (each `resolved` and carrying `decided-in` to a signed ACTZ), and the forward interpretation is technically feasible. **There is no client signature on an ADAPT** — client commitments are carried by ACTZ. After approval an ADAPT is **immutable**.

### 5.6 Changes to an approved ADAPT — three mechanisms

A frozen ADAPT is not edited. Changes happen only by adding a new artifact via one of three paths:

| Mechanism | When | Signature |
|---|---|---|
| **delta-ADAPT** | a delta-TZ arrived (the contract changed) | the Architect signs the ADAPT; the client's decisions go into new ACTZ (dual signature) |
| **errata-ADAPT** | the prior interpretation was **wrong** | the Architect. If the correction touches a decision from a signed ACTZ, a **new ACTZ** with a dual signature is mandatory |
| **superseding ADAPT** | the prior decision was **correct** but later refuted by new requirements | the Architect. If the superseded decision had a contractual outcome (a clause of a signed ACTZ), the cancellation is formalized by a **new ACTZ** with a dual signature |

**Supersession.** A new `ADAPT-NNN` with the field `supersedes: ADAPT-MMM` and a mandatory `supersession-rationale` (a reference to the conflicting `BR`/`SR`/`SPEC` and its source). The superseded ADAPT moves to the terminal state **`superseded`** (distinct from `obsolete`), stays immutable, and is kept for audit; it gets `superseded-by: ADAPT-NNN`. All derivatives with `source.adapt: ADAPT-MMM` MUST be repointed to the superseding ADAPT or re-derived — a **dangling reference to a `superseded` is forbidden**. There is no separate gate — it goes through the same QG-3.

### 5.7 AI and adversarial review

The agent creates an ADAPT **draft** automatically (forward interpretation by section, an attempt to find contradictions/gaps/unclear terms, an initial term mapping). This is a starting point, not the final. A separate critic agent on a **different model** looks for what was missed. The client **does not talk to the AI directly**: the Architect aggregates and rephrases the questions; the client is presented with a prepared list of decisions (an ACTZ), not with the raw output of an agent.

---

## 5A. ACTZ — the TZ clarification protocol

### 5A.1 What it is and how it differs from ADAPT

**ACTZ** (`ACTZ-NNN`, Agreed Clarification of TZ; in contract practice — the "**TZ Clarification Protocol No. N**") is an artifact of the **contractual circuit**: a batch of questions, proposals, and decisions put to the client and signed by **both** parties.

| | **ADAPT** — interpretation | **ACTZ** — commitment |
|---|---|---|
| Content | Translation of the TZ into engineering language, term mapping, completed scenarios, backward findings | Questions, proposals, and decisions for the client. The language of commitments ("the button is called X"), not of interpretation |
| Audience | The engineer, the AI agent, the reviewer, the verifier | The client and the parties to the contract |
| Signature | **The Architect only** | **Dual**: client + vendor |
| Weight | The internal circuit | **Contractual** |

The criterion is binary: "put to the client and signed" either holds or it does not. The argument over the materiality of a change ("is this a clarification or already a change?") disappears by construction — do not reason about it; look for a signed ACTZ.

### 5A.2 Origin and multiplicity

Two normal sources:

1. **From a backward finding.** A finding that needs a client decision is put into an ACTZ; after signing it gets `decided-in: ACTZ-NNN §M`.
2. **On the client's initiative, with no finding.** The client proposes a decision themselves. Such an ACTZ references only the TZ; it has no parent finding. After signing, the decision **MUST** be reflected in the ADAPT.

Cardinality: **TZ : ACTZ = 1 : 0..N** (zero protocols is lawful — a conversion with no questions produces no documents); **ADAPT : ACTZ = 1 : 1..N** (the findings of one ADAPT are closed by several protocols across rounds).

ACTZ is **stage-independent**: a late protocol — from working through remarks after a demonstration — is the normal case, not an exception.

### 5A.3 Lifecycle

```text
draft → sent → signed → superseded
```

| Status | What it means |
|---|---|
| `draft` | Being prepared; not put to the client. Referencing it from `decided-in` is **forbidden** |
| `sent` | Put to the client, awaiting signature |
| `signed` | Signed by both parties; **immutable**, carries contractual weight |
| `superseded` | A later signed ACTZ cancelled the decision; a terminal state, kept for audit |

A signed ACTZ is not edited. A correction happens only through a new ACTZ that cancels the prior decision (`superseded-by`).

**Annexes to the TZ** (mapping tables, reference lists, mock-ups) are an integral part of the TZ and are not separately addressable entities. Clarifying an annex is formalized as a **new version of the annex**, attached to an ACTZ (`annexes[]`) and approved by the same dual signature.

### 5A.4 The effective TZ — the benchmark for delivery and acceptance

> **Effective TZ = the initial TZ (with annexes) + all signed ACTZ.**
> On divergence, the **later signed** document prevails.

The acceptance tests `AT` (section 8A) are derived against the effective TZ, and the acceptance report is built from it.

**ADAPT is not part of the acceptance benchmark.** The client answers only for what they signed and understood; the internal interpretation is taken out of the contractual circuit entirely.

---

## 6. Requirements hierarchy and provenance

- **BR (Business Requirement)** — captures the business goal of a group of related SR: who, what, **why**. When an SR changes, the link to the business need is visible.
- **SR (System Requirement)** — what the system does; `parent` — exactly one BR (multiple parents are forbidden).
- **TR (Task Requirement)** — an implementation task in the tracker: Goal + acceptance criteria. References `SR`/`SPEC`, **not** ADAPT directly — all interpretations are already in SR/SPEC.

### 6.1 System levels and references to higher requirements

Every artifact carries a `scope` with a level. There are three levels:

| Level | What it is | Who can be at the level |
|---|---|---|
| `system` | The information system as a whole | `BR`, `SR`, `TR` |
| `subsystem` | A technical division: a component, service, team | `BR` (if the subsystem is a standalone product), `SR`, `TR` |
| `module` | A part of a subsystem fit for one task | `SR`, `TR` (but **not** `BR` — a business goal is not formulated at the module level) |

The base decomposition `BR → SR → TR` works within a single level. For composite systems the levels link **upward**:

- **A subsystem as a technical division** (not a standalone product): has no `BR` of its own — it inherits the system's business goal; the subsystem's `SR` has `parent` = the system's `BR`.
- **A subsystem as a standalone product** (its own business owner): has its own root `BR`. That `BR` **MUST** declare `implements[]` — a reference to the parent system's `BR` that it elaborates. Without it the link between the subsystem tree and the system tree is lost, and the traceability of "why this subsystem exists" becomes irrecoverable.

The obligation to reference upward lies on the subsystem's `BR` (via `implements[]`), not on the parent: the system does not know in advance which subsystems will implement it — they declare their affiliation. The `implemented-by[]` field on the parent `BR` is assembled by the substrate automatically from the back-references.

**implements-edge (subsystem → system).** `implements[]` is an array of `id + scope.system` pointing at the parent system's `BR`. It is a typed cross-level edge (**not** a parent): cardinality 0..N, acyclic, target in status `approved`+. One subsystem `BR` may elaborate several system `BR`. The ban on multiple `parent`s does **not** apply to this edge — it is of a separate type.

### 6.2 Artifact storage layout (informative, substrate-dependent)

> This section is **informative**: RENAR does not normalize the file layout — the substrate may be a file system, a database, a tracker, or a combination. Below is an **example** layout on a file-based substrate; an organization is free to arrange storage differently, as long as the `parent` / `source` / `implements[]` / `constrained-by[]` links and the machine-readability of the graph are preserved.

A convenient reference point for a file-based substrate is a layout by systems and levels, with TC next to the verified artifact:

```text
<requirements-root>/
├── tz/                          # immutable TZ and delta-TZ
│   ├── TZ-2026-001.md
│   └── TZ-2026-001-delta-1.md
├── adapt/                       # ADAPT (0..N per TZ), immutable after frozen
│   └── ADAPT-001.md
├── <system>/
│   ├── br/                      # BR at the system level
│   │   └── BR-01.md
│   ├── sr/
│   │   └── SR-01.md
│   ├── spec/                    # SPEC of all 11 types
│   │   ├── SPEC-API-01.md
│   │   └── SPEC-DATA-01.md
│   ├── tc/                      # TC next to its scope; pos/neg pairs together
│   │   ├── TC-01.md
│   │   └── TC-01-neg.md
│   └── <subsystem>/             # a standalone product — its own tree
│       ├── br/                  # subsystem BR with implements[] to system BR
│       │   └── BR-01.md
│       ├── sr/
│       └── tc/
└── RENAR-CONFORMANCE.yaml       # conformance manifest (section 14)
```

There is no TR here: a TR lives in the task tracker, not as a separate file (section 2). File names = the artifact `id` — this gives a stable reference that survives a title rename.

**Trace chain** (read-side) has two valid variants: through ADAPT (`source.adapt`) or directly from the TZ (`source.tz-section` + `source.adversarial-review-ref`). Both are machine-readable. A dangling reference to a `superseded` ADAPT makes the chain invalid.

### 6.3 A requirement originated by the implementation (`source: implementation-originated`)

While implementing a task you routinely add **internal technical details** that are not in the requirements: a defensive input check, an edge-case handler, logging. Demanding an ACTZ with a client signature for every such detail is an absurd ceremony — and it is exactly what pushes people toward silently fitting the requirements after the fact. Hence a **narrow** lawful class: `source: implementation-originated`.

| What | Where |
|---|---|
| **Behavior observable by the client** (a screen, a field, a message, a deadline, a format, the scope of delivery) | **Only** through the contractual circuit: ADAPT + ACTZ with signatures. There are no relaxations |
| **An internal technical detail with no client-observable behavior** | `source: implementation-originated` is allowed |

The boundary is **observability by the client**, not the size of the change. Doubt is resolved in favor of the contractual circuit.

The mandatory harness for such a requirement (all five items):

1. **Provenance**: a reference to the implementation change unit that produced it, and a justification of why it is needed.
2. **Human approval**: an explicit approval by a supervisor. The agent cannot legalize its own addition.
3. **A TC before the merge**: the covering test exists and passes before the change is included.
4. **A killed mutant**: such a TC cannot have a red history (the test is written after the code and is born green) — its bite is proved by a **mutation check** (`mutation-check.mutants-killed ≥ 1`). Without a killed mutant the TC is not evidence (section 8.2).
5. **A counter in the drift metrics**: a rising share of `implementation-originated` is a signal that the requirements process is leaking, and it MUST be visible.

What remains forbidden: silently fitting an existing `SR` to the behavior of the code (a breach of MVR-1) and using the class for client-observable behavior (non-conformance: a commitment to the client cannot arise from code).

---

## 7. Specifications (SPEC) — eleven types, closed list

A SPEC type MUST belong to the list of eleven. Creating new types locally is forbidden.

| Type | Purpose |
|---|---|
| `SPEC-ARCH` | Architecture: components, boundaries, decisions |
| `SPEC-API` | Interface contracts (endpoints, methods, formats) |
| `SPEC-DATA` | Data models, schemas, migrations, classification |
| `SPEC-INT` | Integrations with external systems |
| `SPEC-PROC` | Processes, workflow, orchestration |
| `SPEC-UI` | User interface, screens, behavior |
| `SPEC-AI` | AI components: model, risk class, judge isolation |
| `SPEC-SEC` | Security: threats, controls, requirements |
| `SPEC-OPS` | Operations: deployment, monitoring, SLO |
| `SPEC-TEST` | Test environments and data: topology, emulators and sandboxes of external systems, run configuration, datasets, anonymization |
| `SPEC-DOC` | Deliverable project documentation: composition, structure of each document, verifiable requirements for it |

A SPEC is an axis parallel to the requirements. The link to a requirement is a typed `constrained-by[]` edge (an SR is constrained by specifications). The `depends-on` graph between SPECs MUST be acyclic (a DAG).

---

## 8. Test cases (TC)

A TC is a standalone artifact with its own lifecycle, not a line in code. For every normative statement of a verified artifact that is covered by at least one TC, a paired **negative** TC **MUST** exist. The exception is a statement that itself describes a negative invariant.

- `verifies[]` points at the verified artifact and its version; the reverse link `verified-by` is symmetric.
- `requirement-version` is pinned: when the requirement version increments, the TC moves to the appropriate state (staleness detection).
- An automated TC (`automation.status: automated`) MUST have a non-empty `automation.location` and a **mandatory** `automation.kind` (`dynamic` | `static`; `static` — when the runner is a static analyzer).
- For `SPEC-AI`: the judge model MUST differ in vendor from the production model (evaluation isolation, P7).
- Optional task binding: `verifies-tr` + `verifies-claims[]` — the test narrows to the scope of a TR (a subset of the parent SR's statements). Coverage is still counted from the artifact's statements, not from tasks.

TC states: `draft → ready → passing | failing`. Only the runner-actor writes `last-run`.

### 8.1 Six TC types (closed list)

```text
tc-type ∈ { business, ux, system, contract, eval, security }
```

| Type | What it checks | Applies to |
|---|---|---|
| `business` | Whether the business goal is achieved | BR |
| `ux` | Whether the UX matches the stated experience | SPEC-UI |
| `system` | Whether the system behaves as described | SR, SPEC-PROC, SPEC-ARCH |
| `contract` | Whether the interface contract holds | SPEC-API, SPEC-INT, SPEC-DATA |
| `eval` | Whether AI-component quality is reached | SPEC-AI |
| `security` | Whether the security invariants hold | SPEC-SEC |

**The `acceptance` type no longer exists** — it was renamed to `business`. There are two acceptances, on opposite sides of the circuit split: a `business` TC checks the business goal of a BR (the internal circuit), while `AT` checks conformance to the contract (section 8A). One name for two subjects was a direct source of confusion.

### 8.2 Authorship isolation (P8) and red history (P9)

**P8 — isolation of test authorship.** A test created while writing the code will be fitted **to the code**, not to the requirement: it honestly checks what was written, not what was required. Isolation is mandatory on three axes:

| Axis | Requirement |
|---|---|
| **Time** | The TC is frozen (`ready`) **before** the implementation it checks begins. A TR does not enter work until its linked TC are in `ready` |
| **Author** | The agent writing the test **is not** the agent writing the implementation (different sessions or models). The TC's provenance is cross-checked against the provenance of the implementation change unit |
| **Change** | Editing the `## Pass criterion` / `## Fail criterion` of a frozen test happens only through `[test-spec-change]` with an engineer's approval |

**P9 — red history.**

> **A test never observed red is not evidence.**

- The **fixing run** happens **before** the implementation: the test MUST be **red** — the behavior under check does not exist yet. The "red → green" transition is recorded by the substrate and is the condition for counting the TC at QG-2.
- A green result on the fixing run is a **signal to investigate**, not a success: either the test checks nothing, or the functionality already exists. Both cases require an engineer's analysis.
- **Inheritance**: for tasks that do not change observable behavior (refactoring, a migration with no contract change) the red history is **inherited** from the TC of the same statement (`red-history.inherited-from`).
- **Exception — `implementation-originated`** (section 6.3): such a test is born green and cannot have a red history. Compensation is mandatory: a **killed mutant** (`mutation-check.mutants-killed ≥ 1`).

**Why P9 if P8 exists.** Isolation guarantees that the test was written before the code and not by whoever writes the code. But it does not guarantee that the test **checks anything**: an empty test, honestly written by an isolated agent, passes all three axes of P8 and is green from birth. Only the red history closes that hole.

**The machine signal of a weakened norm.** If a previously green system **fails after a test is edited**, the norm has changed in fact, however the edit was classified. The trigger is blocking: the edit must be carried out as a change of the norm (`[test-spec-change]` + an engineer's approval) or reverted.

---

## 8A. AT — the acceptance test of the contractual circuit

### 8A.1 Why

TC traceability is closed through the **interpretation**: `TC → SR → ADAPT → TZ`. Hence a class of defects that the TC level cannot catch **in principle**: if the interpretation of the TZ is wrong, all TC may be `passing` — the system perfectly matches a **wrong** interpretation — and still fail acceptance at the client.

**AT** (`AT-NN`) is derived **exclusively** from the **effective TZ** (section 5A.4) and checks conformance to the **contract**, not to the interpretation.

### 8A.2 Isolation as the generation mechanism

An AT is created by an **isolated agent**: the input is **only the effective TZ**. Access to ADAPT, BR / SR / SPEC, TC, and the code is **forbidden**. The model of the AT generator agent MUST differ from the model of the primary agent.

Isolation here is not hygiene but the **essence of the mechanism**: an AT is a simulation of the client's view. An agent that has seen the ADAPT or the SR will reproduce the **same** interpretation — and the AT will start confirming it instead of the contract. The acceptance level collapses into the verification level, and the error of interpretation receives a **false confirmation of conformance**. A breach of isolation is **fatal**.

### 8A.3 Regeneration before the trials

> **AT are regenerated before every trial run** from the **current** revision of the effective TZ.

Every signed ACTZ produces a new revision of the effective TZ. AT derived at planning time go stale by the time of the trials — without regeneration, at the end of a long engagement the system is checked against a year-old contract. A stale trial program is **not admitted** to the trials: the gate compares each AT's `tz-version` with the current revision and blocks a divergence. Regeneration is cheap — the same isolated agent performs it.

### 8A.4 Failure routing (diagnostics)

| AT | TC | Diagnosis | What gets fixed |
|---|---|---|---|
| ✗ | ✓ | **Error of interpretation**: the system matches the ADAPT but not the contract | The ADAPT / ACTZ, then the derived requirements |
| ✗ | ✗ | An implementation defect | The code |
| ✓ | ✗ | The requirement is stricter than the contract, or the TC is wrong | Investigate: an excess requirement or a defective TC |
| ✓ | ✓ | Normal | — |

The first row is the reason AT exists: this defect is not detected by any TC.

### 8A.5 Mandatory fields and body

- `verifies[]` — **only** `TZ §N` and `ACTZ-NNN §M`. A reference to an internal artifact (BR / SR / SPEC / TC) is **fatal**.
- `tz-version` — the revision of the effective TZ the AT was derived from.
- `generator` — the provenance of the isolated agent: vendor, model, confirmation that there was no access to the internal circuit.
- `negative` — pos/neg pairing as for TC; `status` and `automation` (including `automation.kind`) as for TC; `last-run` is written by the runner.
- `environment-ref` — the environment and dataset of the acceptance trials. The field is filled in **not by the generator**: the isolated agent does not see internal artifacts. The architect or the runner attaches the environment **after** generation — the trials stay reproducible and isolation is not broken.
- **`tz_text`** — a verbatim quote of the checked clause of the effective TZ next to the steps — a **mandatory** body section of an AT. The quote ends the argument at acceptance: what is presented is the contract clause itself, not a paraphrase.

**The acceptance report** `ACCEPTANCE.md` is auto-generated: AT coverage across the sections of the effective TZ and the clauses of the signed ACTZ. The product is not presented for delivery until all AT are `passing` (section 9).

---

## 9. Lifecycle and quality gates (QG)

Requirement states: `draft → approved → verified → deprecated → obsolete`.
ADAPT states: `draft → review → asked → answered → approved → frozen`, plus the terminal `superseded` on supersession. The `client-ready` state is **withdrawn**: putting questions to the client is the subject of an ACTZ, not a state of an ADAPT.
ACTZ states: `draft → sent → signed → superseded`.

| Gate | What it checks | Who runs it | Level |
|---|---|---|---|
| **QG-0** Approval | The schema is valid, there is a link to a parent, the source is stated | Architect / authorized | required |
| **QG-1** Implementation | A `TR` is linked to a `SPEC`, the implementation substrate is pinned; the linked TC are frozen in `ready` (P8) | Engineer + runner | required |
| **QG-2** Verification | All `TC` pass, a pos/neg pair, versions match, every TC has a red history or a killed mutant (P9) | Automated runner | required |
| **QG-3** Architecture | **The Architect's signature** on the ADAPT; every finding `resolved` and carrying `decided-in` to a signed ACTZ; supersession too | Architect | declared / absent |
| **QG-4** Acceptance | The business outcome is accepted (`achievement ≥ 80%`) | Stakeholder | declared / absent |
| **Release acceptance gate (AT)** | All `AT` are `passing`; each AT's `tz-version` = the current revision of the effective TZ; the generator's provenance confirms isolation | Isolated agent + runner | **mandatory** |

QG-0..QG-2 are mandatory (`required`). QG-3/QG-4 are `declared` or `absent`. Creating new gate types locally is forbidden.

**The release acceptance gate is not merged with QG-4:** QG-4 is optional and measures the business outcome, while the release gate measures conformance to the contract. The business goal may be reached while the contract is breached, and vice versa.

**Substrate-independent enforcement.** The substrate MUST automatically block transitions when preconditions are unmet: promote-transition (V3/V4), approve-transition (V6), reference-validation (V1/V5), `implements`-edge validation, `adapt-applicability` validation, `adapt-supersession` validation (a dangling `source.adapt` to a `superseded` — fatal), `decided-in` pointing at an unsigned or non-existent ACTZ — fatal, a signed ACTZ not reflected in any ADAPT — fatal, a breach of AT generator isolation — fatal.

---

## 10. Roles and signatures

**The agent (AI) is a first-class executor**: the primary generator of `BR`/`SR`/`SPEC`/`TC`/draft-ADAPT drafts and the adversarial critic. But the agent is **not the owner** of an artifact and **does not sign**.

**The human** is the owner, verifier, and approver. By RACI: `R` (Responsible) = AI, `A` (Accountable) = the **Architect** (the role name for Architect / Tech Lead on the executor side). An attempt to declare the AI agent Accountable is non-conformant.

The signature map is closed:

| Artifact | Who signs |
|---|---|
| **TZ** and delta-TZ | The client |
| **ACTZ** | **Dual**: client + vendor (`client-signature` + `vendor-signature`; the same person on both sides is a violation) |
| **ADAPT** | **The Architect only** |
| **AR** | The adversarial reviewer |
| `implementation-originated` | A human supervisor |

The client signs **only the TZ and the ACTZ**. There is **no** client signature on an ADAPT: the client would be signing an engineering document they never read and cannot assess.

AI provenance is recorded in `ai-provenance` (model, prompt template, tokens, the fact of a human edit). Different agent roles MUST be different agents: the primary agent ≠ the adversarial reviewer; the test author ≠ the implementation author (P8); the AT generator ≠ the primary agent (a different model, with no access to the internal circuit).

---

## 11. Closed lists (cannot be extended locally)

- **11 SPEC types:** `ARCH / API / DATA / INT / PROC / UI / AI / SEC / OPS / TEST / DOC`.
- **6 TC types:** `business / ux / system / contract / eval / security` (there is **no** `acceptance` type).
- **7 finding categories:** `contradiction / gap / hidden-assumption / feasibility / regulatory / terminology / scope`.
- **9 normative TC principles:** P1 standalone artifact, P2 document ≠ implementation, P3 AI-generated, P4 AI-executed, P5 pos/neg pairing, P6 `last-run` bot-managed, P7 judge ≠ production, **P8 authorship isolation**, **P9 red history**.
- **Quality Gates:** `QG-0 / QG-1 / QG-2 / QG-3 / QG-4`.
- **V1–V6** substrate capabilities: immutable history, atomic change unit, diff & review, branching, version pin, author + timestamp.
- **ADAPT states:** `draft / review / asked / answered / approved / frozen / superseded` (an ADAPT has no `obsolete` state).
- **ACTZ states:** `draft / sent / signed / superseded`.

Extending any list is possible only by a formal amendment to the standard (research draft → discussion → minor-version bump → migration guide).

---

## 12. Hard rules (cannot be broken)

- **A TZ, a signed ACTZ, and an approved ADAPT are immutable** — only the addition of new artifacts with an explicit typed link.
- **Do not reconstruct `SR`/`SPEC` from code** without a bug-fix justification (source-of-truth inversion). The narrow exception is `implementation-originated` for an internal technical detail, with the harness from section 6.3.
- **Do not fit tests** to the implementation; a change to verified behavior is tagged `[test-spec-change]`.
- **Do not let the test be written by the same agent that writes the implementation** (P8), and do not count a test that has never been red (P9) — the only exception is `implementation-originated` with a killed mutant.
- **Provenance is mandatory** for every `BR`/`SR`/`SPEC` (`source.tz-section` always; `source.adapt` or `source.adversarial-review-ref`).
- **A TC pair** (positive + negative) for every normative statement.
- **Adversarial review of the TZ is always mandatory**; "no ADAPT needed" is a recorded verdict of a different model, not a silent assumption.
- **Do not have the client sign an ADAPT.** What is put to the client is an ACTZ; an ADAPT is signed by the Architect only.
- **Every finding that needs the client's word carries `decided-in` to a clause of a SIGNED ACTZ.** A reference to a `draft`/`sent` ACTZ is fatal. A signed ACTZ not reflected in any ADAPT is fatal.
- **An AT is derived only from the effective TZ** by an isolated agent on a different model; the generator's access to ADAPT / BR / SR / SPEC / TC / code is forbidden; an AT's `verifies[]` references only `TZ §N` and `ACTZ-NNN §M`.
- **AT are regenerated before every trial run** from the current revision of the effective TZ; the product is not presented for delivery until all AT are `passing`.
- **Do not invent closed lists** (section 11).
- **A dangling reference to a `superseded` ADAPT** is forbidden — repoint or re-derive the derivatives.

---

## 13. Minimal recording forms (frontmatter)

### TZ
```yaml
id: TZ-YYYY-NNN
type: TZ
status: registered            # immutable after registration
signed-by-client: "<name + role>"
signed-date: "<ISO-date>"
document-version-ref: "<substrate version identifier>"
```

### ADAPT
```yaml
id: ADAPT-NNN
type: ADAPT
trigger-stage: import-tz       # import-tz | decompose-br | decompose-sr | spec | tc
source-tz: { id: TZ-YYYY-NNN, signed-date: "<ISO>", signed-by-client: "<name+role>" }
parent-adapt: { id: ADAPT-NNN, delta-tz: TZ-YYYY-NNN-delta-N }   # for a delta-ADAPT
supersedes: ADAPT-MMM          # only for a superseding ADAPT
superseded-by: ADAPT-NNN       # auto-derived on the superseded one
supersession-rationale: "<conflicting BR/SR/SPEC + source>"   # mandatory if supersedes
status: draft | review | asked | answered | approved | frozen | superseded
approval:
  architect-signature: { signed-by: "<name>", role: architect, signed-at: "<ISO>" }   # the ADAPT's only signature
open-questions-count: 0        # MUST be 0 for approved
```
Every backward finding in the ADAPT body:
```yaml
- id: B-NNN
  category: gap                # one of the 7 closed categories
  status: open | asked-to-client | answered | resolved | revised | frozen
  decided-in: "ACTZ-NNN §M"    # mandatory for resolved; the ACTZ MUST be signed
```

### ACTZ (the TZ clarification protocol)
```yaml
id: ACTZ-NNN
type: ACTZ
contract-name: "TZ Clarification Protocol No. N"
tz-ref: TZ-YYYY-NNN
resolves: [B-001, B-004]       # the ADAPT entries it closes; absent for a client-initiated ACTZ
decisions:                     # mandatory; the language of commitments, a stable clause number §M
  - { section: "§1", text: "<the client's decision in the language of commitments>" }
annexes: ["<new version of a TZ annex>"]   # if the decision is a new version of an annex
status: draft | sent | signed | superseded
client-signature: { signed-by: "<name>", role: "<role>", organization: "<org>", signed-at: "<ISO>" }   # mandatory for signed
vendor-signature: { signed-by: "<name>", role: "<role>", signed-at: "<ISO>" }                          # mandatory for signed
superseded-by: ACTZ-MMM        # mandatory when status: superseded
```

### BR
```yaml
id: BR-NN
type: BR
status: draft                  # draft → approved → verified → deprecated → obsolete
level: system | subsystem
implements: [{ id: BR-MM, scope.system: "<system>" }]   # for a subsystem (0..N)
source:
  adapt: ADAPT-NNN             # if an ADAPT exists
  tz-section: "§N.N"           # always mandatory
  adversarial-review-ref: AR-NNN        # if source.adapt is omitted -> AR (issued, no-findings)
```
Body (mandatory sections):
```markdown
## Need
Who (role), what (action), why (business goal) — one sentence.
## Success criteria
Measurable outcomes, 3–7 items; each independently verifiable.
## Context
Where the requirement came from (reference to an ADAPT section if present); what alternatives.
## Constraints
Optional: business constraints (budget, deadlines, regulation). No technical ones.
```

### SR
```yaml
id: SR-NN
type: SR
status: draft
parent: BR-NN                  # exactly one
source:
  adapt: ADAPT-NNN
  adapt-section: "Forward §3"
  tz-section: "§3.4"           # always mandatory
constrained-by: [SPEC-API-02, SPEC-UI-04]
verified-by: [TC-NN, TC-NN-neg]
```
The provenance variant for an internal technical detail (section 6.3) — **only** when `observable-by-client: false`:
```yaml
source:
  tz-section: "§N.N"                   # always mandatory, here too
  implementation-originated:
    change-unit-ref: "<the implementation change unit that produced the requirement>"
    rationale: "<why the functionality was deemed necessary>"
    human-approval: { approved-by: "<human supervisor>", role: "<role>", approved-at: "<ISO>" }
    observable-by-client: false        # true → non-conformance
    covering-tc: TC-NN                 # exists and passes before the merge
    mutation-check: { mutants-killed: 1, report-ref: "<mutation check report>" }   # ≥ 1
```
Body (mandatory sections):
```markdown
## Requirement
One sentence in normative form: "The system MUST …".
## Behavior
Detailed observable behavior; functional scenarios.
## Constraints
If applicable: non-functional (performance, security). Full ones — in SPEC.
## Link to SPEC
If constrained-by[] is present: which aspects of behavior are governed by which SPEC.
```

### SPEC
```yaml
id: SPEC-API-NN
type: SPEC-API                 # one of the 11 closed types
status: draft
source: { adapt: ADAPT-NNN, tz-section: "§N.N" }
depends-on: [SPEC-DATA-NN]     # DAG, no cycles
```

### TR (in the tracker, not a file)
```yaml
id: TR-NNN
type: TR
goal: "<what to do>"
acceptance-criteria: ["<criterion 1>", "<criterion 2>"]
implements-spec: SPEC-API-NN
parent-sr: SR-NN
```
Body (mandatory sections; the names `Goal`/`Acceptance Criteria`/`Scope` are canonical):
```markdown
## Goal
One paragraph; the outcome the TR makes observable.
## Acceptance Criteria
A numbered list of falsifiable criteria; covers positive and negative scenarios.
## Scope
What is in and what is **not** in the TR.
## References
If applicable: to the SPEC in implements-spec[] and the sections of the parent SR.
```

### TC
```yaml
id: TC-NN
type: TC
tc-type: business             # business | ux | system | contract | eval | security  (acceptance WITHDRAWN)
negative: false               # the paired TC-NN-neg is mandatory (negative: true)
verifies: [{ id: SR-NN, requirement-version: "1.4" }]
verifies-tr: TR-NN            # optional: narrowing to the scope of a task
verifies-claims: ["§2.1"]     # optional: a subset of the parent SR's statements
status: draft                 # draft → ready → passing | failing | obsolete
red-history:                  # mandatory for the TC to count as evidence (P9)
  fixing-run: { date: "<ISO>", result: fail }      # the fixing run BEFORE implementation — MUST be red
  green-transition: "<ISO>"                         # written by the runner
  inherited-from: TC-NN                             # conditional: refactoring with no behavior change
  not-applicable-reason: implementation-originated  # conditional: the class of section 6.3
mutation-check: { mutants-killed: 1 }               # mandatory if not-applicable-reason is set (≥ 1)
environment-ref: SPEC-TEST-NN  # mandatory if automation.kind: dynamic — the environment and dataset the TC is valid against; not applicable to static
automation:
  status: automated           # automated | manual-pending
  kind: dynamic               # MANDATORY: dynamic | static
  location: "<path/identifier>"                     # mandatory if automated
judge: { vendor: "<provider>", model: "<model>" }   # mandatory for ux | eval; vendor ≠ production (P7)
ai-provenance: { generated-by: "<vendor>-<model>@<date>", human-edits: false }   # test author ≠ implementation author (P8)
```
Body (mandatory sections; `## Pass criterion` and `## Fail criterion` are fixed names):
```markdown
## Context
Which clause of the verified artifact the TC references; a quote or paraphrase.
## Preconditions
The system and data state for the run; the seed mechanism.
## Steps
Runner actions. For tc-type: ux — intentions, not selectors.
## Pass criterion
Binary, observable, reproducible.
## Fail criterion
Observable signs of a violation (not the negation of Pass): leaks, side effects, races.
## Postconditions
The expected state after the run; cleanup.
## Out of scope
What is deliberately not checked, naming the paired TC.
```

### AT (the acceptance test against the contract)
```yaml
id: AT-NN
type: AT
verifies:                     # the contractual circuit ONLY; a reference to BR/SR/SPEC/TC is fatal
  - "TZ §3.4"
  - "ACTZ-001 §2"
tz-version: "<revision of the effective TZ>"    # MUST match the current revision
generator:                    # the isolated agent
  vendor: "<provider>"
  model: "<model>"            # MUST differ from the primary agent's model
  internal-access: false      # no access to ADAPT / BR / SR / SPEC / TC / code; true → fatal
negative: false               # pos/neg pairing as for TC
status: draft                 # draft → ready → passing | failing | obsolete
environment-ref: SPEC-TEST-NN            # mandatory: the environment and dataset of the acceptance trials; filled in NOT by the generator but by the architect or runner AFTER generation — isolation is not broken
automation: { status: automated, kind: dynamic, location: "<path/identifier>" }
```
The AT body is as for a TC, plus a **mandatory** section with a verbatim quote of the contract clause:
```markdown
## tz_text
A verbatim quote of the checked clause of the effective TZ (not a paraphrase).
```

---

## 14. Conformance minimum

A project declares conformance through a **manifest** (immutable, V1) with mandatory fields:

```yaml
renar-version: 1.0
senar-version: "<version>"
level: RENAR-1                 # RENAR-1 (ad-hoc) … RENAR-5 (optimizing)
mandatory-clauses:
  sot-inversion: true
  substrate-v1-v6: { v1: true, v2: true, v3: true, v4: true, v5: true, v6: true }
  adapt-reactive: true
  spec-types-closed-list: true
  tc-pos-neg-pairing: true
  quality-gates-closed-list: true
  conformance-manifest: true
```

An implementation MAY **tighten** the requirements (`declared-stricter`: QG-3/QG-4 as `required`, and so on), but MUST NOT **weaken** them: it cannot declare ADAPT optional, allow a single TC for a normative statement, or omit `senar-version`/`level`. The levels `RENAR-1..RENAR-5` reflect process maturity, not the volume of documentation.

---

## 15. Glossary of key terms

- **TZ** — the technical assignment: the client's contractual input, immutable.
- **ADAPT** — the **internal** interpretation of the TZ (forward interpretation + backward findings); reactive, 0..N per TZ; signed by the architect only.
- **ACTZ** — the TZ clarification protocol ("TZ Clarification Protocol No. N"): the decisions put to the client; **dual** signature, contractual weight; `draft → sent → signed → superseded`.
- **Effective TZ** — the initial TZ + all signed ACTZ; the benchmark for delivery and acceptance.
- **`decided-in`** — a finding's reference to a clause of a **signed** ACTZ recording the client's decision.
- **AT** — the acceptance test against the contract: derived by an isolated agent from the effective TZ only; regenerated before every trial run.
- **P8 (authorship isolation)** — the test is frozen before implementation; the test author ≠ the implementation author; criteria are edited via `[test-spec-change]`.
- **P9 (red history)** — a test never observed red is not evidence.
- **`implementation-originated`** — the narrow provenance class for an internal technical detail; a killed mutant is mandatory.
- **Forward interpretation (Forward)** — the translation of a TZ section into the language of requirements.
- **Backward finding** — a recorded question/problem in one of the 7 categories.
- **Adversarial review** — a review by a separate agent on a different model; issues a verdict; recorded as an AR.
- **Provenance / source** — the machine-readable origin of an artifact.
- **implements-edge** — a typed edge "subsystem BR implements system BR".
- **Supersession** — the cancellation of a previously correct but refuted decision; the state `superseded`.
- **QG (Quality Gate)** — a lifecycle-transition gate.
- **SoT inversion** — requirements (not code) are the source of truth about behavior.
- **MVR** — Minimum Viable RENAR: the seven mandatory statements.
- **Architect** — the role name for Architect / Tech Lead; the owner and signatory on the executor side (including the sole signatory of an ADAPT).

---

*RENAR 1.0 — the operational edition for the agent. Full normative corpus: [renar.tech](https://renar.tech). © 2026 Vadim Soglaev, Andrey Yumashev. CC BY-SA 4.0.*