diff --git a/docs/ARCHITECTURE.md b/docs/ARCHITECTURE.md
new file mode 100644
index 0000000..44d826e
--- /dev/null
+++ b/docs/ARCHITECTURE.md
@@ -0,0 +1,27 @@
+# Architecture
+
+## Purpose
+
+This document will become the central architecture overview for HoopScout v2. It should summarize the current approved technical direction and provide a stable starting point for future implementation work.
+
+## Current Status
+
+This is a phase-1 placeholder. The architecture is not yet fully defined, and implementation should not proceed from undocumented assumptions.
+
+## Decision-Driven Development
+
+Architecture in this repository should be decision-driven. Major technical choices should be documented before implementation begins, and implementation should follow documented decisions rather than informal local reasoning.
+
+## Relationship to ADRs
+
+This document should stay aligned with the ADR set in `docs/adr/`. ADRs capture specific decisions and their rationale. This overview should summarize the accepted decisions at a higher level, not replace the ADR record.
+
+## Future Sections Placeholder
+
+Future versions of this document may include sections such as:
+- system context
+- major components
+- data flow
+- deployment/runtime assumptions
+- integration boundaries
+- operational considerations
diff --git a/docs/PHASE_1.md b/docs/PHASE_1.md
new file mode 100644
index 0000000..5e8aac0
--- /dev/null
+++ b/docs/PHASE_1.md
@@ -0,0 +1,51 @@
+# Phase 1
+
+## Purpose
+
+Phase 1 defines the technical decision-making framework that must be completed before implementation begins. This phase is about making and documenting core technical choices in a clear order so future work follows shared decisions rather than assumptions.
+
+## Scope
+
+Phase 1 establishes how technical and architectural decisions will be recorded, reviewed, and used to guide later implementation tasks.
+
+## In Scope
+
+- defining the major technical decisions required before implementation
+- documenting architecture decisions in a durable repository-owned form
+- establishing the relationship between architecture overview documents and ADRs
+- clarifying the minimum decision set required before implementation starts
+
+## Out of Scope
+
+Until the phase-1 decision framework is complete, do not:
+- start application implementation
+- introduce runtime services
+- choose implementation details that depend on unresolved architecture decisions
+- expand into feature delivery work
+- treat undocumented assumptions as approved decisions
+
+## Expected Outputs
+
+Phase 1 should produce:
+- a maintained phase-1 decision plan
+- a central architecture overview document
+- a set of ADRs covering major technical choices
+- clear implementation preconditions for the next phase
+
+## Decision Order
+
+Make decisions in this order:
+
+1. Define the required decision areas.
+2. Record the ADR process and naming conventions.
+3. Establish the architecture overview and its relationship to ADRs.
+4. Document major technical decisions in ADRs.
+5. Confirm that implementation-critical choices are explicit and aligned.
+
+## Exit Criteria for Phase 1
+
+Phase 1 is complete when:
+- the decision framework is documented
+- the architecture overview exists and points to ADRs
+- required major technical decisions are recorded as ADRs
+- implementation can begin without relying on undocumented assumptions
diff --git a/docs/adr/README.md b/docs/adr/README.md
new file mode 100644
index 0000000..ea24b08
--- /dev/null
+++ b/docs/adr/README.md
@@ -0,0 +1,64 @@
+# ADRs
+
+## What an ADR Is
+
+An ADR, or Architecture Decision Record, is a short document that captures one important technical decision, its context, and its outcome.
+
+## When To Create One
+
+Create an ADR when a decision:
+- affects architecture or major technical direction
+- changes implementation constraints for future work
+- needs durable reviewable documentation in the repository
+
+## Minimum ADR Template
+
+Each ADR should include at least:
+- title
+- status
+- date
+- context
+- decision
+- consequences
+
+Minimal example:
+
+```md
+# ADR-0001: Example Decision
+
+- Status: proposed
+- Date: YYYY-MM-DD
+
+## Context
+
+What problem or uncertainty is being resolved?
+
+## Decision
+
+What was chosen?
+
+## Consequences
+
+What follows from this decision?
+```
+
+## Status Values
+
+Use these status values:
+- proposed
+- accepted
+- superseded
+- rejected
+
+## Naming Convention
+
+Name ADR files using a numeric prefix and a short slug:
+
+```text
+ADR-0001-short-decision-name.md
+ADR-0002-another-decision.md
+```
+
+## Relationship to Implementation Tasks
+
+Implementation tasks should follow documented ADRs when they depend on architecture decisions. If an implementation task exposes a new major technical decision, record the decision first or explicitly resolve it as part of the task before implementation proceeds.