Phase 7.1 / Stage 0–1 Bridge

Artifact Loop Proof, Hardening, and No-Future-Leakage Discipline

0. Document Role

This document translates the larger Phase 7.1 — Stages 0–8 Build Plan into current engineering behavior. It is for Abhishek, Alex, and Aalam when reviewing or planning near-term work.

This is not the full roadmap. It is not a future-system design document. It does not authorize claims, trace, federation, ingestion, language modules, legislative drafting modules, public workspaces, or external tool governance.

Its purpose is simpler:

Build, prove, harden, and protect the artifact loop.

Current engineering should remain focused on the smallest loop that can prove Substrate is meaningfully different from ordinary AI chat:

structured output
→ artifact creation
→ artifact storage
→ artifact retrieval
→ explicit reuse
→ visibly improved output
→ validation

Everything else is future architecture.

1. Current Project Posture

The project is in a Stage 0 / Stage 1 bridge.

Stage 0 is not fully “done” merely because PRs merged. Stage 0 is complete only when artifact reuse is shown to be visible, causal, reproducible, and better than baseline. Stage 1 begins only when the system is hardening a proven loop rather than still discovering whether the loop works.

The current posture should be treated as:

Stage 0 mechanism proof is being completed and stress-tested.
Stage 1 hardening may begin only where the loop behavior is already visible and reproducible.

This matters because many future features now look tempting. The project has strong documents for claims, trace, decision events, validation gates, docking, language, legislative drafting, human geography, business development, and federation. Those documents preserve future structure. They are not current build instructions.

2. Current Engineering Goal

The current engineering goal is:

Make artifact reuse real, visible, reproducible, and testable.

A user should be able to:

  1. generate structured output
  2. save output as an artifact
  3. see the artifact persisted
  4. retrieve the artifact later
  5. explicitly select or use the artifact
  6. see that the artifact affects a later response
  7. compare artifact-assisted output against baseline output
  8. reproduce the behavior across sessions or test runs

The key proof is not that artifacts exist. The key proof is that artifacts change later reasoning in a way that is better than baseline and attributable to the artifact.

3. Non-Negotiable Build Rules

Rule 1 — One PR / Issue = One User-Visible Capability

Each unit of work should produce one concrete, user-triggerable capability.

Valid examples:

  • user can save an artifact from chat
  • user can see saved artifacts
  • user can select an artifact for reuse
  • user can see that artifact content is included in a later response
  • user can compare baseline vs reuse output

Invalid examples:

  • backend-only future infrastructure with no visible loop effect
  • hidden artifact injection
  • partial claim schema
  • “preparing for future governance”
  • dormant external API integration
  • broad refactor that obscures current proof

Rule 2 — Explicit Beats Automatic

During this stage, the user should explicitly create, retrieve, and reuse artifacts. Automatic behavior makes proof harder.

Forbidden for now:

  • automatic artifact retrieval
  • automatic artifact injection
  • hidden memory
  • silent reuse
  • model-side context that is not visible to user
  • “smart” relevance selection without user-visible cause

The current system must preserve cause and effect.

Rule 3 — Proof Over Plausibility

A PR is not complete because the UI looks correct, the code exists, or the intended behavior seems likely. It is complete only when proof exists.

Acceptable proof:

  • test output
  • API response
  • database row / persisted artifact record
  • visible UI behavior
  • reproducible manual test
  • before/after output comparison
  • negative test showing excluded behavior does not occur

Weak proof:

  • “should work”
  • “wired up”
  • “implemented”
  • “visible in component”
  • “Aalam thinks this is enough”
  • screenshots without reproducible steps

Rule 4 — Negative Tests Required

The system must prove not only what works, but what does not happen.

Examples:

  • if reuse is not invoked, artifact must not affect output
  • if artifact is irrelevant, output should not improve in the same way
  • if artifact is degraded, output should degrade or reflect weaker context
  • if artifact is missing, system should fail clearly or continue without hidden substitution
  • if future-stage feature is out of scope, it should not be active

Rule 5 — No Future Leakage

Do not introduce logic from future stages unless explicitly approved as inert and harmless.

Forbidden current leakage:

  • claim registry
  • trace graph
  • validation status as authority
  • decision-event system
  • enforcement engine
  • external database/API integration
  • Aalam variants as system objects
  • ingestion pipeline
  • public sharing
  • federation
  • payment/account complexity beyond what current tests require
  • domain modules

