# Architecture Policy

**Base Policy Version:** 1.0

**Last Updated**: 2026-09-06

## Base Policy Template

This document is the base template for the canonical architecture policy,. Repositories that implement this policy should:

1. Revise this document to include an architectural policy tailored to the implementing repository, including a description of the repository's purpose, overall intended system shape, and any architectural and/or engineering invariants that must be maintained during future development;
2. Ensure that any supporting documents referenced in the architecture policy are present on the filesystem, even if the initial content is simply `TODO`;
3. Update the `Last Updated` field to the current date; and
4. Remove this heading (`Base Policy Template`) and the associated text. 

As compared to other base policy documents, the Architecture Policy is the document that should be most heavily customized and tailored to the intended architecture of a particular application.

## Purpose

This policy defines the purpose of this repository and the architectural principles that contributors
must follow during development.

TODO: Complete this document.

Non-limiting examples of topics that may be addressed by an architectural policy include:
- Adherence to a hexagonal architecture, including whether external integrations/APIs must be encapsulated within internal adapters (strongly recommended)
- Whether a library is intended to provide a highly flexible API that supports a variety of downstream consumers, or a strongly opinionated API that is intended to enforce consistency across downstream consumers
- Whether an application should support a full DAG, or alternatively a strongly ordered sequence of discrete stages
- Whether the application should use specific external libraries to provide key functionality (e.g., FeedKit, ConfigKit, PromptKit)
- Any explicit architectural non-goals