# Code Elevation — Static Model

> **Version:** 1.0 | **Last Updated:** 2026-02-25  
> **Purpose:** Map the anatomy of the existing codebase: components, responsibilities, data model, API surface, and dependencies. Generated by the AI collaborator during Code Elevation Stage 1. The team validates and enriches with context not evident in the code.  
> **Usage:** The AI populates this file during the session. The team validates before proceeding to Stage 2.

---

## Session Info

| Field | Value |
|-------|-------|
| **Brownfield Intent** | [Intent description] |
| **Codebase Analyzed** | [Modules/folders in scope] |
| **Date** | [YYYY-MM-DD] |
| **Validated by** | [Team members who reviewed] |

---

## Component Inventory

| Component | File/Module | Responsibility | Lines (approx.) |
|-----------|-------------|---------------|-----------------|
| [Name] | [Path] | [What it does] | [N] |

---

## Component Relationship Diagram

> Visual map of how components depend on each other and on external services.
> For simple codebases, a dependency tree suffices. For complex systems, use a
> full component diagram showing direction of dependencies.

```
+-------------------+     +-------------------+     +-------------------+
|   API Router      | --> | Order Service     | --> | OrderRepository   |
+-------------------+     +-------------------+     +-------------------+
                               |                         |
                               | calls                   | reads/writes
                               v                         v
                          +-------------------+     +-------------------+
                          | Payment Gateway   |     | DynamoDB          |
                          | (external)        |     | OrdersTable       |
                          +-------------------+     +-------------------+
```

> **For single-component codebases:** Replace the diagram with a dependency
> tree showing the component's external dependencies (SDKs, services, stores).

---

## Identified Responsibilities

> If responsibilities are mixed in a single file, list them here with where they should be.

| Responsibility | Current Location | Should Be |
|---------------|-----------------|-----------|
| [e.g., HTTP routing] | [File:lines] | [Separate router module] |

---

## Data Model

> Document each table/store, its attributes, keys, and indexes.

### [Table/Store Name]

| Attribute | Type | Key | Notes |
|-----------|------|-----|-------|
| [name] | [S/N/BOOL/M/L] | [PK/SK/GSI/—] | [Constraints, defaults, observations] |

**Indexes:** [List GSIs/LSIs or note "None"]

---

## API Surface

| Method | Path | Request | Response | Auth | Notes |
|--------|------|---------|----------|------|-------|
| [GET/POST/...] | [/path] | [Body/params] | [Shape] | [Type or None] | [Observations] |

---

## Dependency Map

> External services, SDKs, and infrastructure the codebase depends on.

| Dependency | Type | Version | Usage | Notes |
|-----------|------|---------|-------|-------|
| [e.g., AWS SDK v2] | [SDK/Service/Library] | [Version] | [What uses it] | [Deprecation, risk] |

---

## Interface Contracts

### External (API)

> What callers of this system expect.

| Contract | Format | Consumers | Documented? |
|----------|--------|-----------|-------------|
| [e.g., REST API] | [JSON] | [Who calls it] | [Yes/No/Partial] |

### Internal (Data Store)

> What the system expects from its data layer.

| Contract | Store | Access Pattern | Notes |
|----------|-------|---------------|-------|
| [e.g., Task lookup by ID] | [DynamoDB] | [GetItem PK=id] | [Observations] |

---

## Key Observations

> Findings that don't fit the tables above. Flag unclear responsibilities, naming mismatches, dead code, or patterns that need developer clarification.

- [Observation 1]
- [Observation 2]
