After M8 - How Transformer System Is Made: Research Loops, Evidence, and Publication

0x00 The Published Article Is A Compiled Artifact

Transformer System began as a rewrite of the Transformer Series. The early assumption was that a better structure would make the same material easier to understand. That was only partly true. Reorganization removed repetition, but it also exposed a more dangerous failure: a concise synthesis can preserve conclusions while deleting the derivations, tensor transitions, implementation choices, training state, runtime consequences, and paper lineage that made the conclusions useful.

The production method changed in response. An article stopped being treated as a document written from top to bottom. It became the publication artifact compiled from four different layers:

Layer	Main question	Typical artifacts	Reader-facing?
research corpus	what evidence exists, and what does each source actually support?	local source articles, papers, official code/docs, source figures	references and selected figures
design and ownership	which article owns each concept, and which neighboring article must not duplicate it?	roadmap, owner contract, boundary graph, depth-gap audit	owner question and handoffs
engineering evidence	do formulas, shapes, algorithms, examples, links, and renders agree?	manifests, fixtures, oracles, tests, hashes, browser reports	examples, pseudocode, failure labs
publication prose	what sequence lets a reader reconstruct the mechanism?	Markdown, figures, captions, references, publish gate	yes

The first three layers contain planning machinery that would normally remain in an author’s notebook, code repository, spreadsheet, or review history. Transformer System makes much of that machinery explicit because it is still under construction. This is normal. Human authors also work through outlines, rejected explanations, derivation scratchpads, source tables, editorial comments, and successive drafts. Those intermediate structures are not defects in the process, but they are not automatically the final literary form either.

The distinction matters:

research and evidence machinery
    proves that the candidate article is coherent

publication prose
    teaches the coherent mechanism to a reader

final editorial form
    may later hide loop labels and internal gates
    without deleting the depth they produced

This afterword records that production method. It is not a claim that every Transformer System article has reached the same editorial maturity. It is a reusable protocol for building the next series with the same depth while improving the separation between internal scaffolding and final exposition.

0x01 Begin With A Corpus, Not A Table Of Contents

A new series should not begin by inventing article titles. It should begin by constructing the evidence surface.

For Transformer System, the corpus included the original Transformer Series, the roadmap, later local writing, primary papers, official runtime documentation, source code, figures, and selected engineering references. The original articles were not treated as obsolete drafts. They established a minimum depth baseline: the rewrite could remove duplicated prose or repair an error, but it could not silently discard useful explanations simply to become shorter.

0x01A Every Source Has A Role And A Claim Ceiling

A source manifest should record more than a URL:

source_id: paper_or_local_name
kind: local_article | primary_paper | official_code | official_docs | secondary
revision: exact version, commit, or retrieval date
supports:
  - mechanism or claim supported by this source
claim_ceiling: source_local | source_reported | externally_verified
figures:
  - identifier, license, disposition, and intended semantic use

The claim ceiling prevents several common substitutions:

paper reports a benchmark
    != benchmark reproduced locally

official API exposes an option
    != optimized backend executed

source code contains a path
    != deployed runtime selected that path

article explains a mechanism
    != every implementation uses that mechanism

Sources should therefore be classified by what they can prove. Primary papers own their algorithm and source-reported experiments. Official code and docs own version-specific interfaces and implementation boundaries. Local articles own their explanations, but technically consequential claims still need external verification. Secondary sources are useful for discovery and interpretation, not as silent replacements for the primary record.

0x01B Read Sources For Missing Machinery, Not Only Missing Facts

The source audit asks what the current draft has compressed away:

• the historical pressure that created the method;
• prerequisite concepts the source author introduced before the mechanism;
• derivation steps between the objective and final formula;
• tensor shapes, indexing, masks, and persistent state;
• alternative methods and why one design was chosen;
• training schedules, initialization, checkpoint, and export behavior;
• runtime dispatch, memory, synchronization, and serving integration;
• source figures that explain a mechanism better than prose alone;
• negative results, assumptions, and failure cases.

This is why source length is not the decision rule. A long historical survey may compress into one lineage table, while a single two-line equation may require a full derivation, numerical example, and implementation trace.

0x02 Design An Ownership Graph Before Writing Prose

Redundancy is not solved by deleting repeated concepts everywhere. It is solved by assigning one canonical owner and giving other articles explicit imports and handoffs.

Each article begins with one owner question. The question must be specific enough that a reader can tell when the article is complete. An owner contract then separates four sets:

owns:
    mechanisms derived completely here

imports:
    prerequisites used from earlier owners

defers:
    consequences developed by later owners

forbidden collapses:
    distinctions the article must never merge