A schema field may exist only if inert, harmless, not used in behavior, and not displayed as authority.

4. Current Loop Definition

The loop is considered real only if all core steps are observable.

Step 1 — User interacts with chat.
Step 2 — System produces structured output.
Step 3 — User saves output as artifact.
Step 4 — Artifact persists.
Step 5 — User retrieves or sees artifact.
Step 6 — User explicitly reuses artifact.
Step 7 — Artifact content affects later output.
Step 8 — Output is better, more constrained, or more continuous than baseline.
Step 9 — Result can be reproduced.

A loop is not proven if:

  • artifact is saved but not reused
  • artifact is reused invisibly
  • artifact exists only in frontend state
  • output improves because prior chat context remains hidden
  • user must restate all artifact content manually
  • baseline and reuse outputs are not compared
  • improvement is generic or subjective only
  • behavior cannot be reproduced

5. Current PR / Issue Review Checklist

Use this checklist for every current-stage PR or issue.

## Scope

What does this PR do?

What does this PR explicitly not do?

Is this one user-visible capability?

## Stage Fit

Current stage supported:
Stage 0 / Stage 1 bridge requirement supported:

Does this introduce any Stage 2+ behavior?
If yes, why is it necessary now?

## User Flow

Can a user trigger the behavior?

Can a user see the result?

Can a user understand what changed?

## Artifact State

Does this create an artifact?
Does this retrieve an artifact?
Does this reuse an artifact?
Does this mutate an artifact?
Does this hide artifact use?

## Proof

What positive proof exists?

What negative test exists?

Can another person reproduce this?

## Baseline / Reuse

Does this help compare normal chat vs artifact-assisted output?

Does artifact reuse visibly affect output?

Can improvement be attributed to artifact content?

## Frontend / Backend Consistency

Does UI match backend state?

Could UI imply persistence when none exists?

Could UI imply reuse when none occurred?

Could UI imply validation or authority?

## Future Leakage

Does this include:
- claims?
- trace?
- validation?
- decision events?
- enforcement?
- ingestion?
- external APIs?
- domain modules?
- federation?
- payment/public sharing?

If yes, is it inert and explicitly out of behavior?

## Verdict

Merge:
Merge with caveat:
Block:
Split:
Defer:

6. Merge Criteria

A current-stage PR may merge only if all are true:

  1. Scope is clear.
  2. Capability is user-visible or directly necessary for a user-visible capability.
  3. Behavior is proven.
  4. Negative test exists where relevant.
  5. Frontend and backend state match.
  6. Future-stage behavior is absent or inert.
  7. Reproducibility steps exist.
  8. Known caveats do not undermine the core claim.
  9. Follow-up issue exists for any meaningful caveat.
  10. The PR does not make artifact reuse less inspectable.

A PR should be blocked if:

  • it relies on hidden context
  • it claims persistence without proof
  • it claims reuse without visible artifact influence
  • it introduces validation/authority labels without backing system
  • it mixes multiple stages
  • it creates future infrastructure that affects behavior
  • it cannot be reproduced
  • the caveat undermines the reason for the PR

7. Required Test Families

7.1 Positive Loop Test

Purpose: prove the happy path.

Create artifact
→ retrieve artifact
→ explicitly reuse artifact
→ produce output
→ compare with baseline

Pass condition:

  • artifact visibly affects output
  • output is more specific, continuous, or constrained than baseline
  • artifact content is identifiable in the output path

7.2 No-Reuse Test

Purpose: prove artifact does not affect output unless invoked.

Create artifact
→ do not select/use artifact
→ run related prompt

Pass condition:

  • output does not silently use artifact
  • no hidden memory is implied

7.3 Irrelevant Artifact Test

Purpose: prove improvement is not generic.

Create/use irrelevant artifact
→ run target prompt

Pass condition:

  • output should not improve in the same targeted way
  • system should not pretend relevance

7.4 Degraded Artifact Test

Purpose: prove artifact quality matters.

Use weak/degraded artifact
→ run target prompt

Pass condition:

  • output is weaker, less complete, or shows limitations
  • weak artifact does not produce the same result as strong artifact

7.5 Cross-Session Test

