Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.conformly.ai/llms.txt

Use this file to discover all available pages before exploring further.

What it is

The Standards Knowledge Graph is Conformly’s curated layer encoding the alignments between ASPICE 3.1, ISO 26262, and ISO 21434. The same engineering practice — say, “verify software units with MC/DC coverage for ASIL D code” — is required by both ASPICE SWE.4 and ISO 26262-6 §9. They use slightly different language and structure, but the underlying work product is identical. Without a knowledge graph, analyzing a document against ASPICE and against ISO 26262 means running the analysis twice. With one, the same evidence satisfies both clauses in a single analysis pass. This is what lets Conformly answer the procurement question:
“How does Conformly handle cross-standard analysis? We need to be assessed against ASPICE 3.1, ISO 26262, and ISO 21434 simultaneously — we don’t want to upload our documents three times.”
The answer is: you don’t have to. The knowledge graph automatically maps your evidence across all three standards.

Where to find it

Sidebar → Library → Knowledge Graph. You see four KPIs at the top (clauses, cross-references, standards covered, most common edge type), a filter row for searching and narrowing by standard, and a list of clauses below. Clicking any clause expands it to show its full set of relationships.

What you can do here

The page is read-only. You can:
  • Browse the full clause set across all three standards
  • Search for specific clause IDs, titles, or descriptions
  • Filter by standard (ASPICE 3.1 / ISO 26262 / ISO 21434)
  • Click into a clause to see its outgoing and incoming relationships
  • Read the justification for each relationship — why this cross-reference exists, with a citation to the source standard or alignment guide
  • See the confidence score of each cross-reference (0–1.0)
You cannot edit cross-references from the UI. The knowledge graph is intentionally version-controlled, not user-editable. Every entry goes through the same code review discipline as a code change.

Why the KG is read-only

The knowledge graph is the product’s defensibility moat. The whole point of having one is that it’s curated to a high standard — every entry is sourced from published industry alignment guides (VDA QMC, ASPICE 4.0 Annex, etc.), every relationship has an explicit justification, every entry has a provenance tag. Letting users add cross-references through a UI would mean:
  • LLM-generated suggestions getting saved without review
  • Customer-specific mappings polluting the global graph
  • No way to roll back a bad addition
  • No way to track who added what and why
Instead, the seed lives in a single YAML file (conformly-core/app/services/kg/seed_clauses.yaml) that’s loaded into the database via a one-shot loader script. To add a new cross-reference, an engineer (or domain expert) opens a pull request against that file. The PR is reviewed, the cross-reference is run against the eval benchmark to verify it improves the F1 score, and only then is it merged and loaded into production.

Provenance tags

Every cross-reference has one of three verification sources:
TagMeaning
industry_standardExplicitly aligned in published standards or alignment guides. Citation in the justification field. Used by the AI pipeline.
domain_expertReviewed by a human automotive compliance professional. Used by the AI pipeline.
ai_proposedLLM-suggested, awaiting human review. Not used by the AI pipeline — visible to admins for review only.
The pipeline injects only industry_standard and domain_expert entries into evaluation prompts. ai_proposed entries are stored for review but never leak into customer-facing analysis. This is enforced in code, not by convention.

How the AI pipeline uses it

When you analyze a document against ASPICE SWE.4, the pipeline:
  1. Looks up SWE.4 in the knowledge graph
  2. Finds the cross-reference to ISO 26262-6 §9
  3. Injects a “Cross-Standard Notes” section into the LLM evaluation prompt
  4. Asks the LLM to (optionally) declare which related clauses the same evidence satisfies
  5. Captures the LLM’s claim in a cross_standard_satisfied field on the result
So when you analyze your unit test plan against ASPICE SWE.4 and the test plan happens to satisfy ISO 26262-6 §9 too, the result tells you both — without you having to upload the document twice or pick both standards manually.

Browsing tip

Click into a clause to see everything connected to it. Both outgoing edges (this clause → other clauses it satisfies / cross-references) and incoming edges (other clauses → this clause). This is the most useful view when you’re trying to understand “what does this clause relate to?” The justification text on each edge is short on purpose — it has to fit a procurement review. If you want the full context, follow the citation in the justification to the original standard or alignment guide.

What’s in the v1 seed

StandardClauses
ASPICE 3.1SYS.2, SYS.3, SWE.1, SWE.2, SWE.3, SWE.4, SUP.10
ISO 26262Part 4 §6, Part 6 §6, §7, §9; Part 8 §8
ISO 21434Clauses 9, 10, 11
That’s 15 clauses and 10 cross-references in v1. The seed grows incrementally as we add benchmark cases — every new cross-reference must improve the eval benchmark F1 score by ≥0.5 points before it ships. Quality over quantity.