For example, a method name must not collapse a training objective, an exported artifact, and a runtime kernel into one object. A nominal bit width must not collapse logical codes, serialized bytes, loaded memory, executed arithmetic, and measured service capacity. A speculative output token must not collapse with the K/V row that is valid to commit. These distinctions became owner and failure contracts because plausible prose had hidden them before.

0x02A Article Count Is An Output

The number of articles should emerge from ownership. It should not be fixed for symmetry with an older series.

Split an article when two sections have different:

• owner questions;
• mathematical objects or state transitions;
• source lineages;
• training or runtime contracts;
• evaluation denominators;
• failure modes;
• downstream consumers.

Merge articles only when they explain one continuous state transition and a split would force both halves to repeat the same derivation or manifest. The M6, M7, and M8 expansions were consequences of this rule. Depth was preserved by adding owners rather than forcing unrelated mechanisms into a word budget.

0x02B A Program Audit Precedes Article Audits

Before deepening one article, inspect the module as a graph:

1. list every owner question;
2. map prerequisites and downstream consumers;
3. locate exact duplicated explanations;
4. locate concepts referenced everywhere but owned nowhere;
5. identify incompatible notation or state models;
6. freeze stable routes unless a migration is necessary;
7. order work so foundational contracts close before consumers.

This prevents an excellent local rewrite from making the series globally less coherent.

0x03 The Read-Only Pre-Loop Audit

The first operation on an article is a read-only audit. It is deliberately not a rewrite. Its output is a bounded inventory:

Audit surface	Questions
introduction	does the reader know why the problem exists and what came before it?
owner boundary	what is fully owned, imported, deferred, or forbidden?
formulas	are assumptions, variables, units, shapes, and derivations present?
mechanisms	can one input be traced through the state transition?
alternatives	which viable designs exist, and what does each exchange?
training	what is initialized, optimized, frozen, scheduled, saved, or converted?
runtime	what is allocated, packed, dispatched, synchronized, cached, measured, or rolled back?
papers	are methods compared by full contracts rather than names and benchmark maxima?
visuals	which source figures can be reused, which need reconstruction, and what is still invisible?
evidence	which claims can be checked symbolically, numerically, structurally, or in a browser?
scope	which claims remain source-reported, uncertain, environment-dependent, or untested?

The audit ends with priorities, not prose. A useful classification is:

P0: correctness or publication blocker
P1: missing mechanism depth
P2: visual, source, accessibility, or editorial closure
P3: optional extension with a separate owner or verification need

This inventory becomes the loop plan. It also provides a stopping rule: when a later audit finds no unowned P0/P1 mechanism gap, work can move from technical construction to editorial refinement.

0x04 Freeze Identity Before Deriving Behavior

Many technically wrong explanations are shape-correct. They fail because the identity of a token, row, cache entry, expert route, candidate branch, adapter, quantization group, or experimental sample changed silently.

The early loops therefore freeze the article’s immutable objects. The exact manifest is domain-specific, but often includes:

• source and target tensor names, shapes, axes, dtypes, devices, and layouts;
• sample, request, token, route, branch, or artifact identity;
• masks, positions, validity, and supervision state;
• trainable, frozen, optimizer, checkpoint, and random-number state;
• persistent, temporary, recomputed, transferred, and released memory;
• runtime version, source commit, backend, kernel, topology, and fallback;
• dataset split, workload, metric, tolerance, and decision policy;
• source, figure, license, and article hash.

0x04A Hashes Are Evidence Bindings, Not Proof By Themselves

A hash answers one narrow question: is this the same byte sequence that the report evaluated? It does not prove that the evaluated claim is true. Transformer System uses hashes to prevent a green report from drifting away from the article, source revision, generated HTML, or fixture that produced it.

The proof still comes from the appropriate check:

symbolic identity     -> derivation or algebraic oracle
tensor implementation -> shape/index/state oracle
numerical behavior    -> reference calculation and tolerance
source claim          -> pinned primary source and scoped wording
rendered publication  -> generated HTML and browser evidence
runtime performance   -> measured exact environment, if actually executed

0x05 Plan Bounded Loops, Not One Giant Rewrite

A loop is the smallest coherent research-and-publication transaction that can close one question without making the rest of the article unauditable.

Each loop has:

question: one bounded uncertainty or missing mechanism
inputs: exact sources and prior owner contracts
deliverables: prose, formulas, traces, visuals, and evidence
gate: observable conditions required to call the loop complete
scope_ceiling: claims the loop is not allowed to make
rollback: article and evidence state that can be restored

