Idea.md in place - Ready for bootstrap

Author: prophetadmin

.gitignore

@@ -0,0 +1,6 @@
+.DS_Store
+Thumbs.db
+.vscode/
+.idea/
+__pycache__/
+*.pyc

01_GENESIS/IDEA.md

@@ -0,0 +1,292 @@
+PROJECT IDEA — ARGUS TRACE
+
+Objective
+
+Build a local-first evidence trace and discrepancy review system for construction
+delivery artifacts.
+
+The system ingests schedule exports, meeting minutes, basis documents, action
+logs, and selected transmittals, then derives a traceable discrepancy graph
+showing where commitments, dates, and scope statements diverge across sources.
+
+The primary goal is not general chat or document search.
+The goal is controlled contradiction detection, trace surfacing, and reviewable
+evidence bundles.
+
+The system must allow a user to ask questions such as:
+
+- What dates for Module Set A energization are stated across all sources?
+- Which commitments in meeting minutes are unsupported by the current basis?
+- What changed between Revision B and Revision C of the execution narrative?
+- Which action items appear to conflict with the approved schedule logic?
+- Where do downstream summaries appear to overstate source certainty?
+
+The result is a governed local application that produces deterministic trace
+artifacts, discrepancy records, and human-review packets.
+
+
+Scope
+
+In Scope
+- local ingestion of selected project artifacts
+- normalization into canonical text artifacts
+- source registration with immutable provenance records
+- extraction of claims, dates, entities, and commitments
+- derivation of cross-document trace links
+- contradiction / discrepancy detection
+- confidence-scored review queues
+- exportable evidence packets for human validation
+- resumable project state and deterministic re-entry
+- minimal local UI or review surface
+
+Out of Scope
+- cloud sync
+- OCR for scanned image-only PDFs unless an explicit fallback phase is defined
+- autonomous correction of source documents
+- real-time collaboration
+- enterprise authentication
+- replacement of Primavera, Aconex, SharePoint, or document control systems
+- final truth adjudication without human review
+
+
+Desired End State
+
+A user can point the system at a controlled folder of project artifacts and obtain:
+
+1. canonical normalized artifacts
+2. claim/commitment extraction artifacts
+3. trace-link artifacts connecting related statements
+4. discrepancy records with cited evidence
+5. review packets for human adjudication
+6. a persisted state surface allowing deterministic continuation after interruption
+
+
+System Shape
+
+The system is composed of six logical layers:
+
+1. Intake Layer
+   Accepts raw files and registers them.
+
+2. Canonicalization Layer
+   Converts accepted files into normalized canonical text artifacts plus metadata.
+
+3. Extraction Layer
+   Extracts structured statements such as commitments, dates, quantities,
+   milestones, and responsibility assignments.
+
+4. Trace Layer
+   Links extracted statements across artifacts using deterministic matching rules
+   and bounded semantic assistance.
+
+5. Discrepancy Layer
+   Detects divergence, contradiction, omission, and unsupported restatement.
+
+6. Review Layer
+   Presents discrepancy records and evidence packets for human disposition.
+
+The exact boundary between Trace Layer and Discrepancy Layer is intentionally
+not fully fixed and may require clarification during roadmap generation.
+
+
+Primary Inputs
+
+Expected raw sources may include:
+- .pdf basis documents
+- .docx meeting minutes
+- .xlsx action registers
+- .xer-derived schedule exports converted to .xlsx or .csv
+- .txt or .md execution narratives
+- .msg exports if already converted to text
+- manually entered user notes placed in a controlled folder
+
+The exact supported minimum file set for a first runnable version is not fully
+defined and should be resolved during planning.
+
+
+Primary Outputs
+
+Expected outputs include:
+- canonical text artifacts
+- provenance sidecars
+- extraction records
+- trace-link records
+- discrepancy records
+- review queue indexes
+- review packet bundles
+- state and run manifests
+- failure reports for rejected files
+
+
+Hard Invariants
+
+1. Filesystem Authority
+   Repository artifacts are authoritative.
+   Conversational memory is non-authoritative.
+
+2. Write-Once Evidence
+   Canonical evidence artifacts are immutable once emitted.
+   Corrections create successor artifacts rather than in-place mutation.
+
+3. Stable Provenance
+   Every derived artifact must point to its direct parent artifact(s).
+
+4. Deterministic Re-Entry
+   A new session must be able to resume from repository state alone.
+
+5. Review Before Promotion
+   No discrepancy may be marked resolved without an explicit human disposition artifact.
+
+6. No Silent Merge
+   If two extracted claims are collapsed into one trace identity, that merge must
+   be represented explicitly in an artifact.
+
+7. Bounded Inference
+   Language-model assistance may propose links or discrepancies, but proposals
+   must be written as reviewable artifacts and never treated as accepted truth
+   by default.
+
+8. Address Contract
+   Canonical artifacts must be emitted beneath:
+
+   02_EXODUS/runtime_store/projects/<project_slug>/artifacts/
+
+   using a two-hex fan-out directory structure.
+
+9. Manifest Contract
+   Every execution run must emit:
+
+   05_NUMBERS/runs/<run_id>/run_manifest.json
+
+10. Review Queue Contract
+    Open discrepancy queue state must be reconstructible from filesystem artifacts
+    even if any cache database is deleted.
+
+11. Packet Export Contract
+    Every exported review packet must contain exactly one packet manifest, at least
+    two cited evidence excerpts, and one machine-readable discrepancy record.
+
+12. No Cross-Project Bleed
+    Artifacts from one project slug must never be linked into another project slug
+    unless an explicit federation contract exists.
+
+13. Local Path Reservation
+    The following path is reserved and must not be repurposed:
+
+    04_DEUTERONOMY/canonical_schemas/trace_identity.schema.json
+
+14. Human Label Constraint
+    A reviewer may assign custom labels, but system behavior must not depend on
+    free-text labels alone.
+
+
+Soft / Ambiguous Constraints
+
+These are intentionally under-specified and should force roadmap clarification:
+
+- “Important” contradictions should surface first, but importance is not yet formally defined.
+- Similar dates may or may not represent the same milestone depending on source context.
+- Meeting minutes may be treated as lower authority than approved basis documents,
+  but that authority ladder is not fully frozen.
+- Some schedule-derived dates may be considered operational rather than contractual,
+  though the distinction is not yet formalized.
+- The first UI may be a browser surface, terminal workflow, or static review export.
+- It is preferred that extraction be deterministic where possible, but some bounded
+  semantic interpretation is acceptable if explicitly recorded.
+- A discrepancy may include omission, contradiction, unsupported summary, or drift,
+  but the exact taxonomy may need refinement.
+- The system should be “fast enough for practical use” on a local workstation, but
+  no explicit performance threshold is yet fixed.
+- The initial supported project size may be a few hundred files or several thousand;
+  this is not locked.
+- It is unclear whether transmittals should be treated as evidence, metadata only,
+  or intake-control artifacts.
+
+
+Seeded Governance Tension
+
+The project intentionally contains a few tensions that planning must resolve:
+
+- deterministic extraction vs model-assisted trace proposals
+- immutable canonical artifacts vs iterative review outcomes
+- local filesystem authority vs optional cache/index acceleration
+- strong provenance vs practical usability
+- review packet export vs minimal first runnable scope
+
+
+Proposed Artifact Families
+
+Potential artifact families include:
+- source_registration
+- canonical_text
+- canonical_meta
+- extraction_claim
+- extraction_commitment
+- extraction_date
+- trace_identity
+- trace_edge
+- discrepancy_record
+- discrepancy_packet
+- human_disposition
+- run_manifest
+- rejection_record
+
+These names are suggestive, not final.
+Planning may revise them if done explicitly.
+
+
+Invented Example Constraints
+
+- Project slug example: west_delta_demo
+- Reserved reviewer ID format: RVW-###
+- Discrepancy ID prefix: DISC-
+- Trace identity ID prefix: TID-
+- Packet ID prefix: PKT-
+- Run IDs should be time-sortable
+- At least one artifact should preserve exact source excerpt byte offsets if available
+- If byte offsets are unavailable, the fallback locator format is not yet fixed
+- A “red folder” intake class may exist for disputed documents, but behavior is not defined
+- One future integration path may target a local graph store at:
+
+  02_EXODUS/runtime_store/graph_cache/
+
+  but this integration is not required for the first executable version
+
+
+Failure Philosophy
+
+- Fail closed on provenance uncertainty.
+- Fail open on optional enrichment.
+- Reject unsupported file types explicitly.
+- Do not discard contradictory evidence merely because a higher-authority source exists.
+- Preserve rejected-input records for audit.
+- Prefer explicit review artifacts over hidden runtime judgment.
+
+
+Example User Outcomes
+
+A planner or controls lead should be able to:
+- review all conflicting milestone dates for a named deliverable
+- inspect the exact excerpts that created a discrepancy
+- export a packet for team review
+- resume prior work after interruption without conversational context
+- distinguish machine-proposed links from human-accepted conclusions
+
+
+Open Questions Intentionally Left Unresolved
+
+- What exact authority order should govern source classes?
+- What minimum artifact set defines “Phase 1 runnable”?
+- Should schedule logic be parsed structurally or only through exported text tables?
+- Is the first review surface an app, CLI flow, or packet-only workflow?
+- What discrepancy categories are mandatory in v1?
+- What exact success criteria define acceptable trace precision?
+- When should semantic assistance be allowed to create candidate links?
+- How are superseded source revisions detected and represented?
+
+Success Condition
+
+The project succeeds when a bounded local system can ingest a controlled sample
+set, produce canonical and trace artifacts, surface discrepancy records with
+evidence, and support deterministic review continuation using repository state
+alone.