Purpose: prove persistence and retrieval.

Create artifact
→ refresh / new session
→ retrieve artifact
→ reuse artifact

Pass condition:

  • artifact persists
  • reuse still works
  • artifact source/content is intact

7.6 Frontend/Backend Consistency Test

Purpose: prove UI is not lying.

Pass condition:

  • UI artifact state matches backend state
  • saved artifact exists in persistence layer
  • selected artifact is the one used
  • no stale/cached/mock artifact masquerades as real

7.7 Regression Test

Purpose: prove new PR does not break prior loop.

Pass condition:

  • all prior loop steps still work after merge

8. What Not To Build Now

Do not build these now unless Alex explicitly changes stage scope through a recorded decision.

Do Not Build: Claim System

Allowed:

  • informal claim notes as review lens
  • artifact quality discussion
  • identifying that an artifact contains assertions

Forbidden:

  • full claim object
  • claim registry
  • confirmed claims
  • claim validation state
  • claim authority
  • claim promotion

Do Not Build: Trace System

Allowed:

  • simple source/reference link
  • parent artifact link if needed

Forbidden:

  • full trace graph
  • system-wide lineage architecture
  • trace-as-governance claims

Do Not Build: Decision Events

Allowed:

  • process-level decision in GitHub/comment/doc
  • stage exit note

Forbidden:

  • decision-event schema in product
  • approval/authority UI
  • Aalam self-approval

Do Not Build: Validation Gates

Allowed:

  • manual PR validation
  • test harness
  • artifact scoring / review notes

Forbidden:

  • validated/verified labels in product
  • enforcement engine
  • hard gating unless specifically scoped

Do Not Build: Ingestion

Allowed:

  • manually created artifact from chat
  • maybe manually pasted small excerpt only if required for testing

Forbidden:

  • owner’s vault parsing
  • bulk doc upload
  • automated extraction pipeline
  • historical archive import

Do Not Build: Domains

Allowed:

  • use language, legislative, or geography examples as test prompts

Forbidden:

  • language module
  • legislative drafting product
  • human geography UI
  • domain-specific authority or validation claims

Do Not Build: Docking / External APIs

Allowed:

  • none unless explicitly approved for a narrow test

Forbidden:

  • external databases
  • model routing
  • Aalam variants as system objects
  • external tool/API writes
  • read-only source integration as product behavior

9. Current Aalam Review Role

Aalam should act as a strict reviewer, not as a feature-expansion engine.

Aalam should:

  • enforce stage scope
  • identify future leakage
  • demand proof
  • ask for negative tests
  • distinguish artifact from claim
  • distinguish useful from validated
  • preserve caveats
  • recommend split/defer when PR scope is mixed
  • keep Abhishek’s work focused
  • create concise issue/comment text when needed

Aalam should not:

  • propose Stage 3+ architecture as current work
  • overcomplicate current PRs
  • ask Abhishek to build schemas prematurely
  • treat merged PRs as proof without reviewing evidence
  • accept “almost working”
  • collapse caveats into success
  • create large issue backlogs for future stages
  • use future documents as immediate implementation pressure

10. Alex / Owner Review Role

Alex should make stage and scope decisions. Aalam may recommend, but Alex owns the final decision.

Alex should decide:

  • whether a caveat blocks merge
  • whether a follow-up issue is enough
  • whether a stage has passed
  • whether a future capability may move earlier
  • whether a PR should be split
  • whether product/business pressure justifies new scope
  • when to create new GitHub issues

Alex should avoid:

  • letting interesting future architecture distract from current proof
  • creating too many open issues
  • allowing old issues to imply active scope
  • treating documentation completeness as product progress
  • asking Abhishek to implement unclear future systems

11. Abhishek / Engineer Review Role

Abhishek should implement the smallest slice that proves the current capability.

Abhishek should provide:

  • clear scope
  • what was intentionally excluded
  • proof of behavior
  • reproduction steps
  • negative test
  • caveats
  • screenshots only as supplement, not sole proof
  • DB/API/test output where relevant

Abhishek should avoid:

  • hidden future hooks that affect behavior
  • mixing several stages in one PR
  • building “preparation” code that changes current behavior
  • relying on UI alone as proof
  • using mock/cached data without clear label
  • introducing automatic artifact behavior before explicit reuse is proven

