NLQ knowledge graph demo

Automotive SDV Change-Impact Data Ingestion Plan

A practical manual-upload strategy for a deterministic NLQ chat app that answers release-impact questions about a safety-critical ECU with evidence from requirements, Jira, Git, test management, variants, releases, and cybersecurity data.

Graph Review Workspace

Upload the same evidence package used by the NLQ flow, then inspect the resulting knowledge graph node by node. Select any node, expand its connected edges, and review the source-backed properties for each discovered neighbor.

TracePilot
Signed in
Enter your email to receive a sign-in link. To get free access, email axel.reichwein@glidesystemsinc.com.
Access list
    Dashboard Workspace overview
    Nodes
    0

    Entities currently loaded in the workspace graph.

    Links
    0

    Explicit and discovered relationships available for review.

    Files
    0

    Uploaded source files connected to graph evidence.

    Active Workspace
    Name Untitled Workspace
    Workspace ID No workspace selected
    Link policy Discovered links included
    Assurance
    0

    Graph warnings reported by ingestion.

    Workspaces Create a workspace or return to the active one.
    Current Workspace
    Name Untitled Workspace
    Workspace ID No workspace selected
    API Base http://127.0.0.1:8080
    Graph Snapshot
    0

    Loaded graph entities for the active workspace.

    New Workspace Add exported engineering files to build a knowledge graph.
    Drag and drop project files or folders here

    Upload Jira exports, requirements, trace matrices, test reports, release manifests, Git records, DOCX, PDFs, logs, Markdown, text files, or folders containing those files.

    User Profile Session and access status
    Account
    Email Local demo user
    Access Authentication disabled
    Session Local session
    Role
    User

    Workspace graph review access.

    No graph loaded.
    0 Nodes
    0 Edges
    0 Visible
    0 Warnings
    Select a node to begin.
    Completeness & Traceability Load a graph snapshot to run automated assurance checks.
    0 Critical
    0 Warnings
    0 Review
    0 Passed
    Baseline / Evidence Configuration Create a graph baseline from the imported artifact versions.
    No saved baselines yet.
    0 Evidence Groups
    0 Version Choices
    0 Scoped Nodes
    0 Scoped Links
    Ingested Data Choose an uploaded file to inspect source content.

    Recommended Demo Framing

    Use a safety-critical brake control ECU because it makes traceability valuable without needing a huge dataset. The buyer immediately understands why a wrong answer is unacceptable: a late braking defect can affect requirements, hazards, variants, release packages, certification evidence, supplier change requests, and retest decisions.

    Demo question: A defect is found after SW-2.4.1-RC2 is built. Which requirements, Jira issues, commits, tests, vehicle variants, release packages, and change requests are affected, and can the release still ship?

    Keep ingestion manual first

    Let a project owner define source slots and upload exported files. Avoid live credentials, OAuth, webhooks, and rate limits in the first prototype.

    Use realistic native exports

    Prefer formats prospects already produce: Jira CSV, ReqIF/CSV/XLSX from requirements tools, GitHub JSON/TSV exports, test XLSX/CSV, release manifests, and SBOM JSON.

    Preserve source evidence

    Every graph node and edge should retain source file, source row/object ID, original field names, extracted value, import timestamp, and optional source URL.

    Minimum Demo Dataset

    Area Suggested demo scope Purpose in the story Seed filenames
    Product and variants 1 brake control ECU, 2 vehicle variants Shows variant-specific impact instead of generic release risk. vehicle_variants.xlsx, ecu_components.csv
    Safety and requirements 3 hazards/safety goals, 10-15 requirements Connects bugs and code to regulated safety evidence. requirements.reqifz or requirements.csv, hazards.csv
    Work management 8-12 Jira items: bugs, tasks, change requests Represents the work queue and release blockers. jira_issues.csv, jira_links.csv
    Source control 2 repos, 10-15 commits or pull requests Proves which code changed and why. commits_brake_repo.jsonl, pull_requests_brake_repo.json, file_changes.csv
    Verification 15 test cases, latest pass/fail executions for 2 releases Answers rerun, failed-release, and evidence questions. test_cases.xlsx, test_results_SW-2.4.1-RC2.csv
    Release and cybersecurity 2 releases, 1 SBOM, optional CVE or security finding Adds package completeness, approval, and UN R155/R156-adjacent relevance. release_manifest_SW-2.4.1-RC2.json, sbom.cdx.json, security_findings.csv

    Entity Sources And Export Formats

    This table maps each graph entity to the system where it is most likely maintained, a realistic manual extraction method, the format the prototype should accept, and the evidence to preserve for deterministic answers.

    Entity type Most likely source app Manual extraction approach Likely export format Prototype upload recommendation Key fields to ingest Important graph relationships
    Project Your app User creates project and source slots before upload. JSON Require a small project_manifest.json to identify demo name, source files, baseline releases, and import date. project_id, name, domain, source_systems[], baseline_ids[] Owns every imported source, snapshot, graph build, and answer evidence set.
    ECU / product component PLM or architecture tool such as PTC Windchill, Siemens Teamcenter, Vector PREEvision, or a controlled Excel component list Export product structure, ECU bill of material, or architecture component table. XLSX CSV Accept ecu_components.csv first; support XLSX import next. Keep component IDs stable and human-reviewable. component_id, name, type, supplier, owner, version, safety_relevance Component implements requirements, is packaged in releases, is used by variants, is changed by commits.
    Vehicle variant PLM, product-line engineering, PREEvision, Windchill, Teamcenter, or a program variant matrix Export variant matrix or product structure list for the two chosen configurations. XLSX CSV Accept a simple variant matrix where rows are variants and columns are included ECUs, calibrations, feature flags, market, and platform. variant_id, model_year, market, platform, included_components[], feature_flags[] Variant includes ECU, includes release package, is affected by bug or change through component and release links.
    Requirement IBM DOORS Next, Jama Connect, PTC Codebeamer, Siemens Polarion, Vector PREEvision Export baseline or filtered module as ReqIF where possible; CSV/XLSX is acceptable for a small demo. ReqIF/ReqIFZ CSV XLSX Support CSV immediately for easy review. Design parser interfaces for ReqIF because it is common in automotive requirements exchange. requirement_id, title, text, type, status, ASIL, baseline, owner Requirement mitigates safety goal, traces to Jira item, is implemented by component/code, is verified by tests.
    Hazard, safety goal, safety requirement Ansys medini analyze, Jama, Codebeamer, Polarion, DOORS Next, or safety team spreadsheet Export HARA and safety concept subset for the selected ECU. XLSX CSV ReqIF Accept hazards.csv and safety_goals.csv; use stable IDs such as HZ-03 and SG-02. hazard_id, operational_scenario, ASIL, safety_goal_id, severity, exposure, controllability Hazard leads to safety goal, safety goal is refined by requirements, failed tests threaten safety evidence.
    Jira bug, task, story Jira Software or Jira Service Management Use filtered issue search and export CSV with all fields. CSV Make Jira CSV the default work-item import. Add optional JSON later for comments, history, and rich links. issue_key, summary, issue_type, status, priority, fix_version, affects_version, labels, linked_issues Bug affects requirement, blocks release, is fixed by PR/commit, is verified by test execution.
    Change request Jira, Codebeamer, Polarion, ServiceNow, or formal change control spreadsheet Export filtered change-control items with status and approval fields. CSV XLSX Represent change requests as first-class graph nodes, even if they arrive in the same Jira CSV as issues. cr_id, title, reason, risk, approval_status, target_release, affected_items[] Change request modifies requirements, creates Jira tasks, causes commits, requires retests, needs approval before release.
    Git repository GitHub, GitHub Enterprise, GitLab, Bitbucket, or internal Git server Upload repository metadata export, or use a small generated JSON file from a scripted Git/GitHub export. JSON CSV Use repositories.json with repo name, URL, default branch, component ownership, and baseline tags. repo_id, name, url, default_branch, component_id, release_tags[] Repo owns commits, PRs, files, and component implementation evidence.
    Commit GitHub/GitLab/Bitbucket or local Git clone Export via REST API, CLI script, or local Git log. Include commit message, author, date, parents, branch, touched files, and issue keys parsed from messages. JSON/JSONL CSV Prefer JSONL because commit metadata contains nested parents and file changes. Allow CSV for the small demo. sha, repo_id, author, date, message, parents[], files[], issue_keys[] Commit fixes Jira item, changes source file, belongs to PR, is included in release delta.
    Pull request / code review GitHub, GitLab, Bitbucket Export from REST/GraphQL API or a simple scripted file for the demo. JSON Use pull_requests.json with approvals and linked commits. This gives strong evidence for reviewed safety-critical changes. pr_id, repo_id, title, status, merged_at, reviewers[], commit_shas[], linked_issue_keys[] PR implements Jira item, contains commits, changes files, may require safety review, is included in release.
    File / software module Git repository, architecture model, or code ownership file Export changed files between baseline and release candidate using compare/diff output. CSV JSON Accept file_changes.csv with one row per file per commit or PR. This is easy to inspect during a sales demo. path, repo_id, component_id, change_type, sha, lines_added, lines_deleted File belongs to component, changed by commit, traces to requirement through ownership map or explicit code annotations.
    Test case Xray, Zephyr Scale, qTest, Polarion, Codebeamer, TestRail, or ECU test bench spreadsheet Export test library or filtered test set from the test management tool. XLSX CSV Accept both XLSX and CSV. Normalize test steps only if needed; the first demo needs test ID, title, level, method, requirement links. test_id, title, test_level, method, status, requirement_ids[], owner Test verifies requirement, covers safety goal, is executed in release, must rerun after file/component change.
    Test execution / result Xray, Zephyr, qTest, CI system, HIL/SIL test bench result export Export execution report for the release candidate and previous approved baseline. CSV XLSX JSON Use one compact test_results_*.csv per release. Include exact result evidence and run timestamp. run_id, test_id, release_id, result, executed_at, environment, defect_keys[], evidence_uri Execution validates release, fails against requirement, creates defect, blocks release gate.
    Release version / software baseline Jira fix versions, GitHub releases/tags, CI/CD, Artifactory, release management spreadsheet Export release list, baseline tags, and release candidate metadata. JSON CSV Use releases.csv plus release_manifest_*.json. Keep the previous approved baseline and current release candidate explicit. release_id, version, status, baseline_tag, build_id, release_date, approvals[] Release includes artifacts, commits, fixed issues, test executions, variants, and approval decisions.
    Release package / build artifact JFrog Artifactory, Nexus, GitHub Releases, GitLab Packages, CI/CD build output Export build-info JSON or release manifest with artifact names, checksums, component versions, and source commit SHAs. JSON Use release_manifest_SW-2.4.1-RC2.json. It should be the anchor for “what exactly shipped?” questions. artifact_id, build_id, version, checksum, repo_id, commit_sha, component_id Artifact built from commits, packages component, belongs to release, is deployed to vehicle variants.
    Trace links Requirements ALM tool, Jira links, test management, manually curated mapping sheet Export link tables if source tools preserve typed relationships; otherwise upload a reviewer-friendly mapping CSV. CSV ReqIF JSON Use a canonical trace_links.csv in the demo. It makes the evidence graph easy to inspect and keeps the scope limited. source_id, source_type, relation_type, target_id, target_type, source_system, confidence Creates explicit edges such as verifies, implements, blocks, affects, fixes, included_in, supersedes.
    SBOM component Build pipeline, SCA tool, Artifactory Xray, Black Duck, Snyk, GitHub dependency graph, CycloneDX/SPDX generator Export SBOM for the release package. CycloneDX JSON SPDX JSON XML Accept CycloneDX JSON first because it is compact, widely generated, and easy to validate. Add SPDX JSON as a second supported option. bom_ref, component_name, version, purl, license, hashes[], dependency_edges[] SBOM component is included in release artifact, may be affected by CVE, may trigger cybersecurity change request.
    Cybersecurity finding / CVE SCA scanner, vulnerability management tool, Jira security issue, supplier bulletin Export findings list for the release SBOM. CSV JSON Use a tiny optional security_findings.csv with one relevant CVE or supplier advisory to show cybersecurity traceability without expanding the demo. finding_id, cve_id, severity, affected_component, status, remediation, linked_issue_key Finding affects SBOM component, creates Jira issue, blocks release, requires change request or risk acceptance.
    Release approval / gate decision Jira workflow, Confluence page, Polarion/Codebeamer approval workflow, electronic signature system, release checklist spreadsheet Export release gate checklist and approvals for the baseline and release candidate. CSV XLSX JSON Accept a release gate CSV with one row per gate condition. Deterministic “can it ship?” answers should be rule-based against this table. gate_id, release_id, condition, status, approver, approved_at, blocking_reason Gate decision checks open blockers, failed tests, unapproved changes, security findings, and missing evidence.

    Prototype Source Slots

    For the first version, make the project setup explicit and boring in the best way: each slot describes a source, allowed file types, parser, and canonical entity types. This is enough to feel enterprise-real while staying easy for prospects to trial.

    Project source slot Accepted files Parser behavior Validation rules Best demo answer enabled
    Requirements baseline .csv, .xlsx, .reqif, .reqifz Parse requirements, hazards, safety goals, and existing requirement-to-requirement links. Require stable IDs, status, text/title, and baseline ID. “Which requirements trace to this failed release candidate?”
    Jira work items .csv Normalize Jira issue keys, issue types, fix versions, affects versions, labels, and linked issue columns. Require Issue key, Summary, Issue Type, Status. “Which open Jira issues block release SW-2.4.1?”
    Source control .json, .jsonl, .csv, .diff Parse repos, commits, PRs, changed files, release tags, and issue keys from branch names, PR titles, and commit messages. Require repo ID and commit SHA for every code-change record. “Show the evidence linking this code change to the safety requirement.”
    Test management .csv, .xlsx, .json Parse test cases separately from executions so one test can have results across multiple releases. Require test ID, release ID for executions, result, and timestamp. “If we accept this change request, which tests must be rerun?”
    Variant and component data .csv, .xlsx Parse variant matrix, ECU/components, included packages, feature flags, and market applicability. Require variant ID, component ID, and included/excluded indicator. “Which vehicle variants are affected by BUG-217?”
    Release package .json, .csv Parse releases, artifacts, build IDs, checksums, included commits, and gate decisions. Require release ID, artifact ID, version, and checksum or build ID. “What changed since the last approved safety baseline?”
    Cybersecurity and SBOM .json, .xml, .csv Parse CycloneDX/SPDX components and optional vulnerability findings. Require release ID, component name/version, and finding ID for findings. “Does this release contain a known security blocker?”

    Canonical Graph Model

    Node labels

    • Project, DataSource, ImportSnapshot
    • ECU, Component, VehicleVariant, FeatureFlag
    • Hazard, SafetyGoal, Requirement
    • JiraIssue, ChangeRequest, PullRequest, Commit, File
    • TestCase, TestExecution, Release, Artifact, GateDecision
    • SBOMComponent, SecurityFinding

    Edge labels

    • MITIGATES, REFINES, VERIFIES, IMPLEMENTS
    • AFFECTS, FIXES, BLOCKS, REQUIRES_RERUN_OF
    • CHANGES, CONTAINS_COMMIT, CONTAINS_ARTIFACT, BUILT_FROM
    • INCLUDED_IN_VARIANT, PACKAGED_IN_RELEASE, DEPENDS_ON
    • HAS_EVIDENCE, DERIVED_FROM_SOURCE_ROW, SUPERSEDES

    Determinism guardrail: imported graph edges must be explicit, rule-derived, or visibly marked as inferred. The chat app should not invent traceability. If a link is absent, the answer should say the evidence is missing and show the nearest available source records.

    Deterministic Answer Strategy

    Question Deterministic query path Evidence to display Fail-closed behavior
    Which vehicle variants are affected by BUG-217? JiraIssue -FIXED_BY/CHANGED_BY-> Commit/PR -CHANGES-> File -BELONGS_TO-> Component -INCLUDED_IN_VARIANT-> VehicleVariant Bug row, PR/commit, changed file rows, component map, variant matrix rows. If file-to-component mapping is absent, answer with changed files and state that variant impact cannot be proven.
    Which requirements and tests trace to this failed release candidate? Release -HAS_EXECUTION-> Failed TestExecution -OF_TEST-> TestCase -VERIFIES-> Requirement Release manifest, failed test execution rows, test case export, requirement baseline row. If tests lack requirement links, show failed tests and flag missing verification traceability.
    What changed since the last approved safety baseline? Compare release baseline tags and list commits, PRs, files, issues, requirements, and test deltas between releases. Release manifests for both versions, Git compare export, Jira fix-version rows, changed requirement baseline rows. If no previous baseline is selected, require the user to choose one before answering.
    Which open Jira issues block release SW-2.4.1? Filter JiraIssue where target/fix version is release and status is not closed, then apply gate rules for blockers. Jira CSV rows, release gate checklist rows, status and priority fields. If blocker policy is missing, list open issues and state that release-blocking status cannot be determined.
    Show the evidence linking this code change to the safety requirement. Commit/PR -FIXES-> JiraIssue -AFFECTS/IMPLEMENTS-> Requirement -REFINES-> SafetyGoal Commit message, PR review, Jira linked issue, requirement row, trace-link row. If the link is inferred only from text, label it inferred and separate it from explicit evidence.
    If we accept this change request, which tests must be rerun? ChangeRequest -AFFECTS-> Requirement/Component/File -VERIFIED_BY/COVERED_BY-> TestCase plus impacted variant/release scope. Change request row, impacted requirements/components, test coverage rows, latest execution status. If coverage is incomplete, list known tests and show uncovered requirements/components as residual risk.

    Recommended Upload Package

    For the sales demo, ship a reviewer-friendly sample package. Prospects can inspect every file in a spreadsheet or text editor, then see the app produce the same impact analysis with links and evidence.

    Filename Format Content Why this file matters
    project_manifest.json JSON Project metadata, source file inventory, release IDs, baseline IDs. Makes imports reproducible and versioned.
    requirements.csv CSV 10-15 requirements with ASIL, status, baseline, owner, source URL. Easy for prospects to review; can later be replaced by ReqIF.
    hazards.csv CSV 3 hazards/safety goals and safety classifications. Gives safety-critical context without a full HARA model.
    trace_links.csv CSV Explicit typed links among safety goals, requirements, Jira issues, tests, components, and releases. Keeps the demo deterministic and auditable.
    jira_issues.csv CSV 8-12 work items exported from Jira-like fields. Matches a familiar manual export path for most prospects.
    repositories.json JSON Two repos mapped to brake ECU software components. Provides context for commit and PR imports.
    commits.jsonl JSONL 10-15 commits with changed files and parsed issue keys. JSONL handles nested file changes better than CSV.
    pull_requests.json JSON PR titles, merge status, reviewers, commits, linked Jira issue keys. Creates credible review evidence for safety-critical software changes.
    test_cases.xlsx XLSX 15 test cases with verification links and test level. Reflects common test management exports while staying readable.
    test_results_SW-2.4.0.csv, test_results_SW-2.4.1-RC2.csv CSV Pass/fail executions for previous baseline and release candidate. Enables exact “what regressed?” answers.
    vehicle_variants.xlsx XLSX Two vehicle variants, markets, included ECUs, software package applicability. Turns defect impact into a business and release-scope answer.
    release_manifest_SW-2.4.1-RC2.json JSON Artifacts, checksums, build ID, commit SHAs, included components. Anchors release evidence and “can it ship?” logic.
    release_gates.csv CSV Gate rules and current decision state. Allows deterministic release recommendation instead of an LLM judgment.
    sbom.cdx.json CycloneDX JSON Small SBOM for the brake ECU release package. Adds cybersecurity and supply-chain credibility.
    security_findings.csv CSV Optional single CVE or supplier cybersecurity finding. Shows cybersecurity traceability without growing the demo too much.

    Implementation Notes For The App

    Importer UX

    Use a project setup page with source slots, drag-and-drop upload, schema detection, field mapping preview, validation warnings, and a “build graph snapshot” button.

    Graph snapshots

    Every upload should create an immutable import snapshot. The app should answer against a selected snapshot so answers remain reproducible.

    Evidence-first answers

    The chat UI should show the answer, a source-backed path, and clickable evidence rows. Avoid free-form claims that are not grounded in nodes and edges.

    Field mapping

    Support default templates for Jira, GitHub, Xray, Zephyr, qTest, DOORS/Jama-style requirements CSV, and generic trace-link CSV.

    Deduplication

    Use source-system-qualified IDs: jira:BUG-217, git:brake-ecu:abc123, req:BCU-SR-014. Never merge purely by title.

    Accuracy claim

    Position “100% accurate” as “100% deterministic over imported evidence.” The app can be exact about known data and explicit about missing data.

    Source References

    The format choices above are grounded in common vendor-supported exchange paths. These links are useful footnotes for prospects who ask whether the import approach matches real-world tooling.