01_GENESIS/PROJECT_SEED.md

@@ -0,0 +1,33 @@
+# PROJECT_SEED.md
+
+This scaffold placeholder does not count as a generated seed artifact until it
+is replaced with seed content that follows
+`03_LEVITICUS/Core/GENESIS_SEED_PROMPT_v1.md`.
+
+This file is created during the bootstrap phase of a MetaDictum-governed project.
+
+Purpose
+Capture the initial project idea or problem statement that will be transformed into a structured execution roadmap.
+
+Source
+Generated by running `/seed` with:
+
+`03_LEVITICUS/Core/GENESIS_SEED_PROMPT_v1.md`
+
+from
+
+`01_GENESIS/IDEA.md`
+
+Lifecycle
+
+`01_GENESIS/IDEA.md`
+-> `/seed`
+-> `PROJECT_SEED.md`
+-> requirements normalization
+-> roadmap generation (`/create_map_v2`)
+
+Notes
+
+* This file does not exist until the seed prompt is executed.
+* The seed represents project intent, not the implementation plan.
+* The requirements ledger, component realization map, and roadmap are derived from this seed during bootstrap.

01_GENESIS/REQUIREMENTS_LEDGER.md

@@ -0,0 +1,39 @@
+# REQUIREMENTS_LEDGER.md
+
+This scaffold placeholder does not count as a generated requirements ledger artifact until it
+is replaced with schema-conforming requirements content.
+
+This file is created during the bootstrap phase of a MetaDictum-governed project.
+
+Purpose
+Normalize the project seed into a binding requirements and component inventory for roadmap generation.
+
+Generation
+Created during `/create_map_v2` bootstrap preprocessing by applying:
+
+`03_LEVITICUS/Core/REQUIREMENTS_DERIVATION_PROMPT_v1.md`
+
+to
+
+`01_GENESIS/PROJECT_SEED.md`
+
+Structure
+This file must conform to:
+
+`03_LEVITICUS/Core/REQUIREMENTS_LEDGER_SCHEMA_v1.md`
+
+Lifecycle
+
+`01_GENESIS/IDEA.md`
+-> `/seed`
+-> `PROJECT_SEED.md`
+-> requirements derivation
+-> `REQUIREMENTS_LEDGER.md`
+-> roadmap generation (`/create_map_v2`)
+
+Notes
+
+* This file does not count as generated until it is replaced with schema-valid requirements content.
+* The requirements ledger is a binding planning input for roadmap generation.
+* The roadmap must not be generated until this file exists and conforms to schema.
+* `/create_map_v2` must treat this ledger inventory as binding for coverage and phase planning.

02_EXODUS/templates/.gitkeep

@@ -0,0 +1 @@
+