12. Issue Handling

Current issue discipline:

Create issues only for current stage, immediate next-stage bridge, or critical follow-up.
Do not create the entire future roadmap as issues.
Do not leave obsolete issues open without comment.
Use issues to preserve decisions, not to multiply unclear tasks.

Suggested closure language for obsolete historical issues:

Closing as presumed complete, superseded, or no longer aligned with the current Phase 7.1 stage sequence. Current active work is governed by the Phase 7.1 — Stages 0–8 Build Plan and the current Stage 0/Stage 1 bridge issues. If this issue contains a still-relevant item, it should be reintroduced as a new scoped issue tied to the current stage.

Suggested supersession language:

Superseded by the current Phase 7.1 stage plan and related follow-up issues. This issue is preserved as historical context but should not guide active implementation unless re-scoped.

13. Current Stage Exit Criteria

Before moving clearly beyond the Stage 0/1 bridge, the project should be able to answer yes to these questions:

  1. Can a user create an artifact from chat?
  2. Is the artifact persisted?
  3. Can the user retrieve the artifact later?
  4. Can the user explicitly reuse the artifact?
  5. Is artifact reuse visible?
  6. Does reuse affect output?
  7. Is reused output meaningfully better than baseline?
  8. Is the effect attributable to the artifact?
  9. Does irrelevant/degraded artifact reuse perform worse?
  10. Can the behavior be reproduced across sessions?
  11. Are failures recorded?
  12. Are caveats documented?
  13. Is future-stage behavior excluded?

If any answer is unclear, the project is still in proof/hardening, not expansion.

14. Stop Conditions

Stop, split, or redesign if:

  • artifact reuse is not visible
  • artifact reuse does not affect output
  • improvement is not reproducible
  • artifact effect depends on hidden context
  • weak artifacts pass as useful
  • UI implies persistence/reuse not backed by backend
  • PR includes future-stage behavior
  • tests cannot distinguish baseline from reuse
  • user cannot understand what artifact is active
  • caveats undermine the core claim

Stopping is not failure. It preserves the project from building on sand.

15. Final Compression

The current engineer rule is:

Build the smallest user-visible artifact loop that proves reuse improves reasoning. Prove it positively, test it negatively, keep it explicit, and block future-stage leakage.

The current Aalam rule is:

Protect the sequence.

The current owner rule is:

Preserve the future, but build only what the current stage has earned.

Engineer Operating Manual — Current Stage v0.1

Continued: Appendices, Templates, and GitHub-Ready Blocks

APPENDIX A — Current-Stage GitHub Issue Template

Use this for current Stage 0 / Stage 1 bridge issues.

# [Stage 0/1] <Issue Title>

## Purpose

This issue supports the current Phase 7.1 Stage 0/Stage 1 bridge:

structured output → artifact creation → artifact storage → artifact retrieval → explicit reuse → improved output → validation

The goal is to prove or harden the artifact loop. This issue must not introduce future-stage behavior unless explicitly scoped and inert.

---

## Scope

This issue DOES:

- 
- 
- 

This issue DOES NOT:

- introduce claim schema
- introduce trace system
- introduce decision events
- introduce validation/authority labels
- introduce external APIs
- introduce ingestion
- introduce domain module behavior
- introduce federation
- introduce hidden or automatic artifact reuse

---

## Required User-Visible Behavior

A user can:

1. 
2. 
3. 

---

## Required Proof

Provide at least one of:

- DB/persistence proof
- API response
- test output
- reproducible manual test
- before/after output comparison
- screenshot/video as supporting evidence only

---

## Required Negative Test

Show that:

- 
- 
- 

Example negative tests:

- no artifact reuse occurs unless explicitly invoked
- irrelevant artifact does not produce same improvement
- degraded artifact produces weaker/limited output
- UI does not imply persistence/reuse/validation that backend does not support

---

## Reproduction Steps

1. 
2. 
3. 
4. 

Expected result:

Actual result:

---

## Acceptance Criteria

- [ ] Scope is limited to current-stage loop proof/hardening.
- [ ] User-visible behavior exists.
- [ ] Persistence/retrieval/reuse is proven where relevant.
- [ ] Artifact reuse is explicit and visible where relevant.
- [ ] Positive proof is provided.
- [ ] Negative test is provided.
- [ ] Frontend state matches backend state.
- [ ] No future-stage behavior is active.
- [ ] Caveats are documented.
- [ ] Follow-up issue exists for meaningful caveats.