There is no universal twelve-section article template. Twelve loops became a useful engineering rhythm for many deep Transformer System owners, but their contents were adapted to the mechanism. A common sequence was:

Loop family	Typical purpose
0	immediate correctness repair or read-only pre-loop audit
1	historical introduction, owner contract, source and figure manifest
2	immutable identities, tensor/state schemas, and source-to-object trace
3-6	mathematical derivation and mechanism implementation, one dependency at a time
7-9	training/runtime integration, alternatives, paper variants, cost and sensitivity
10	executable oracle, framework/source trace, or pipeline comparison
11	evaluation, failure injection, release, rollback, and source-reported reconciliation
12	formula, source, visual, render, accessibility, and cross-article closure

The numbering is bookkeeping, not pedagogy. Some articles need fewer loops. Others need a new article owner rather than a thirteenth unrelated mechanism.

0x05A The Atomic Loop

Inside one loop, the work proceeds in a fixed causal order:

1. restate the owner question and exact gate;
2. inspect the current article and primary sources without editing;
3. write the derivation and name every assumption;
4. trace one concrete input through tensors, state, and code;
5. compare viable alternatives under the same contract;
6. patch only the owned section and its handoffs;
7. build an independent oracle or reconciliation fixture;
8. turn plausible failure modes into negative or mutation tests;
9. add or revise semantic visuals and provenance;
10. build and inspect desktop/mobile, light/dark publication output;
11. review the diff, rerun prior gates, and update the next loop.

Later loops extend earlier work. They do not earn room by compressing derivations, implementation traces, alternatives, training/runtime integration, or paper comparisons that already passed a gate.

0x06 Five Dimensions Of Depth Are Non-Compressible

The roadmap depth contract names five dimensions that must survive every rewrite. The loop process makes each one operational.

0x06A Derive The Formula, Do Not Merely Display It

A formula section should answer this chain:

object and objective
 -> assumptions
 -> decomposition or state transition
 -> algebraic steps
 -> final expression
 -> variables, shapes, units, and convention
 -> limiting cases
 -> worked numerical example
 -> implementation translation
 -> failure if an assumption changes

For a generic constrained objective,

$$\max_\theta J_R(\theta) \quad\text{subject to}\quad J_{C_i}(\theta)\le d_i,$$

showing the final Lagrangian is not enough. A deep treatment must define the trajectory distribution behind each expectation, the reward and cost return conventions, finite- or infinite-horizon assumptions, discounting, feasibility, and why nonnegative multipliers correspond to upper-bound constraints. Only then does the saddle objective have a stable meaning:

$$\mathcal{L}(\theta,\lambda) =J_R(\theta)-\sum_i\lambda_i\left(J_{C_i}(\theta)-d_i\right), \qquad \lambda_i\ge 0.$$

The sign, multiplier projection, update timescale, and empirical estimator are not typographic details. They determine whether the code encourages or punishes constraint violation.

0x06B Carry Tensor And State Identity Through Code

Pseudocode must preserve the identities established by the manifest. It should include shapes, indexing, ownership, mutation, and commit points.

For reinforcement learning, a trace might follow:

environment transition
 -> trajectory row (s_t, a_t, r_t, c_t, done_t, timeout_t)
 -> reward and cost returns
 -> reward and cost advantages
 -> policy/value/cost-value minibatches
 -> primal gradient and dual update
 -> projected multiplier state
 -> checkpoint and evaluation policy

The trace must distinguish termination from truncation, on-policy collection from replay data, behavior policy from target policy, per-step cost from trajectory constraint, and training-time estimates from evaluation-time gates. Those are the constrained-RL equivalents of token/KV, logical/physical, or artifact/runtime identity failures in Transformer System.

0x06C Compare Alternative Designs Under One Contract

Alternatives should not appear as a list of acronyms. Normalize them across the same axes:

Contract axis	Example questions for constrained RL
objective	expected cost, chance constraint, CVaR, worst case, or temporal logic?
feasibility	assumed feasible start, learned recovery, shield, or no guarantee?
update	penalty, primal-dual, trust region, projection, or model-predictive correction?
estimator	on-policy, off-policy, model-based, importance weighted, or conservative?
guarantee	asymptotic, local, high probability, empirical only, or none?
state	policy, reward critic, cost critic, multipliers, model, safety set, replay buffer
runtime	training-only constraint, action filter, shield, planner, or deployment monitor
evidence	theorem assumptions, simulator result, real-system result, reproduced result

This exposes real design exchanges instead of declaring one paper universally better.

0x06D Connect Training To Runtime

Training details are part of the method:

• initialization and pretraining;
• data collection policy and environment versions;
• reward and cost normalization;
• critic targets and bootstrapping;
• optimizer and update frequencies;
• multiplier parameterization and projection;
• trust-region or clipping behavior;
• replay, importance weights, and distribution shift;
• checkpoint contents and resumption;
• export, inference policy, safety layer, monitoring, and rollback.

A method whose safety mechanism exists only during training is different from a method whose runtime action is filtered by a shield. The article must carry that difference into deployment rather than ending at the loss function.

0x06E Compare Papers By Pipeline Contract

Paper comparison should separate:

problem definition
assumptions and guarantee
objective and estimator
data/interaction budget
optimization schedule
architecture and persistent state
evaluation protocol
reported result
artifact/runtime consequence

Benchmark numbers remain source-reported unless reproduced. A theorem remains conditional on its assumptions. A method evaluated with privileged simulator state is not silently equivalent to one deployed from observations alone.

0x07 Evidence Should Fail Closed

Tests in a writing repository are not substitutes for peer review or empirical reproduction. They are executable checks that specific contracts remain true as the article evolves.

0x07A Useful Evidence Classes

Evidence	What it can catch	What it cannot prove alone
source manifest	citation drift, wrong revision, unsupported attribution	technical correctness of the source
formula registry	missing variables, duplicate symbols, convention drift	truth of the derivation
executable oracle	algebra, index, state, or numerical mismatch on defined fixtures	general performance or unrestricted correctness
mutation test	audit that stays green after a known-bad change	completeness of all possible failures
article hash	report/article drift	semantic quality
route/link audit	missing local posts, assets, or external targets	source relevance
browser matrix	math parity, overflow, broken images, theme and viewport regressions	pedagogical clarity
program audit	duplicate owners, missing handoffs, stale final evidence	correctness of every article claim

0x07B The Oracle Must Be Independent Enough To Disagree

Reimplementing the article pseudocode line for line and calling it a reference creates correlated errors. Prefer a second formulation:

• enumerate a tiny state space instead of sampling;
• compare a merged online state with direct full computation;
• calculate a ledger from dimensions rather than parsing the displayed total;
• build a mask from a graph relation rather than copying a table;
• replay a state machine from events rather than trusting the final state;
• compare a source-pinned implementation trace with the teaching pseudocode.

Every oracle should state its domain. Passing a tiny deterministic fixture does not become a hardware benchmark or a proof for every model.

0x07C Mutation Tests Protect The Audit

An audit can be more dangerous than no audit when it reports green without checking the terminal artifact. Mutation tests deliberately change a hash, formula token, route, state transition, mask entry, or source revision and require the audit to fail. They test the detector, not the mechanism.

The central rule is:

no final report without source identity
no program green without running article terminal gates
no browser green without exact route/profile cardinality
no performance claim without an executed measurement contract

0x08 Visuals Are Part Of The Explanation

The visual process begins during source research, not after prose is complete. Every figure found in a local source or primary paper receives one disposition:

reuse:
    license and resolution permit direct use; caption states provenance

reconstruct:
    redraw the mechanism with Transformer System notation and cite the conceptual source

context-only:
    useful during research but redundant or too paper-specific for publication

omit:
    decorative, illegible, unsupported, duplicated, or outside the owner scope

A custom visual needs a semantic job. Good jobs include proving an axis, showing ownership, exposing temporary versus persistent state, comparing two algorithms under one input, or making a failure visible. “Make the page less text-heavy” is not a sufficient specification.

Each visual should declare:

• the claim or transition it explains;
• labels and notation shared with the prose;
• source and reconstruction provenance;
• what is intentionally omitted;
• alt text that communicates the semantic result;
• stable dimensions and mobile legibility;
• light/dark compatibility and text containment.

Source figures remain valuable, especially for paper lineage and source-reported results. Custom diagrams are better for cross-paper normalization, tensor/state traces, and program-specific owner boundaries. The two roles should not be confused.

0x09 Article Closure And Program Closure Are Different

An article can pass locally while breaking the series. Closure therefore occurs at two levels.

0x09A Article Closure

The terminal article audit checks:

• owner question and owns/imports/defers boundary;
• derivations, variables, units, shapes, and renderer-safe formulas;
• source manifest and source-scoped wording;
• visual routes, provenance, captions, and alt text;
• code fences, tables, heading IDs, links, and references;
• executable oracles, negative fixtures, and mutation tests;
• desktop/mobile and light/dark rendering;
• explicit empirical and runtime claim ceilings;
• article-source hash binding.

0x09B Program Closure

The module audit then checks:

• ordered owner set and publication state;
• reciprocal handoffs and no missing owner;
• duplicate deep prose and conflicting notation;
• final report selection for every article;
• all terminal validators, not selected status fields;
• exact article hashes and generated routes;
• normalized browser evidence across the complete module;
• bounded repair scope for any remaining delta.

This distinction was learned through false greens: a central report can say “pass” while an article’s current terminal suite fails, its source hash is absent, or the central selector points to a structural report instead of the final publication report.

0x09C Build, Deployment, And Live Acceptance Are Separate Gates

A successful static build proves that the publication can be generated. A local browser matrix proves properties of that generated candidate. Deployment proves that a particular release was transferred. Live acceptance proves that public routes and assets behave in the deployed environment. No earlier gate should claim a later one.

0x0A The Final Editorial Pass Comes After Technical Closure

The current Transformer System articles often expose loop boundaries, manifests, owner language, and publish gates. That is useful while mechanisms are still being deepened because it keeps scope and evidence visible. It is not necessarily the final reading experience.

A later editorial pass may:

• replace “Loop 4” with a descriptive transition;
• move detailed manifests from the article into repository evidence;
• merge repetitive publish gates into a concise end note;
• convert internal source-status tables into precise citations and prose;
• smooth transitions between sections written in different loops;
• remove planning narration that no longer helps reconstruct the mechanism;
• preserve a short methodology link back to this afterword.

It must not remove:

• derivations and assumptions;
• tensor, state, and code traces;
• alternative design comparisons;
• training/runtime bridges;
• paper-by-contract distinctions;
• useful source and reconstructed figures;
• failure cases and claim limitations.

The editorial objective is therefore not “make it shorter.” It is:

reduce visible scaffolding
while preserving or improving reconstructible technical depth

0x0B Failure Lab For Research-Loop Writing

Failure	Why it looks reasonable	Detection	Required response
start from article titles	a clean curriculum appears quickly	important concepts have no owner or appear repeatedly	audit corpus and build owner graph first
treat old articles as word budget	rewrite looks concise	derivations and implementation details disappear	use old corpus as minimum depth baseline
one giant rewrite	prose becomes stylistically consistent	review cannot identify which claim changed	split into bounded loops with gates
fixed twelve-section template	process appears standardized	article structure follows tooling rather than mechanism	keep loop protocol, customize loop content
formula without derivation	mathematical notation signals rigor	sign, axis, assumption, or unit cannot be reconstructed	add derivation ladder and limiting cases
pseudocode without identities	code looks executable	state, positions, ownership, or commit semantics are ambiguous	freeze manifest and trace one concrete example
methods compared by names	survey covers many papers	training budget, assumptions, and runtime differ	compare full pipeline contracts
source figure copied without audit	paper authority transfers visually	license, caption, axes, or scope are wrong	record provenance and disposition
every visual redrawn	style is uniform	source evidence and historical context disappear	mix licensed source figures with semantic reconstructions
tests mirror prose exactly	all checks pass	the same error exists in article and oracle	use an independent formulation and mutations
central audit trusts old report	module remains green	article hash or terminal suite is stale	execute terminal gates and require exact binding
benchmark quoted as local result	article sounds decisive	no environment or raw evidence exists	label source-reported and scope exact setup
internal machinery kept forever	process remains transparent	reader path becomes repetitive and bureaucratic	perform separate editorial pass after closure
scaffolding removed too early	article reads smoothly	later patches silently reintroduce drift	retain evidence layer until program closure

0x0C Adapting The Method To Constrained Reinforcement Learning

The process transfers across domains; the manifests and invariants do not. A constrained reinforcement learning series should not merely replace Transformer terms in existing loop plans. It needs a domain audit centered on decision processes, feasibility, estimators, guarantees, and deployment-time safety.

0x0CA Domain Invariants To Freeze Early

At minimum, distinguish:

reward objective vs safety/cost constraint
per-step cost vs discounted/undiscounted trajectory cost
expected constraint vs chance, CVaR, worst-case, or temporal constraint
environment termination vs time-limit truncation
behavior policy vs target policy vs deployed policy
true environment cost vs learned cost critic estimate
training feasibility vs evaluation compliance
penalty coefficient vs Lagrange multiplier vs runtime safety threshold
asymptotic/theoretical guarantee vs finite-sample empirical result
simulator safety vs real-system safety
training-time correction vs runtime shield or action projection
mean performance vs violation frequency, severity, and tail risk

0x0CB A Seed Ownership Map, Not A Final Curriculum

The corpus audit should be allowed to change this map:

