NAEP
A provider-agnostic engineering foundation for reusable AI-assisted software workflows
- My Role
- Founder, platform architect, and TypeScript engineer
- Platform
- Open-source TypeScript monorepo and command-line developer platform
Quick Overview
An early-alpha TypeScript platform and CLI for creating, inspecting, and validating structured engineering workspaces, with a roadmap toward reusable knowledge and provider-independent AI runtimes.
- Who it serves
- Developers and teams who want repeatable engineering standards, project structure, and AI-assisted workflows without tying their knowledge to one model provider
- Current status
- Active Build
Active early-alpha development. Dashboard, knowledge-engine, provider-runtime, and multi-agent gallery views are product-direction concepts, not shipped interfaces.
The Problem
AI-assisted projects often accumulate prompts, decisions, standards, and lessons in disconnected places. That makes good engineering practices difficult to reuse and leaves project quality dependent on whichever model or tool happens to be in use.
NAEP starts by standardizing the workspace itself: the files, directories, manifest, validation rules, and command-line operations that give future automation a dependable foundation.
The Solution
The implemented alpha separates reusable platform logic into @naep/core and exposes it through @naep/cli. The core package defines workspace structure, creates manifests and required directories, parses configuration, and reports validation issues.
The CLI currently exposes init, doctor, and workspace info commands. Broader knowledge-engine, runtime-provider, project-generation, and multi-agent capabilities are documented architectural direction rather than presented as finished features.
My Contribution
Platform direction
Defined the provider-agnostic principle: models are replaceable, while engineering knowledge remains the durable asset.
Monorepo architecture
Separated reusable workspace behavior into @naep/core and the developer interface into @naep/cli.
Workspace engine
Implemented workspace creation, manifest serialization and parsing, required-file checks, and structured validation results.
CLI engineering
Implemented init, doctor, and workspace info commands with Commander.js and distributable Node.js entry points.
Engineering governance
Established ADR, RFC, architecture, release, contribution, security, and platform specification foundations.
Key Features
Workspace initialization
The init command creates the required engineering workspace structure and a versioned naep.json manifest.
Workspace diagnostics
The doctor command checks required directories, files, and manifest validity and reports actionable issues.
Workspace inspection
The workspace info command validates a workspace before displaying its name, schema version, creation version, and path.
Reusable core package
Workspace behavior lives in @naep/core so other interfaces can reuse it without duplicating CLI logic.
Governance foundation
ADRs, RFC templates, contribution guidance, architecture documentation, and release artifacts make decisions reviewable.
Provider-independent roadmap
Runtime directories and specifications reserve clean boundaries for Ollama, OpenAI, Claude, Gemini, and future providers.
Technology
Implementation
Architecture
Architecture
Developer interface
@naep/cli
Commander.js commands provide workspace initialization, diagnostics, and inspection.
Platform logic
@naep/core
Reusable TypeScript APIs own workspace creation, validation, definitions, and manifest handling.
Workspace contract
naep.json + specifications
A versioned manifest and documented directory contract define a valid engineering workspace.
Future runtimes
Provider adapters
Documented boundaries reserve local and cloud runtime integrations without claiming they are complete.
The current executable path is intentionally small: CLI commands call @naep/core, which applies a versioned workspace definition and reads or writes naep.json. Knowledge engines, provider runtimes, project generators, and multi-agent systems remain roadmap layers behind those boundaries.
Product Gallery
These are AI generated concept UI images showing how the NAEP experience is being designed. They are not screenshots of a finished product.
Engineering Challenges
Turning principles into enforceable structure
A manifesto alone cannot make projects consistent. The first implementation challenge was translating platform principles into a concrete workspace contract that the CLI can create and validate.
Keeping the CLI thin
Workspace behavior needed to remain reusable outside the command line, so creation, validation, and manifest logic live in the core package while commands focus on user interaction.
Separating implementation from roadmap
NAEP has an ambitious multi-stage architecture. Clear versioning and documentation are necessary so future provider and agent plans do not get confused with the smaller alpha that exists today.
Results and Evidence
- Published the NAEP source repository with an Apache 2.0 license and contributor, security, release, ADR, and RFC foundations.
- The TypeScript @naep/core and @naep/cli packages compile successfully from the npm workspace build.
- Implemented executable init, doctor, and workspace info command paths in the alpha CLI.
What I Learned
Starting with workspace contracts made the platform idea testable before building model integrations: the CLI can already enforce whether a project has the structure NAEP expects.
Separating core logic from the CLI creates a cleaner path for future desktop, web, or agent interfaces to reuse the same rules.
Related Credentials
Explore Emerging Tech
IBM SkillsBuild
Issued Apr 25, 2026
See every credential on the Credentials and Learning page.