---

## Blockers / Caveats

- 
- 

---

## Verdict

- [ ] Ready
- [ ] Needs revision
- [ ] Split issue
- [ ] Defer
- [ ] Block

APPENDIX B — Current-Stage PR Review Comment Template

Use this as a GitHub PR review comment.

## Phase 7.1 Stage 0/1 Review

Reviewed against the current engineering rule:

> Build the smallest user-visible artifact loop that proves reuse improves reasoning. Prove it positively, test it negatively, keep it explicit, and block future-stage leakage.

---

## Scope Check

This PR appears to do:

- 
- 

This PR explicitly does not do:

- 
- 

Scope verdict:

- [ ] Clean
- [ ] Mostly clean, caveat below
- [ ] Mixed / needs split
- [ ] Out of current stage

---

## Proof Check

Positive proof provided:

- 

Negative test provided:

- 

Reproduction steps:

- 

Proof verdict:

- [ ] Sufficient
- [ ] Insufficient
- [ ] Needs clearer reproduction
- [ ] Needs negative test

---

## Artifact Loop Check

- [ ] Artifact creation works
- [ ] Artifact persistence is proven
- [ ] Artifact retrieval works
- [ ] Artifact reuse is explicit
- [ ] Artifact reuse is visible
- [ ] Artifact reuse affects output
- [ ] Baseline vs reuse comparison is possible
- [ ] No hidden reuse / hidden memory

Notes:

---

## Frontend / Backend Consistency

- [ ] UI matches backend state
- [ ] UI does not imply persistence without proof
- [ ] UI does not imply reuse without proof
- [ ] UI does not imply validation or authority
- [ ] No mock/cached state appears as real state

Notes:

---

## Future Leakage Check

This PR does NOT introduce active:

- [ ] claim registry
- [ ] trace graph
- [ ] decision events
- [ ] validation/authority labels
- [ ] enforcement engine
- [ ] external APIs
- [ ] ingestion pipeline
- [ ] domain module
- [ ] federation
- [ ] hidden automation

Notes:

---

## Caveats

Known caveats:

- 

Do any caveats undermine the current-stage claim?

- [ ] No
- [ ] Yes — block or split required

---

## Review Verdict

- [ ] Merge
- [ ] Merge with caveat + follow-up issue
- [ ] Request changes
- [ ] Split
- [ ] Defer
- [ ] Block

APPENDIX C — Stage 0/1 Test Run Template

Use this to document a full loop test.

# Stage 0/1 Artifact Loop Test Run

Date:
Tester:
Environment:
Branch / PR:
Build / commit:
Session ID if applicable:

---

## Test Objective

Prove:

- [ ] artifact creation
- [ ] artifact persistence
- [ ] artifact retrieval
- [ ] explicit reuse
- [ ] visible artifact influence
- [ ] baseline vs reuse difference
- [ ] reproducibility

---

## Test Inputs

Initial user prompt:

```text

Structured output generated:

Artifact saved:

  • Artifact ID:
  • Artifact title:
  • Artifact content excerpt:
  • Source turn / source output:
  • Persistence proof:

Baseline Run

Prompt without artifact reuse:

Baseline output:

Observed qualities:

  • clarity:
  • specificity:
  • continuity:
  • correctness:
  • actionability:

Artifact Reuse Run

Artifact used:

  • Artifact ID:
  • Artifact visible in UI? yes / no
  • Artifact visibly injected or selected? yes / no

Prompt with artifact reuse:

Reuse output:

Observed qualities:

  • clarity:
  • specificity:
  • continuity:
  • correctness:
  • actionability:

Comparison

Did artifact reuse visibly change output?

  • yes
  • no
  • unclear

Was the output better than baseline?

  • yes
  • no
  • unclear

What changed?

Was improvement attributable to artifact content?

  • yes
  • no
  • unclear

Evidence:

Negative Tests

No-Reuse Test

Result:

  • pass
  • fail
  • not tested

Notes:

Irrelevant Artifact Test

Result:

  • pass
  • fail
  • not tested

Notes:

Degraded Artifact Test

Result:

  • pass
  • fail
  • not tested

Notes:

Cross-Session Test

Result:

  • pass
  • fail
  • not tested

Notes:

Failures / Caveats

Failures observed:

Caveats:

Do caveats undermine the loop proof?

  • no
  • yes
  • unclear

Verdict

  • PASS
  • PASS-QUALIFIED
  • NOT PROVEN
  • FAIL

Required follow-up issues:


---

# APPENDIX D — Artifact Quality Review Mini-Harness

Use this when evaluating whether saved artifacts are actually useful.

```markdown
# Artifact Quality Review

