# CoreAI Foundations

## Purpose

This document defines the founding constraints of CoreAI v1.

CoreAI exists to make operational context durable, readable, auditable, and usable by AI systems without locking the project to a provider or premature platform architecture.

## Founding Principles

### Context First

CoreAI treats context as the primary artifact. A runtime should load known, explicit, documented context before asking a model to reason.

### Filesystem Native

The filesystem is the base runtime surface. A CoreAI project must remain inspectable with standard tools such as `ls`, `cat`, `grep`, `git`, and text editors.

### Documentation Native

Markdown and YAML are not secondary outputs. They are official project interfaces for humans, maintainers, auditors, and AI systems.

### Human Readability

Every important artifact should be understandable without custom software. Machines can optimize access later, but humans must remain able to inspect the source of truth.

### Provider Independence

CoreAI must not depend on one model vendor, embedding service, proprietary memory layer, or hosted runtime.

## Runtime Philosophy

The runtime should be small and explicit:

- read files
- validate manifests
- compose bundles
- produce exports
- capture snapshots
- preserve forensic continuity

Anything beyond that must prove operational value before becoming part of the core.

## Architectural Constraints

CoreAI v1 does not introduce:

- microservices
- Kubernetes
- distributed coordination
- autonomous agent frameworks
- mandatory vector databases
- opaque memory systems
- provider-specific abstractions

## Stability Rule

CoreAI should prefer stable files and clear conventions over clever automation.