Revenue Plays · Proposal System
Chase Defense Partners AI Proposal System
Chase Defense Partners operates a deliberately minimal AI proposal system for defense-contracting work. The system is built around two Python tools, Anthropic Claude API inference, and Obsidian markdown vaults. Its central lesson is not technical sophistication; it is disciplined scope control. The system exists to produce business output: parse solicitations, generate proposal drafts, support debriefs, ingest lesson…
wiki/wiki/business-operations/chase-defense-ai-proposal-system.mdAnswer
Chase Defense Partners operates a deliberately minimal AI proposal system for defense-contracting work. The system is built around two Python tools, Anthropic Claude API inference, and Obsidian markdown vaults. Its central lesson is not technical sophistication; it is disciplined scope control. The system exists to produce business output: parse solicitations, generate proposal drafts, support debriefs, ingest lesson…
Auto-generated neutral summary from the source page — needs human review before trusted use.
Evidence & Source Cards
artifacts/chase-defense-ai-proposal.htmlexistsSource Excerpt
Summary
Chase Defense Partners operates a deliberately minimal AI proposal system for defense-contracting work. The system is built around two Python tools, Anthropic Claude API inference, and Obsidian markdown vaults. Its central lesson is not technical sophistication; it is disciplined scope control. The system exists to produce business output: parse solicitations, generate proposal drafts, support debriefs, ingest lessons, and preserve proposal memory in a human-readable structure.
The source document was provided in session 20260522_084157_8994a5c4 as message.txt and later converted into an HTML artifact. The document describes the system state as of May 2026: active production use, first proposal ingested, first debrief completed, Karpathy-style Large Language Model knowledge base restructure in progress, and an SBIR submission pending.
System Shape
The architecture has two persistent tools on a single Windows 11 ARM64 workstation:
- Proposal AI — handles solicitation parsing, draft generation, debrief facilitation, and memory ingestion.
- Dev Assistant — handles development-session briefings, project memory management, and lessons-learned capture.
Both tools use Claude Opus 4.7 via API for current operations. There is no GPU, no local inference, no scheduler, no containerization, no Multi-Agent Orchestration coordination, and no messaging gateway. The operator runs direct CLI commands; the tool responds.
The memory substrate is Obsidian. Proposal AI uses an Obsidian vault for proposal memory, wikilinks, solicitation artifacts, drafts, debriefs, and learned patterns. Dev Assistant uses a separate Obsidian vault outside OneDrive to avoid sync/file-locking problems and to manage the development stack itself.
Proposal AI
Proposal AI is described as a three-file Python application:
parse_solicitation.py— main script and CLI command surface.prompt_templates.py— all Claude prompts isolated for tuning.obsidian_writer.py— all vault read/write operations centralized for path management.
The command set covers the full proposal lifecycle:
- parse a solicitation PDF and generate a submission-ready draft;
- run a needs assessment against current memory;
- ingest past proposals into the memory wiki;
- conduct an interactive debrief with auto-saved transcript;
- learn from team-annotated debriefs;
- update memory after a win;
- update memory after a loss and feedback.
The system explicitly avoids AI-generated pricing. Pricing is treated as a human decision requiring internal validation. The AI may extract reps/certs and proposal artifacts, but pricing amounts are not delegated to the model because the liability and business judgment remain human.
Dev Assistant
Dev Assistant is a single Python file, dev_session.py, that solves the development cold-start problem. It has two commands:
--start [project]generates a session briefing from project memory and writes it toSESSION.md.--chat [project]starts an interactive development session with persistent memory, where aSAVEaction updates project memory.
Its purpose is Meta AI-operational: help the operator return to development work without reconstructing context from scratch. It reads progress, decisions, next steps, and lessons, then captures new lessons so the same mistake is not repeated.
Knowledge Management Pattern
The system is transitioning from flat memory to a Karpathy-style Large Language Model knowledge base. The source document explicitly rejects a previously planned vector/RAG approach at the current scale. The rationale is practical:
- under roughly 100 documents, a curated markdown wiki is easier to inspect and maintain;
- RAG returns disconnected chunks, while wiki pages preserve coherent context;
- wiki pages are auditable and human-editable;
- compliance-grade defense outputs benefit from visible provenance;
- compile cost is paid during ingest and amortized over future proposal generation.
The planned memory structure includes operating instructions, capabilities, needs assessment, people, past performance, teaming partners, and patterns such as win themes, loss lessons, compliance patterns, and writing style.
Governance and Reliability
The system keeps authority with the human operator. AI generates drafts, proposes memory updates, identifies gaps, and facilitates debriefs. The operator reviews, edits, commits, and decides. Nothing auto-submits. Git was initialized for Proposal AI on May 19, 2026, with an initial commit before the Karpathy restructure. Future signed commits and GitHub backup are planned.
The audit trail is central. Every solicitation, draft, transcript, debrief, and memory update persists in the vault with timestamps and wikilinks. Memory updates should record which proposal triggered the change. That is important for proposal work because lessons must remain traceable to actual outcomes.
Design Lessons
This system is a useful counterweight to overbuilt agent infrastructure. Its design principles are clear:
- Simplicity over sophistication: every component must justify itself against doing nothing.
- Ship before optimize: a working business tool beats elegant unused infrastructure.
- Beginner-maintainable: the operator is a domain expert, not a software engineer.
- Cloud-first, local-deferred: local inference is a possible future option, not a current requirement.
For Clark Farming Company, the durable lesson is that AI operational architecture should be sized to the business loop. The Chase Defense system does not need Multi-Agent orchestration to create value. It needs reliable proposal memory, draft generation, debrief capture, and human review.
Known Limitations
The source document is candid about limitations: single-operator design, no multi-user support, no automation, no Multi-Agent Orchestration coordination, API dependency, no fine-tuning, and OneDrive synchronization caveats. Those limitations are not necessarily flaws. They are conscious tradeoffs made to preserve maintainability and focus.
The page should be treated as a reference architecture for a narrow, business-output-first AI system: one operator, one clear use case, markdown memory, Git rollback, and frontier API inference until business value justifies more infrastructure.
Relationships
Outbound links
- AI-Enabled Business Services Strategycorpus
- Local-First Hermes Runtime Architecturecorpus
- Multi-Agent Orchestrationcorpus