System Intent Brief

Project: TacticalMessaging
Source: compliance.md
Working intent: Deliver a reference example, built on the BogDB graph database NuGet package, that shows how Cypher queries can model, govern, and interrogate tactical messaging compliance and traceability for a US military development program.

Problem

Tactical messaging programs (Link 16, VMF, and related standards) generate dense webs of requirements, policy constraints, translator components, test cases, and review decisions. These relationships are typically spread across documents, spreadsheets, and review notes, making it hard to answer routine traceability and compliance questions:

• Which requirements apply to a given message family, node type, or component?
• Which translator components satisfy a given requirement, and which test cases verify it?
• Which policy constraints (e.g., Link 16 MessageType.name formatting, MIL-STD-6017 vocabulary restrictions) are violated by current data?
• What is the evidence chain behind a compliance claim, and who approved each step?

TacticalMessaging is intended as a concrete worked example demonstrating that a graph database (BogDB) with Cypher-style queries is a strong fit for this domain. It should be useful to developers evaluating BogDB, and credible to compliance-minded reviewers familiar with tactical messaging.

This is a reference example, not a deployed program tool. Its value is measured by how clearly it teaches the modeling and query approach.

Operators and Stakeholders

Primary actors in the modeled domain

• Agency operator — captures and manages tactical messaging compliance records and reviews.
• System administrator — governs vocabularies, policy rules, and access in the modeled system.
• Compliance reviewer / analyst — traces requirements to components, tests, policies, and decisions.
• Applicant / submitter — supplies a request or artifact package for review.

Audiences for the example itself

• .NET developers evaluating BogDB as a NuGet dependency for graph-modeled domains.
• Systems and compliance engineers in tactical messaging programs assessing whether a graph approach fits their traceability problem.
• Architects and tech leads looking for a worked pattern combining Cypher queries with a domain-rich governance model.

Desired Outcomes

• The example clearly demonstrates how tactical messaging requirements, components, tests, policies, and decisions can be modeled as a graph.
• A reader can see Cypher queries that answer realistic traceability and compliance questions end-to-end.
• The example captures the core request and review workflow from the source material with enough fidelity to feel real, without trying to be a full program tool.
• Administrative and reporting surfaces are present at the level needed to show governance, not to ship a product.
• Source-derived policies (Link 16 naming, MIL-STD-6017 vocabulary, requirement ID schemes) are encoded as queryable rules, not prose.

Success Measures

• A developer can install the BogDB NuGet package, run the example, and execute the included Cypher queries against a seeded tactical messaging graph.
• The example includes named, documented queries that cover at minimum: requirement → component, requirement → test case, policy → affected nodes, and decision/approval history for a requirement.
• At least one realistic policy violation scenario (e.g., a malformed MessageType.name or a non-MIL-STD-6017 VMF term) is detectable via a Cypher query in the example.
• A reviewer reading the example can explain, in their own words, how the graph model supports traceability from requirement to implementation decision.
• Downstream design stages can specify data model, workflow surfaces, and reporting outputs without re-litigating project intent.

Assumptions

• BogDB (available as a NuGet package) is the target graph database, and Cypher-style querying is central to the demonstration.
• The example handles unclassified compliance metadata only; no classified payloads or live operational message traffic.
• Tactical messaging content is represented at the level of requirements, vocabulary, policies, components, tests, and decisions — not message transport.
• Relationships such as TranslatorComponent -SATISFIES-> Requirement and Requirement -VERIFIED_BY-> TestCase are core modeled constructs.
• Requirement IDs follow a synthetic, stable scheme such as REQ-<STANDARD>-<SEQ> (e.g., REQ-L16-001) when source material lacks stable identifiers.

Constraints and Boundaries

• The scope is compliance modeling and traceability querying; not message transport, not an accredited system.
• Source-derived naming and vocabulary rules (Link 16 J<family>.<type>, MIL-STD-6017 public vocabulary for VMF) must be representable as governed, queryable policies.
• Graph relationships must be first-class and queryable, not flattened into document blobs.
• The example must remain understandable to a developer audience: realistic but not maximalist in standards coverage.
• Approval, review, and audit semantics (actor, timestamp, rationale) must be captured in the model so audit-style queries are demonstrable.

Non-Goals

• Live tactical communications, message transport, or any runtime messaging stack.
• Classified data handling or accreditation in this scope.
• Full-fidelity implementation of any military messaging standard.
• A production-grade web product, plugin runtime, or AI-assisted summarization layer.
• Replacing formal systems engineering, test management, or program-of-record governance.

Context Diagram

flowchart LR
    Submitter[Applicant or Submitter]
    Reviewer[Compliance Reviewer]
    Operator[Agency Operator]
    Admin[System Administrator]
    SourceDocs[Source Standards and Policies]
    TM[TacticalMessaging Example App]
    BogDB[(BogDB Graph Store)]
    Queries[Cypher Query Library]

    Submitter --> TM
    Reviewer --> TM
    Operator --> TM
    Admin --> TM
    SourceDocs --> TM
    TM --> BogDB
    Reviewer --> Queries
    Queries --> BogDB

The system boundary is the example application plus its BogDB-backed graph and its documented Cypher query library. External actors supply source standards and review input.

Representative Domain Model Signals

Carried forward from source review and to be honored by downstream data design:

• Requirement nodes carry stable IDs such as REQ-L16-001.
• TranslatorComponent -SATISFIES-> Requirement.
• Requirement -VERIFIED_BY-> TestCase.
• Policy nodes constrain message families, node types, or field names (e.g., Link 16 name format, VMF vocabulary).
• Decision / Review nodes capture actor, timestamp, and rationale.
• Vocabulary and naming rules are modeled as queryable constraints, not prose.

Open Decisions

• Which single workflow anchors the example: change-request intake, requirement compliance review, or translator certification support?
• Delivery shape: console/CLI sample app, minimal web UI, or library plus sample queries — which best serves the BogDB demonstration goal?
• How much of Link 16 and VMF content is embedded as seed data versus left as schema with small illustrative samples?
• What auth and role model, if any, is needed for the example — or is single-user local-only acceptable?
• Which reporting outputs are in scope: a named Cypher query library, a simple dashboard, or both?
• Should policy validation run on write, on demand via queries, or both?
• Is any data import from external requirement or test repositories in scope, or is hand-seeded data sufficient?
• Are there any planned AI-assisted features (mapping, summarization)? If so, what trust and redaction rules apply before they ship?

Notes for Downstream Stages

Downstream design should preserve three distinct layers:

• the graph model (requirements, policies, components, tests, decisions, vocabulary);
• the workflow surface (intake, review, approval) at example fidelity;
• the query and reporting surface (named Cypher queries and any dashboards).

The example will be judged primarily on clarity of the graph model and the expressiveness of its Cypher queries, not on breadth of standards coverage or product polish.