What you'll see
The steps are numbered as in the flow diagram below. A full run takes a few minutes per stage on a single local GPU. After each approval the DAS admin starts the next stage from Jobs in Pipeline; nothing moves without a recorded decision.
1UploadDAS
Pick a demo capability document (FIREBIRD UAV, IRONCLAD ground vehicle, SENTINEL cyber defense) or upload your own. PDF, Word and scanned pages are converted to Markdown by Docling (layout analysis and OCR); the original is kept with the job.
2ScreeningDAS
Every section is checked by k9x Shield and Granite Guardian for hidden instructions and manipulation. Hits go into a separate Document Screening Report for the reviewer: a warning, never a rejection.
3RequirementDAS
Squads build the architecture views, judge the requirement against the content the Service must submit for joint review, and propose a Joint Staffing Designator (JROC, JCB or FCB Interest, or Service Information).
4Service validationK9X HIL
The Service requirements board validates the requirement. In parallel, the Joint Capability Integration review by the JROC, JCB or FCB records its endorsement; it never holds the acquisition flow.
5MDD packageDAS
Draft AoA study guidance and study plan for the validated requirement.
6Materiel Development DecisionK9X HIL
The Milestone Decision Authority decides the phase of entry and the initial review milestone.
7MSA → Milestone A packageDAS
AoA summary and affordability, the Alternative Systems Review (a best-practice review leading to a draft performance specification), and a proposed acquisition strategy matched to a pathway, judged against the Milestone A criteria.
8Milestone AK9X HIL
The MDA approves entry into Technology Maturation and Risk Reduction and the acquisition strategy, including its pathway.
9TMRR: SRR packageDAS
System requirements with traceability to the requirement document, judged against the SRR criteria: consistent, measurable, testable.
10System Requirements ReviewK9X HIL
The Service-appointed technical review chair decides. The built flow ends here; later reviews and Milestone B are designed, not built.
Current as of October 2026
JCIDS was ended in 2025 and replaced by the Joint Force Requirements Process. DAS follows the documents in force today, and keeps the process in one dated, versioned file (process_model.yaml, version mca-2026-10) in which every stage and gate cites its source. When the policy changes, the file gets a new version; past jobs keep the version they ran under.
Requirements
SecDef memo, 20 Aug 2025 (Services validate their own requirements); CJCSI 5123.01J CH 1 and CJCSM 5123.01A, 5 Aug 2026 (Joint Force Requirements Process, JCI review, Joint Staffing Designators).
Acquisition
DoWI 5000.02 Change 2, 8 Apr 2026 (Adaptive Acquisition Framework, six pathways); DoDI 5000.85 (Major Capability Acquisition: MDD, MSA, Milestone A, TMRR). DoD Issuances.
Systems engineering
DoD Systems Engineering Guidebook, 2022: the Alternative Systems Review (best practice) and the System Requirements Review criteria.
The flow
One job, drawn from the process model itself. Blue: DAS prepares; green: a person decides in K9X HIL; amber: the joint review, in parallel.
Every decision (who, when, comment) is kept with the job and shown in Jobs in Pipeline.
Architecture
DAS is a solution built on K9-AIF: each part extends a framework building block, and the stages talk only through events.
Router → Orchestrators → Squads → Agents
The DAS Router routes each event to a stage orchestrator (Requirement, MSA, TMRR), taking the next stage from the process model. Orchestrators run squads; squads run agents in order, each enriching the shared context for the next. No layer knows its caller.
Event backbone (Kafka)
Stages and reviews are connected by topics, e.g. workflow.hil.das.mdd for the MDD review task and das.mdd.replies for the decision. Only the Router publishes to stage topics.
K9X HIL
A separate human-in-the-loop system. It receives review tasks, records the human decision, and publishes it back to the system that asked. hil.k9x.ai
Decisions and results kept by job
Each stage's result and each HIL decision is stored in object storage by job id, so Jobs in Pipeline survives restarts and a decision days later still resumes the right job.
Models, local
Agents run on a local model through Ollama on a single workstation GPU; Docling converts documents and Granite Guardian screens them, both local. No cloud model is used.
Knowledge corpus
Reference passages come from a vector store in PostgreSQL (pgvector): synthetic here, authoritative DoW sources in a real deployment. See Knowledge corpus below.
Roles
demo runs jobs and watches. admin also starts the next stage after a HIL approval: the analyst who runs a job is not the person who moves the program forward.
Knowledge corpus
A requirement package is stronger when it relates a new capability need to precedent programs and reference architectures, not just restates the input. DAS does this with retrieval, kept strictly separate from the submitted document's own facts.
1What is in it
In this demonstration, a synthetic, fictional corpus (data/synthetic_corpus/): three prior CDDs for made-up programs (TALON, MERIDIAN, GRIFFON), DoDAF 2.0 operational and systems/capability view authoring references, and a review-package reference. No real program or DoD data.
2How it is built
Each document is split into sections, each section is embedded with nomic-embed-text (768-dimension vectors, run locally through Ollama), and stored with its text and source in PostgreSQL.
3Where it is stored
PostgreSQL with the pgvector extension: table dow_knowledge_corpus in the dow database. Vectors live next to ordinary tables, under the same backups and access control; no separate vector database to run.
4How agents use it
The View Generator (and the Traceability squad's Link Proposer) ask the retriever for the closest passages (top 5) to the view being written. They are added to the prompt as supplementary reference, labelled as not part of the submitted document and never to be used as this program's facts. The submitted document always goes in directly.
In a real deployment: a DowRetriever
DAS uses K9Retriever, the framework's general retriever (it extends the BaseRetriever building block). A DoW deployment would add a DowRetriever: another BaseRetriever extension, plugged in the same way through configuration, pointed at authoritative DoW knowledge sources such as prior CDDs and ICDs from program repositories, DoDAF reference architectures, requirements and acquisition policy and regulations, and lessons learned. It would respect each source's classification and access rules, and its passages could be graphed alongside the requirement's own entities to show how a new need relates to precedent programs. The agents, squads and gates do not change; only the retriever's sources do. The DowRetriever is a design, not part of this demo.
Status in this hosted demonstration: the corpus and the pgvector table are configured but not yet loaded, so packages currently reflect the submitted document alone.
Built on the K9-AIF framework
K9-AIF (Agentic Integration Framework) is an architecture-first framework for building governed, secure, and enterprise-scale AI applications. Built on OOA/OOD principles and TOGAF-aligned, it brings consistency, governance, and auditability to agentic systems from day one. Every Router, Orchestrator, Squad and Agent in DAS extends a K9-AIF Architecture Building Block, so governance, human review and auditability are inherited, not hand-built per application.
Security checks that keep pace with new attacks. AI is now used to attack applications that are themselves built with AI: instructions hidden in documents, agents impersonating other agents, poisoned tool results. K9-AIF tracks these attack techniques as they are published, for example in the OWASP Top 10 for LLM Applications, and adds matching checks to the framework's governance pipeline. Solutions built on K9-AIF pick up the new checks with a framework upgrade, without rewriting their own agents. That is why K9X Sentinel was introduced: every day it reads newly published attacks and checks each one against the framework's security capabilities, so gaps are found and closed early. How this works ↓
The K9X ecosystem brings the framework to life with core components, including K9X HIL (human-in-the-loop decisions, the review gates in this demo), K9X Sentinel (above) and K9X Satan (an adversarial harness that fires attacks at a pipeline to prove its defences hold).
The framework keeps itself current: K9X Sentinel
New attacks on AI agents are published every week. Rather than waiting for an incident, K9X Sentinel watches for them every day and turns the ones that matter into framework checks, which every solution built on K9-AIF, including DAS, inherits on upgrade.
Try it in the demo: the Red-team Documents dropdown runs capability documents that carry an attack (hidden instructions, credential exfiltration, governance bypass, personal data, a paraphrased injection). Each states its expected outcome, and the result shows exactly which check stopped it, or that it got through to the human reviewer.
In practice: K9-AIF 1.14 closed gaps identified from the ThreatLabz 2026 report (signed agent identity, screening of tool results for injected instructions, a check for deceptive outbound links); 1.14.1 raised dependency floors after Sentinel's vulnerability audit. See sentinel.k9x.ai (read-only demo login; open gaps are redacted).
Scope of this demonstration
- Input documents are synthetic and fictional (no real program or DoD data); outputs have not been reviewed by acquisition experts.
- The reference knowledge corpus is synthetic as well, and is not yet loaded here: packages currently reflect the submitted document alone.
- Built: the Major Capability Acquisition pathway to Milestone A and the System Requirements Review. Later reviews (SFR, PDR), CDD-equivalent validation, Milestone B and the other five pathways are designed in the process model, not built.
- Paraphrased manipulation can pass both screening checks; the human reviewer and the agents' treatment of all document text as data are the next lines of defence.
- The review loop (request changes, revise the document, re-review) is designed, not built.
- This is a public demonstration: the logins above are shared, and runs are visible to the operator.
Where DAS sits
The requirement process feeds the six pathways of the Adaptive Acquisition Framework. DAS builds one path through them: the Joint Force Requirements Process into Major Capability Acquisition, from the Materiel Development Decision to Milestone A and the System Requirements Review. That lit path is what this demonstration runs; the rest is the landscape it fits into.
Sources: DoWI 5000.02 (pathways), DoDI 5000.85 (Major Capability Acquisition), CJCSI 5123.01J and CJCSM 5123.01A (requirements); built and designed steps come from DAS's process model.