13 Conclusions
13.1 SE Process Outcomes
This capstone applied INCOSE systems engineering processes [1] to a rapid software-intensive project: building the open source infrastructure required to demonstrate AI-augmented MBSE workflows for a GVSETS 2026 publication. The SE process was not an end in itself but a disciplined means of ensuring the software systems, grammar tools, and evaluation framework are built on defensible foundations.
13.1.1 Review Gate Completion
Both formal review gates were completed on February 14, 2026, with the full team (Technical Lead, SE Lead, and Advisor) participating:
| Review | Target | Actual | Outcome |
|---|---|---|---|
| SRR | Jan 25 | Feb 14 | Complete with caveats |
| PDR | Feb 8 | Feb 14 | Complete with caveats |
The two-week SRR delay reflected a deliberate choice: rather than reviewing requirements in isolation, we allowed implementation to inform and validate the requirements before baselining them. This “implementation-informed review” approach proved more effective than a traditional waterfall gate — by the time SRR was conducted, every stakeholder requirement had been tested against working software.
13.1.2 Tailoring for Academic Scope
Per INCOSE Handbook 4.3.4, the SE processes were tailored for a software-intensive academic project with a three-person team and 15-week timeline. Key tailoring decisions, each documented with rationale:
| Tailored Element | Full INCOSE Process | Adopted Approach | Risk Accepted |
|---|---|---|---|
| Interface requirements | Formal IR-xxx identifiers in SyRS | Documented in ADD only | Potential traceability gap |
| Stakeholder validation | Formal interview protocol | Iterative development feedback | Less rigorous needs capture |
| Requirements evolution | Change control board after SRR | Baseline with understood mutability | Requirements may drift |
| Review formality | Separate SRR and PDR events | Combined assessment session | Less ceremony |
13.1.3 Requirements Traceability
The RTM (Section 16.1) maintains four trace layers covering 15 stakeholder needs, 15 stakeholder requirements, 34 system requirements, and 22 implemented test cases. All functional requirements trace upward to stakeholder needs and downward to architecture elements and verification activities.
13.1.4 Risk Management
Of nine identified risks, four were closed by implementation evidence (R3, R4, R7, R8), one was mitigated by architectural decisions (R1), and one was mitigated after scope expansion proved manageable (R6). Three risks remain open: R2 (GVSETS deadline pressure), R5 (container testing blocked on macOS), and R9 (tree-sitter org acceptance uncertain). The most significant risk closure was R8 (external scanner): the grammar achieved 100% training file coverage without requiring an external scanner, eliminating a major technical uncertainty. See Section 6.8 for the full register.
13.2 Technical Outcomes
The SE process produced three operational software systems and validated a dual-path grammar strategy:
13.2.1 tree-sitter-sysml: Production-Ready Grammar
The brute-force grammar achieved results that exceeded initial expectations:
| Metric | Target | Achieved |
|---|---|---|
| Corpus tests | 100% pass | 125/125 (100%) |
| Training file coverage | ≥50% | 100/100 (100%) |
| External file coverage | Not targeted | 274/275 (99.6%) |
| Query coverage | Not targeted | 190/190 (100%) |
| Development time | 8 weeks planned | ~25 hours actual |
The grammar supports all major SysML v2 constructs: packages, parts, actions, states, requirements, constraints, verification cases, views, metadata, allocations, and expressions. Context-sensitive definition bodies (part_body vs action_body) reduce over-acceptance. Six language bindings (C, Rust, Go, Python, Node.js, Swift) enable broad ecosystem integration.
13.2.2 open-mcp-sysml: MCP Server Phase 1
The Rust MCP server delivers five operational tools with L0/L1/L2 detail levels designed for an estimated 80-97% token reduction from naive approaches (to be validated by benchmark vignettes V1/V4/V5):
| Tool | Purpose | Token Impact |
|---|---|---|
sysml_parse |
Parse with configurable detail | L0: ~100 tokens, L2: full |
sysml_validate |
Return parse diagnostics | ~300 tokens |
sysml_list_definitions |
List all definitions | ~500 tokens |
repo_list_files |
List .sysml files in repository | ~200 tokens |
repo_get_file |
Read file from repository | Variable |
Twenty-two tests verify correctness across unit, integration, and MCP protocol compliance levels.
13.2.3 kebnf-to-tree-sitter: Spec-Driven Converter
The automated converter parses 640/640 KEBNF rules (100%) and achieves 93% automated conversion (38% direct mapping + 55% strip-and-convert), with 7% requiring manual intervention. The generated grammar has 335+ conflicts requiring iterative resolution — a process that is itself a research contribution documenting the gap between formal specifications and practical parsers.
13.2.4 Dual-Path Grammar Strategy Validated
The decision to maintain both empirical (tree-sitter-sysml) and formal (kebnf-to-tree-sitter) grammar paths proved valuable: the brute-force grammar provides immediate practical value while the spec-driven approach enables formal traceability and automated updates when OMG publishes spec revisions. Cross-validation between the two identifies spec interpretation errors in the hand-written grammar and practical parsing issues in the generated grammar.
13.3 Lessons Learned
13.3.1 Grammar Development Velocity
The tree-sitter-sysml grammar went from 10% to 100% training file coverage in approximately 20 hours of focused development. The key enablers were: (1) a simple test harness that provided immediate coverage feedback, (2) tree-sitter’s built-in error recovery allowing partial progress, and (3) the empirical “fix the next failing file” methodology that avoided premature optimization. This suggests that for textual notations with good training corpora, grammar development can be faster than conventionally assumed.
13.3.2 Scope Expansion as Ecosystem Understanding
The project expanded from 3 planned repositories to 7, adding a grammar benchmark dashboard, PhD research planning, and detailed publication strategies. Rather than impeding the core GVSETS deliverable, this expansion provided a richer understanding of the SysML v2 ecosystem that strengthens the paper’s future work articulation and positions the team for sustained contribution beyond the capstone.
13.3.3 Implementation-Informed Reviews
Conducting SRR and PDR after implementation began (rather than before) produced more meaningful reviews. Requirements were validated against working software rather than hypothetical designs. Architecture was confirmed by running code rather than paper analyses. This approach is consistent with agile SE practices for software-intensive systems, though it requires discipline to maintain formal traceability retroactively.
13.3.4 The SE/LSE Push-Pull Dynamic
The systems-engineer and lead-systems-engineer skill personas established a productive tension: the SE persona drafts comprehensively per INCOSE processes, while the LSE persona prunes pragmatically for project constraints. This dynamic produced artifacts that are both INCOSE-aligned and appropriately scoped — better than either perspective alone would achieve.
13.4 GVSETS Publication
The NDIA GVSETS 2026 paper (“Enabling AI-Augmented Model-Based Systems Engineering with the Model Context Protocol”) is drafted with all sections present in gvsets/paper/main.tex. The evaluation section contains placeholder data pending execution of benchmark vignettes V1, V4, and V5 (Section C.1) against the Eve Mining Frigate model.
The paper argues that MCP provides a practical integration path for AI-augmented MBSE, with projected token reduction ratios and accuracy comparisons across three conditions: baseline (naive file concatenation), vanilla MCP (simple tool calls), and optimized MCP (Cache ID + Summary pattern with L0/L1/L2 tiered responses).
Critical path to submission: Execute benchmark vignettes to replace placeholder data, then polish prose from outline-quality to submission-quality. Draft submission deadline is March 23, 2026.
13.5 Future Work
13.5.1 Deferred In-Scope Items
Several items from the original scope (Section 6) were deferred based on risk mitigation and prioritization decisions during the capstone:
- HTTP transport: Deferred to Phase 2; stdio transport is sufficient for local development and GVSETS evaluation
- SysML v2 API integration: Deferred post-capstone per R1 mitigation; local tree-sitter parsing provides sufficient validation
- Container deployment: Blocked by R5 (macOS testing limitations); deferred to Phase 2
13.5.2 Post-Capstone (Informal Sprint Model)
After the capstone deadline (April 25, 2026), development continues informally without formal INCOSE review gates:
- Token reduction Phase 2: Implement remaining 6 strategies from the PRD (Cache ID + Summary, RTFM Documentation, Two Meta-Tool Architecture, KV-Cache Optimization, Overflow Detection, Vanilla Baseline)
- tree-sitter-sysml 1.0: Complete pre-release cleanup (Phase 3 CI verification, Phase 4 tree-sitter org submission)
- Grammar benchmark dashboard: Wire tree-sitter adapter and corpus into sysml-grammar-benchmark for community comparison
- kebnf conflict resolution: Iterative resolution of 335+ conflicts, documenting patterns for the grammar transposition paper
13.5.3 Research Instrument: sysml.rs
A planned Rust implementation of full SysML v2 semantic analysis (import resolution, type checking, constraint evaluation) will serve as a research instrument for PhD work. This complements tree-sitter-sysml’s syntax-only capabilities with deep language understanding, enabling semantic-level comparison and context-aware MCP tool responses. See the PhD research portfolio for design documentation and timeline.
13.5.4 Publications
Three publications build on this capstone foundation (see Section B.1):
- GVSETS 2026 (Mar-Jun 2026): MCP architecture and proof of value
- Grammar Transposition (Q3-Q4 2026): KEBNF-to-tree-sitter methodology
- INCOSE 2027 (Q3 2027): SE benchmark for AI evaluation
13.5.5 Ecosystem Positioning
This project fills a specific gap in the SysML v2 tooling ecosystem: no MCP server exists for MBSE among 7,364+ public MCP repositories. The open source, provider-agnostic design (MIT license, GitLab as reference implementation) complements commercial platforms like SysGit rather than competing with them. The tree-sitter-sysml grammar fills the gap left by Sensmetry’s archived sysml-2ls language server, providing community-maintained SysML v2 parsing for any tree-sitter-compatible editor.
13.6 Acknowledgments
To be added prior to final submission.
13.7 References
See Section 15.1 for complete bibliography.