Candidate owner	Owner question
orientation and MDP execution	what state, action, transition, return, value, policy, and data-generation objects exist?
policy/value optimization	how do dynamic programming, policy gradients, actor-critic estimators, and trust regions transform trajectory evidence?
constrained MDP foundations	what is feasible, how do occupancy measures express reward/cost objectives, and when does duality apply?
penalty and primal-dual methods	how are multipliers estimated, projected, scheduled, and stabilized with learned critics?
trust-region constrained updates	how do CPO-style approximations, projections, and first-order variants differ by guarantee and implementation?
risk and distributional constraints	how do chance constraints, CVaR, tail costs, robust objectives, and ambiguity sets change the state?
safe exploration and runtime intervention	what belongs to shields, control barrier functions, model predictive safety, recovery policies, or human override?
offline constrained RL	how do support mismatch, conservative estimation, behavior data, and counterfactual safety limit learning?
systems and reproducibility	how are environments, vectorization, seeds, replay, normalization, checkpoints, evaluators, and distributed state made exact?
evaluation and release	how are reward, feasibility, violation tails, uncertainty, stress tests, monitoring, fallback, and rollback turned into gates?

The first research deliverable should be a gap and ownership audit that either confirms, splits, merges, or rejects these candidate owners.

0x0D Reusable Bootstrap Prompt For The Next Series

The following prompt is intentionally detailed. It asks the next research agent to build the program architecture and loop plan before writing final article prose.

You are helping build a deep technical article series on reinforcement learning,
with constrained reinforcement learning as its central specialization.

The objective is not to summarize papers or compress existing material. The
series must let a technically serious reader reconstruct the mathematics,
estimators, training state, implementation, runtime safety boundary, empirical
contract, and paper lineage of each mechanism.

Treat every published article as a compiled artifact produced from a research
corpus, an ownership graph, bounded implementation loops, executable evidence,
semantic visuals, and a final editorial pass.

NON-COMPRESSIBLE DEPTH

Do not compress or remove:
1. derivations explaining why formulas take their final form;
2. tensor-level, trajectory-level, state-level, and code-level traces;
3. alternative methods and design choices;
4. training details and runtime/deployment integration;
5. comparisons between paper variants by complete pipeline contract.

If these dimensions do not fit coherently, create another article owner. Article
count is an output of the ownership audit, not a fixed target.

CLAIM STATUS

Label consequential claims as one of:
- source-local;
- externally verified;
- rewrite interpretation;
- source-reported empirical result;
- locally reproduced;
- uncertain or not externally verified.

Never convert a paper benchmark into a local result. Never convert an
asymptotic theorem into an unconditional finite-sample safety guarantee. Never
convert simulator compliance into real-system safety.

STAGE 1: READ-ONLY CORPUS AUDIT

Before proposing articles, inspect all supplied local writing and build a source
manifest. Then research primary papers, official code, official documentation,
benchmark/environment definitions, and relevant surveys for discovery only.
Pin paper revisions, code commits, environment versions, and retrieval dates.

For every source record:
- what mechanism or claim it supports;
- its assumptions and empirical denominator;
- whether it contains useful figures;
- figure license/provenance and reuse/reconstruct/context/omit disposition;
- its claim ceiling.

Identify depth present in local writing that must survive reconstruction, even
if the prose quality is lower than the target series.

STAGE 2: DOMAIN AND OWNERSHIP AUDIT

Build a concept/dependency graph before a table of contents. At minimum audit:
- MDP/POMDP state, action, transition, reward, cost, horizon, discount, and
  occupancy conventions;
- value functions, policy gradients, actor-critic estimators, bootstrapping,
  termination, and truncation;
- constrained MDP feasibility, primal and dual forms, strong-duality conditions,
  and occupancy-measure geometry;
- penalties, primal-dual methods, multiplier state, update timescales, and
  critic-estimation error;
- constrained trust-region and projection methods;
- chance, CVaR, distributional, robust, and temporal-logic constraints;
- safe exploration, recovery, shields, barrier functions, model-based safety,
  and human intervention;
- offline constrained RL, support mismatch, conservative estimation, and
  counterfactual limitations;
- multi-agent or hierarchical constraints only if the corpus justifies owners;
- environment/runtime integration, reproducibility, evaluation, monitoring,
  fallback, and rollback.

For each proposed article produce:
- one owner question;
- owns, imports, defers, and forbidden collapses;
- prerequisite and downstream links;
- primary source set;
- required derivations, traces, alternatives, training/runtime sections,
  visuals, failure cases, and publish gate.

Detect duplicated content and assign one canonical owner. Do not delete a deep
explanation until its new owner exists and reciprocal links are explicit.

STAGE 3: ARTICLE PRE-LOOP AUDIT

