LAMP — Language-Agnostic Module rePresentation - A3RN LLC
LAMP — Language-Agnostic Module rePresentation
May 18, 2026
A proposal for an intermediate representation that captures software modularity before code is generated.
1. Overview
1.1 Motivation
Agentic coding assistants generate code that compiles and passes tests. Depending on the model and context size, the generated code often lacks coherent modular structure and code hygiene.
The artifacts that feed generation don't address modularity.
Requirements and tests describe behavior, not decomposition.
Design and tasks describe approach, not module contracts.
Language-Agnostic Module rePresentation (LAMP) fills the gap with a reviewable artifact that commits to modular intent before code exists: what each module encapsulates and exposes, the capability contracts the agent must honor, and a modularity audit that gates generation rather than reviewing it afterward.
1.2 What LAMP is
LAMP sits between architectural component-level design and code. It captures a system's modular structure in a form reviewable before any implementation exists. The agent or human generating code is then constrained where it matters (module boundaries, encapsulation, observable contracts) and free where it doesn't (types, languages, data structures, concurrency). It also shrinks the context window, saving token costs.
LAMP serves two goals:
Module Review: a target for human review and modularity auditing before code changes.
Code Generation: a contract the agent honors when producing code and tests.
LAMP is part of a software development pipeline:
DESIGN<br>→ decompose into modules around encapsulated decisions<br>LAMP<br>→ generate implementation honoring the contracts<br>CODE
LAMP rests on four principles drawn from established modularity practice:
Information hiding. Each module is organized around a design decision it encapsulates. Callers depend on the interface. The encapsulated decision can change without disturbing them.
Deep abstractions. A module's value is proportional to how much implementation it hides behind how small an interface.
Decomposition by change axis. Modules are drawn around what is likely to change, not around data structure or algorithm steps.
Stable contracts. A module's interface is more stable than its implementation, and more stable than the requirements that motivated it.
2. Document layout
A LAMP artifact is a directory of Markdown files.
lamp/<br>capability.md # capability registry<br>modules.md # All module manifests
A single file is the default because LAMP modules are small. When a system has many modules or capabilities and a single file grows unwieldy, split them across several files. Name a module file with a module prefix (e.g., module-.md) to group related modules. Name a capability file with a capability prefix (e.g., capability-.md).
3. The module specification
The module manifest answers three questions: what does this module hide, what does it offer, what does it need? Each module is a top-level section in modules.md, with these subsections in order. All are required.
# Module:
## Encapsulates<br>The design decision or complexity this module hides. State it in<br>caller irrelevant terms.
## Provider Capabilities<br>Markdown links into the capability registry in `capability.md`, one per<br>line.
- [issue-session](capability.md#capability-issue-session)<br>- [resolve-session](capability.md#capability-resolve-session)<br>- [revoke-session](capability.md#capability-revoke-session)
## Consuming Capabilities<br>Markdown links into the capability registry, one per line.<br>Dependencies are on capabilities, never on other modules directly.
- [monotonic-clock](capability.md#capability-monotonic-clock)<br>- [opaque-bytes-storage](capability.md#capability-opaque-bytes-storage)
3.1 Authoring rules
Encapsulation is named in caller-irrelevant terms. "How sessions are stored, expired, and revoked" — good. "Uses Redis with TTL" — leaks.
Capability names don't leak implementation. flush_to_disk() leaks; commit() doesn't. cache_evict() leaks; forget(handle) doesn't.
Dependencies are on capabilities, not modules. Say opaque-bytes-storage, not PostgresStore.
No types, signatures, or language idioms. Promise> is implementation.
4. The capability specification
Capabilities live in capability.md's registry. Each is declared once. The heading format is fixed. Module manifests link to capabilities by anchor, so the heading is part of the contract.
### capability:
Description: one sentence on what this accomplishes for a caller.
Inputs: Description of inputs.
Outputs: Description of outputs.
Requires: what must hold for the capability call to be valid.
Guarantees: what is true on successful completion.
Failure modes: caller meaningful error categories.
Providers: List one or more providers who implement the capability. The capability registry and module manifests form a navigable graph in both directions.<br>- [](modules.md#module-)<br>-...