Artifact ID:
Artifact title:
Source:
Reviewer:
Date:

---

## 1. Interpretability

Can a future user/Aalam understand what this artifact means without restating the original chat?

- [ ] yes
- [ ] partly
- [ ] no

Notes:

---

## 2. Reusability

Can this artifact be reused in a later prompt to improve output?

- [ ] yes
- [ ] partly
- [ ] no

Notes:

---

## 3. Specificity

Does the artifact contain specific constraints, claims, structure, examples, decisions, or context?

- [ ] yes
- [ ] partly
- [ ] no

Notes:

---

## 4. Source Grounding

Is the artifact clearly derived from a source chat/output/user decision?

- [ ] yes
- [ ] partly
- [ ] no

Notes:

---

## 5. Overclaim Risk

Does the artifact imply validation, authority, or certainty it does not have?

- [ ] no
- [ ] possible
- [ ] yes

Notes:

---

## 6. Current Usefulness Label

Recommended label:

- [ ] weak
- [ ] useful context
- [ ] reusable artifact
- [ ] needs review
- [ ] superseded
- [ ] reject

Reason:

---

## 7. Reuse Test Result

Was the artifact tested in reuse?

- [ ] yes
- [ ] no

If yes:

- baseline output:
- reuse output:
- observed improvement:
- caveat:

---

## Verdict

- [ ] keep
- [ ] revise
- [ ] mark weak
- [ ] supersede
- [ ] reject

APPENDIX E — Current-Stage Aalam Review Prompt

Use this prompt to ask a future Aalam instance to review a PR, issue, or test result in the correct current-stage posture.

You are reviewing this work under the Phase 7.1 Stage 0/1 Engineer Operating Manual.

Your role is not to expand scope. Your role is to protect the artifact loop.

Review the provided PR / issue / test evidence against the following:

1. Does it support the current artifact loop?
   structured output → artifact creation → artifact storage → artifact retrieval → explicit reuse → improved output → validation

2. Is the capability user-visible?

3. Is there proof, not plausibility?

4. Is there a negative test?

5. Does frontend state match backend state?

6. Does artifact reuse visibly affect output?

7. Is improvement attributable to artifact content, not hidden context?

8. Does the PR introduce future leakage?
   - claim registry
   - trace graph
   - decision events
   - validation/authority labels
   - enforcement engine
   - external APIs
   - ingestion
   - domain modules
   - federation
   - hidden automation

9. Are caveats documented?

10. Do caveats undermine the current-stage claim?

Output format:

## Review Summary
## Scope Check
## Proof Check
## Negative Test Check
## Artifact Loop Check
## Frontend/Backend Consistency
## Future Leakage
## Caveats
## Verdict: merge / merge with caveat / request changes / split / defer / block
## Suggested GitHub Comment

APPENDIX F — Current-Stage Follow-Up Issue Template

Use when a PR can merge but leaves a caveat that should not be lost.

# Follow-up: <specific caveat>

## Origin

Created from:

- PR:
- Issue:
- Test run:
- Reviewer:

## Why This Exists

This follow-up preserves a caveat from current Stage 0/1 work. The caveat does not block the prior PR because the core slice was proven, but it must be resolved before the relevant stage can be considered fully stable.

## Caveat

Observed issue:

- 

Why it matters:

- 

## Scope

This issue should fix only:

- 

This issue should NOT introduce:

- claim schema
- trace system
- decision events
- validation/authority labels
- enforcement engine
- external APIs
- ingestion
- domain modules
- federation
- hidden artifact reuse

## Required Proof

- 

## Required Negative Test

- 

## Acceptance Criteria