For the next article only, perform a read-only gap audit. Classify findings:
- P0 correctness/publication blockers;
- P1 missing mechanism depth;
- P2 source, visual, render, accessibility, or editorial closure;
- P3 optional expansion requiring separate verification or ownership.

Do not begin with a giant rewrite. Convert the findings into small loops. Each
loop must have one question, exact inputs, deliverables, a pass/fail gate, a
claim ceiling, and rollback scope.

STAGE 4: IMMUTABLE MANIFESTS

Freeze the identities needed by the article. For constrained RL include as
applicable:
- environment and wrapper versions;
- observation/action spaces and normalization;
- horizon, discount, termination, truncation, and reset semantics;
- reward and every cost signal with units and aggregation;
- policy, reward critic, cost critic, target network, multiplier, model, shield,
  replay, optimizer, RNG, and checkpoint state;
- behavior, target, collection, evaluation, and deployed policy identity;
- trajectory schema and tensor shapes;
- dataset split, seed, scenario, stressor, and independent sampling unit;
- evaluation metric, confidence interval, feasibility margin, and release rule;
- source, code, visual, article, and generated-page hashes.

STAGE 5: BOUNDED RESEARCH LOOPS

Use the following as a customizable loop family, not a rigid article template:
0. immediate correctness repair or pre-loop audit;
1. historical introduction, motivation, owner contract, source/figure manifest;
2. immutable trajectory, estimator, state, and environment contract;
3-6. derivations and mechanism traces, one dependency at a time;
7-9. alternatives, training schedules, implementation/runtime integration,
     sensitivity, and paper variants;
10. independent executable oracle and source/code trace;
11. evaluation, stress/failure injection, monitoring, fallback, and rollback;
12. formula, source, visual, render, accessibility, and boundary closure.

Within every loop:
1. inspect current content and primary sources before editing;
2. derive formulas from the declared objective and assumptions;
3. carry one concrete trajectory through tensors, estimators, updates, and state;
4. show code-level pseudocode with shapes, mutation, ownership, and commit points;
5. compare viable alternatives under one contract;
6. patch only the owned section;
7. create an independent oracle or reconciliation fixture;
8. create negative and mutation tests for plausible wrong implementations;
9. add or update semantic visuals and provenance;
10. build and check desktop/mobile plus light/dark rendering;
11. rerun prior gates and review the bounded diff before planning the next loop.

STAGE 6: DERIVATION CONTRACT

For each important formula provide:
- object and objective;
- assumptions;
- derivation steps;
- variables, shapes, units, signs, and reduction axes;
- limiting/special cases;
- worked numerical or tiny-state example;
- implementation translation;
- failure when assumptions change.

For constrained objectives, explicitly distinguish expected cumulative cost,
per-step cost, violation probability, CVaR/tail risk, worst-case cost, and
temporal constraints. State feasibility and duality assumptions. Show why the
Lagrangian sign and multiplier projection are correct. Separate true constraint
values from learned estimates.

STAGE 7: PAPER-BY-CONTRACT COMPARISON

Normalize every paper across:
- problem definition and constraint class;
- assumptions and guarantee type;
- objective and estimator;
- data source and interaction budget;
- policy/critic/model/shield architecture;
- optimization and multiplier schedule;
- persistent training and runtime state;
- environment, scenarios, seeds, baselines, metrics, and uncertainty;
- source-reported result;
- artifact and deployment consequence.

Do not compare method names or maxima from incompatible environments as if they
shared a denominator.

STAGE 8: VISUAL SYSTEM

Audit every useful figure from local sources and primary papers. Record license
and provenance. Reuse licensed source figures when they carry historical or
empirical evidence. Reconstruct figures when common notation or a cross-paper
comparison is needed. Omit decorative or redundant figures.

Every custom visual must have a semantic job, such as:
- MDP/occupancy geometry;
- primal-dual update and timescale state;
- trajectory-to-estimator tensor trace;
- trust-region/projection geometry;
- constraint type comparison;
- training-only versus runtime safety boundary;
- offline support and uncertainty;
- evaluation, stress, monitoring, fallback, and rollback state machine.

Require descriptive alt text, stable dimensions, mobile legibility, light/dark
compatibility, and labels consistent with article notation.

STAGE 9: EVIDENCE AND CLOSURE

Create checks appropriate to the claim:
- symbolic or enumerated tiny-MDP checks for derivations;
- shape/index/state checks for trajectory and update code;
- deterministic fixtures for return, advantage, multiplier, projection, and
  termination/truncation semantics;
- independent reference implementations where feasible;
- mutation tests proving audits fail on sign, mask, state, source, hash, or
  boundary errors;
