---
id: "concept-structural-context"
type: "concept"
source_timestamps: ["00:11:58", "00:12:05"]
tags: ["software-architecture"]
related: ["concept-context-engineering", "action-create-module-manifests"]
definition: "Embedded codebase documentation, such as module manifests, that explicitly maps out dependencies and answers 'where' code belongs architecturally."
sources: ["s23-amazon-16k-engineers"]
sourceVaultSlug: "s23-amazon-16k-engineers"
originDay: 23
---
# Structural Context

## Definition

**Structural Context** is embedded codebase documentation — typically module manifests — that explicitly maps out dependencies and answers the question of *where* code belongs architecturally.

## What a Structural Manifest Contains

For every module or service in the codebase:

1. **Purpose** — what this module does, in one paragraph.
2. **Outbound dependencies** — what external services/modules this code calls.
3. **Inbound dependencies** — what other services/modules depend on this code.

## Why It Suppresses [[concept-dark-code]]

Without structural context, AI agents must *guess* the architectural layout when generating new code. Guessing produces:

- Hidden, tangled dependencies
- Duplicate functionality across modules
- Architectural decisions humans cannot later untangle

With structural context, the AI is forced to respect existing topology because the topology is machine-readable.

## Relationship to [[concept-context-engineering-d23]]

Structural context is one of two pillars of context engineering. The other is [[concept-semantic-context]], which addresses *what* code is allowed to do rather than *where* it lives.

## Operationalization

See [[action-create-module-manifests]] for the concrete engineering action.