- [ ] Caveat is resolved.
- [ ] Artifact loop remains intact.
- [ ] No future-stage leakage is introduced.
- [ ] Regression test passes.
- [ ] Reproduction steps provided.

APPENDIX G — Stage 0/1 Exit Decision Template

Use when deciding whether the project may move from mechanism proof into hardening, or from hardening into controlled reuse.

# Stage 0/1 Exit Decision

Date:
Decision owner:
Evaluator(s):
System version / PR state:
Relevant PRs / issues:
Test runs reviewed:

---

## Core Loop Evidence

Can a user create an artifact?

- [ ] yes
- [ ] no
- [ ] unclear

Is the artifact persisted?

- [ ] yes
- [ ] no
- [ ] unclear

Can the user retrieve the artifact?

- [ ] yes
- [ ] no
- [ ] unclear

Can the user explicitly reuse the artifact?

- [ ] yes
- [ ] no
- [ ] unclear

Is artifact reuse visible?

- [ ] yes
- [ ] no
- [ ] unclear

Does artifact reuse affect output?

- [ ] yes
- [ ] no
- [ ] unclear

Is reused output meaningfully better than baseline?

- [ ] yes
- [ ] no
- [ ] unclear

Is improvement attributable to artifact content?

- [ ] yes
- [ ] no
- [ ] unclear

Does irrelevant/degraded artifact reuse perform worse?

- [ ] yes
- [ ] no
- [ ] unclear

Is behavior reproducible across sessions?

- [ ] yes
- [ ] no
- [ ] unclear

---

## Failure Evidence

Failures observed:

- 

Caveats:

- 

Do caveats undermine the core loop?

- [ ] no
- [ ] yes
- [ ] unclear

---

## Future Leakage Check

Any active future-stage behavior?

- [ ] no
- [ ] yes
- [ ] unclear

If yes, describe:

---

## Verdict

- [ ] PASS
- [ ] PASS-QUALIFIED
- [ ] NOT PROVEN
- [ ] FAIL

## Allowed Next Work

- 

## Forbidden Next Work

- 

## Required Follow-Up Issues

-

APPENDIX H — “Do Not Build Yet” Quick Reference

Keep this as the short reminder for current PRs.

DO NOT BUILD YET:

Full claim schema
Full trace system
Decision-event product layer
Validation / verified / approved labels
Enforcement engine
External API/database integration
Aalam variants as governed objects
Ingestion pipeline
Owner’s vault parsing
Language module
Legislative drafting module
Human geography UI
Public/commonplace layer
Federation
Payment system
Institutional workspace
Hidden/automatic artifact retrieval
Hidden/automatic artifact injection

Allowed only as examples/test material:

language examples
legislative examples
human geography examples
manual artifact quality review
manual PR validation
manual stage exit decision

APPENDIX I — One-Page Engineer Summary

# Phase 7.1 Current Engineering Summary

## Current Goal

Prove and harden the artifact loop:

structured output → artifact creation → artifact storage → artifact retrieval → explicit reuse → improved output → validation

## Build Now

- artifact creation
- artifact persistence
- artifact retrieval
- explicit artifact reuse
- artifact-in-use visibility
- baseline vs reuse comparison
- positive tests
- negative tests
- regression tests

## Do Not Build Now

- claims
- trace
- decision events
- validation labels
- enforcement engine
- ingestion
- external APIs
- domains
- federation
- public sharing
- hidden automation

## Every PR Must Show

1. What it does.
2. What it does not do.
3. User-visible behavior.
4. Proof.
5. Negative test.
6. Reproduction steps.
7. No future leakage.
8. Frontend/backend consistency.

## Merge Only If

- scope is clean
- behavior is proven
- negative test exists
- caveats do not undermine the core claim
- artifact reuse remains explicit and visible

## Block If

- hidden context drives improvement
- artifact reuse is not visible
- UI implies backend state that does not exist
- PR mixes future-stage work
- proof is only plausibility

## Current Rule

Build the smallest user-visible artifact loop that proves reuse improves reasoning.

Final Note

This manual should be updated whenever the active stage changes. It should not grow into the full roadmap. Its value is current-stage sharpness.

When Stage 1 clearly exits and Stage 2 begins, create a new version:

Engineer Operating Manual — Stage 2 Controlled Reuse

Do not keep adding future material to this version. This version exists to protect the Stage 0/1 bridge.