- link, source, figure, formula, route, alt-text, and browser checks;
- article-source and generated-page hash binding.

State what was not executed: paper training, large environments, hardware,
real-system interaction, deployment, or live acceptance. Tests in the writing
repository do not become empirical reproduction.

Close the article first, then run a program-level audit for owner coverage,
reciprocal handoffs, duplicates, notation conflicts, terminal evidence, exact
hashes, routes, and normalized browser profiles.

STAGE 10: FINAL EDITORIAL FORM

Only after technical and program closure, perform a separate editorial pass.
Remove visible loop bookkeeping and repetitive internal planning language when
it no longer helps the reader. Preserve every derivation, state/code trace,
alternative, training/runtime bridge, paper distinction, useful visual, failure
case, and claim limitation. The objective is less visible scaffolding, not a
thinner technical series.

FIRST RESPONSE REQUIRED

Do not write final article prose yet. Return:
1. corpus and source-acquisition plan;
2. constrained-RL concept/dependency graph;
3. proposed owner map with merge/split reasoning;
4. redundancy and missing-owner audit;
5. per-article non-compressible depth requirements;
6. visual research backlog;
7. evidence/test strategy;
8. recommended implementation order;
9. the complete bounded loop plan for the first article only.

0x0E Publish Gate For A New Series

Before the first constrained-RL article is considered technically closed:

• The corpus includes local explanations, primary papers, official code, environment definitions, and source figures with claim ceilings.
• The series owner graph was designed before final article prose.
• MDP, constraint, estimator, training state, runtime intervention, and evaluation objects have canonical owners.
• Reward and every cost constraint have explicit horizon, discount, unit, aggregation, and feasibility semantics.
• Termination and time-limit truncation are distinct in formulas and code.
• Every central formula has assumptions, derivation, variables, limiting cases, worked example, and implementation translation.
• At least one trajectory is traced through collection, returns, reward and cost advantages, primal update, dual update, checkpoint, and evaluation.
• Penalty, primal-dual, trust-region, projection, risk-sensitive, shielded, model-based, and offline alternatives are compared only where one owner and source corpus justify the comparison.
• Paper results and guarantees are scoped to exact assumptions and empirical denominators.
• Training-time safety signals and runtime safety interventions are not conflated.
• Source figures have provenance and dispositions; custom visuals have semantic jobs and accessible labels.
• Oracles are independent enough to disagree with the teaching pseudocode.
• Mutation tests prove the audit fails on plausible sign, state, identity, or evidence errors.
• Article and program closure execute terminal gates and bind current source and generated-page identities.
• The final editorial pass removes obsolete scaffolding without deleting non-compressible depth.

0x0F What To Carry Forward

The most reusable Transformer System lesson is not “use twelve loops.” It is that depth needs an architecture of its own.

corpus before outline
ownership before expansion
identity before algebra
derivation before summary
state trace before pseudocode confidence
contract before paper comparison
oracle before green report
visual semantics before decoration
article closure before program closure
technical closure before editorial compression

The next series should improve the method, not imitate its accidental surface. Constrained reinforcement learning has different mathematical objects, safety claims, failure consequences, and empirical limitations. The process transfers because it forces those differences to become explicit.

0xFF References And Local Method Sources

• M0.0 - Roadmap - series architecture, owner boundaries, and the non-compressible depth contract. [TRANSFORMER SYSTEM]
• M4.1 - Transformer Cost Model - immutable manifests, derivation, reconciliation, and executable accounting. [TRANSFORMER SYSTEM]
• M4.3 - IO-Aware Attention And FlashAttention-1 - derivation-to-algorithm-to-oracle workflow and source-figure reconstruction. [TRANSFORMER SYSTEM]
• M5.8 - Multi-Head Latent Attention - twelve-loop architecture, source-to-tensor manifests, runtime integration, final publication evidence, and program-level repair. [TRANSFORMER SYSTEM]
• M6.11 - Pruning, Structural Compression, And Executable Sparsity - mechanism-specific loop design, paper-by-contract comparison, recovery, runtime proof, and preservation rule. [TRANSFORMER SYSTEM]
• M7.1 - Speculative Decoding - exactness derivation, output/KV/RNG identity, correction state, and fail-closed publication contracts. [TRANSFORMER SYSTEM]
• M8.10 - Deployment Evaluation, Release, And Rollback - immutable candidate tuples, statistical gates, measurement contracts, staged release, observability, and rollback. [TRANSFORMER SYSTEM]
• X1.3 - Masks, Training, Runtime, And State - cross-cutting ownership, mixed-origin state, training/runtime bridges, and reuse/release boundaries. [TRANSFORMER SYSTEM]