docs: add Core 2.0 reviewer prep and boundary notes

docs/ANDREI_REVIEW_BRIEF.md

@@ -0,0 +1,53 @@
+# DigiEmu Core 2.0 — Review Brief for Andrei
+
+## Current checkpoint
+
+- Core 2.0 Draft 4 Self-Audit checkpoint
+- Tag: `core-2.0-draft4-self-audit`
+
+## What changed
+
+- Threat model / verification boundary clarified
+- Conformance documentation added
+- Andrei-oriented requirements trace added
+- Go release/tagging safety documented
+- README identity/trust wording cleaned up
+- TBN boundary clarified
+
+## Review focus requested
+
+- Is Core minimal and standardizable enough?
+- Are conformance rules clear enough for independent implementation?
+- Are test vectors sufficient for a first partner-testable draft?
+- Are DigiEmu/TBN boundaries clear?
+- What is needed before Core 2.0 RC1?
+
+## Current safe reference
+
+- Docs: `docs/CONFORMANCE.md`, `docs/THREAT_MODEL.md` (with Core 2.0 addendum), `docs/ANDREI_REQUIREMENTS_TRACE.md`, `docs/RELEASE_SAFETY.md`, `docs/TBN_DIGIEMU_BOUNDARY_NOTE.md`
+- Schemas: `schemas/VERIFY_RESULT_SCHEMA_v1.json`, `schemas/verify_result_v2.schema.json` (draft)
+- Test vectors: `testdata/core_2_conformance/` (11/11 pass)
+
+## Checks
+
+- go test ./... passed
+- go vet ./... passed
+- Core 2.0 conformance report: 11/11 passed
+
+## Known non-goals
+
+- agent identity certification
+- trustworthiness certification
+- authorization framework
+- action legitimacy
+- legal compliance certification
+- trust scoring
+- enterprise dashboard
+- governance workflow engine
+
+## Open questions before RC1
+
+- Any changes needed to make conformance fully independent-implementer friendly?
+- Do v1 vs v2-draft verify-result schemas need additional guidance, or is v1 sufficient for RC1?
+- Any additional negative/edge test vectors needed for standardization clarity?
+- Any boundary language to further simplify for partners?

docs/CORE_2_RC_PLAN.md

@@ -0,0 +1,51 @@
+# DigiEmu Core 2.0 RC Plan
+
+## Current checkpoint
+
+- core-2.0-draft4-self-audit
+
+## RC1 goal
+
+Deliver a minimal, deterministic, partner-testable verification core with stable conformance rules, schemas, and vectors.
+
+## Before RC1
+
+- Confirm README boundary wording
+- Confirm threat model completeness
+- Confirm conformance rules
+- Confirm test vectors
+- Confirm Go module/tagging strategy
+- Confirm no Core/Enterprise boundary leakage
+- Confirm no TBN/DigiEmu responsibility overlap
+
+## RC1 criteria
+
+- All tests pass
+- All conformance vectors pass
+- No known module versioning risks
+- README and docs do not overclaim compliance, identity, or trust certification
+- External reviewer feedback incorporated or documented
+
+## Not required for RC1
+
+- Enterprise dashboard
+- Key management
+- Role system
+- Legal compliance certification
+- Agent identity certification
+- Trust scoring
+
+## Release/tagging safety
+
+- Do not use real v2.0.0 tags unless the module path intentionally ends in /v2
+- Use safe milestone names such as `core-2.0-rc1` until /v2 strategy is explicit
+
+## External feedback handling
+
+- Track Andrei feedback on conformance and standardization (see `docs/ANDREI_REVIEW_BRIEF.md`)
+- Track Burhan feedback on the TBN boundary (see `docs/TBN_DIGIEMU_BOUNDARY_NOTE.md`)
+- Convert accepted feedback into vectors or doc clarifications
+
+## Recommended next milestone
+
+- `core-2.0-rc1` (no /v2 module path change yet)

docs/TBN_DIGIEMU_BOUNDARY_NOTE.md

@@ -0,0 +1,48 @@
+# TBN / DigiEmu Boundary Note
+
+## Purpose
+
+Clarify the boundary between DigiEmu Core and TBN (or similar external trust/attestation systems), ensuring no scope overlap.
+
+## Core distinction
+
+- DigiEmu verifies decision-state reconstruction and deterministic verification evidence.
+- TBN verifies agent identity, trust certification, and action attestation.
+
+## DigiEmu Core responsibility
+
+- canonical snapshot
+- hash verification (SHA-256 over canonical JSON scope)
+- replay / reconstruction
+- PASS / FAIL / ERROR verify result
+- conformance evidence (schemas, vectors, CLI contract)
+
+## TBN responsibility
+
+- agent identity
+- trust state
+- attestation
+- certification
+- external trust claims
+
+## Complementary architecture
+
+- DigiEmu verification reports can be used as deterministic evidence by external trust/responsibility systems.
+- TBN consumes evidence but remains responsible for identity, trust, attestation, and responsibility claims.
+
+## Non-overlap rules
+
+- DigiEmu Core must not certify agent identity.
+- DigiEmu Core must not perform trust scoring.
+- DigiEmu Core must not decide action authorization.
+- TBN must not replace DigiEmu deterministic decision-state reconstruction.
+
+## Example integration boundary
+
+- A DigiEmu `verify` JSON report is produced for a snapshot bundle.
+- TBN ingests the report as evidence, attaches agent identity and attestation, and evaluates trust/responsibility.
+- Decisions about identity, authorization, or trust remain in TBN; deterministic state integrity remains in DigiEmu.
+
+## Summary
+
+DigiEmu Core focuses on deterministic decision-state integrity and reproducible verification. TBN focuses on identity, attestation, and responsibility. Keep the layers separate and complementary.