How to Use CORE SPICE Approaches — Manually or with LLMs

A practical way to define compliant projects without writing processes

CORE SPICE Approaches replace classical process writing with outcome-driven project definitions. With the CORE SPICE Approaches, teams can quickly kick off engineering activities. They ensure consistent, compliant teamwork while eliminating heavyweight process documentation that nobody reads.

Each CORE SPICE Approach is a short, structured template. It is completed with the project team during the early project phase and serves as a living reference for how the project is actually executed. The goal is clarity, speed, and the avoidance of wasteful, redundant documentation.

The CORE SPICE Approaches are available as templates on the CORE SPICE GitHub repository (LINK). They are free to use under the CORE SPICE Creative Commons license, which allows them to be used for any commercial application.

What problem are we solving?

Most automotive development organizations still rely on classical process documentation. These documents are usually large, slow to update, and expensive to maintain. Worse, they are often disconnected from how engineering teams actually work.

Three problems show up in almost every project:

• Process handbooks are rarely ready during project kickoff. Teams start working without shared rules. When the process finally arrives, it collides with reality and causes friction.
• New hires and suppliers do not study hundreds of pages of process documentation. They learn by imitation and local habits. Long process descriptions quickly become irrelevant.
• Automotive SPICE, functional safety, and cybersecurity requirements are often addressed only through assessment. At that point, process work becomes a bottleneck.

Traditional “process tailoring” does not solve this. It still produces documents that are too abstract, too late, and too remote from the day-to-day engineering decisions.

What are CORE SPICE Approaches?

CORE SPICE Approaches are not process descriptions in the classical sense. They define:

• What outcomes must be achieved
• Who is responsible
• How the project intends to work

They intentionally avoid exhaustive activity lists, redundant standard references, and academic completeness.

An Approach does not try to describe everything. It explains what matters for the project. Each Approach fits on a small number of pages. It is reviewed with the core team. After that, Approaches are updated as needed and can be shown directly to assessors and customers.

In short, an Approach is a strategy and decision aid, not a rulebook.

Two ways to use CORE SPICE Approaches

CORE SPICE Approaches can be used in two ways. Both are valid. The choice depends on timing, team maturity, and constraints.

1. Manually (conventional approach)

2. LLM-accelerated way

In the former case, the approaches are used as inputs and manually elaborated, with each description completed line by line by a dedicated project role.

In the latter case, the CORE SPICE Approaches are used as input to LLMs, quickly generating an expanded document that can be reviewed and discussed with the team immediately.

1. Manually

In the manual approach, a designated role (e.g., Project Lead or Issue Lead—an optional role created for this example only) completes the CORE SPICE template line by line. The draft is reviewed with the core team. Open questions are clarified. Conflicts are resolved. After one or two iterations, the document is approved and becomes part of the project baseline.

This conventional approach makes sense when:

• The team needs deep alignment and discussion
• The customer explicitly demands traditional documentation
• There is enough time before development ramps up

The downside is obvious; even using such a slim CORE SPICE Approach still takes time. In real-world projects, manually creating a complete set of Approaches can take weeks or months.

2. LLM-accelerated creation

The second option uses large language models as drafting accelerators—in this case, ChatGPT 5.1.

The procedure is simple:

• The core team aligns on the key project intent, such as safety level, customer priorities, constraints, or team size.
• The responsible role prepares a structured prompt. Inputs typically include:
  • Project context and goals
  • Architectural scope
  • Applicable standards (ASPICE, ISO 26262, ISO 21434)
  • Organizational constraints
• The LLM generates a complete first draft of the Approach.
• The team reviews, corrects, and adapts the draft.

An important point is that LLM does not make decisions (which can be explicitly ensured by adding specific instructions to the original LLM prompt). It only produces a structured proposal. The responsible project role remains fully accountable for completing the Approach.

Using LLMs reduces drafting time by 70–80%. It allows teams to discuss a concrete document immediately rather than debate abstract ideas.

Example: LLM-driven Issue Management Approach

Let us consider an Issue Management Approach created for a hypothetical Door Lock Control ECU project. The project required:

• Handling defects, change requests, and project tasks
• Full tool support via Atlassian JIRA
• Strong focus on ASIL D and cybersecurity
• Compliance with Automotive SPICE 4.0 without clutter

In addition, a new role was introduced: the Issue Flow Manager, who reports directly to the Project Lead. Using an LLM, the Issue Management Approach template was expanded into a full project-specific document.

The detailed prompt for this approach is provided in the “Appendix” at the end of this article.

The result was a 14-page draft that included scope and objectives, defined roles and responsibilities, and explicit issue lifecycles for defects, change requests, and tasks.

The entire first version was created in one working day, including several rounds of review. Creating the same document manually would typically take several weeks. This does not mean the document was “finished.” In a real project setting, it will still require expert review. But the hard part—structuring and completeness—was already done.

Two additional iterations were needed to fine-tune the level of detail. Workflow visualizations were generated automatically. Because the resulting workflows were purely textual, we used  ChatGPT to generate UML-like state machine graphs using PlantUML (see https://www.plantuml.com). We stored the result in Git (see link in Git)

What about quality, accountability, and trust?

A common objection is that LLMs cannot be trusted to define processes. LLMs can produce incorrect or inconsistent output if not validated and appropriately reviewed. Therefore, every generated draft must be reviewed and owned by the responsible project role. Thus, the resulting approaches must be carefully validated by the project core teams.

• LLMs are not accountable. Project leads are.
• LLMs do not approve documents. Teams do.
• LLMs do not replace expertise. They amplify it.
• Quality comes from review, not from typing speed.

In fact, the LLM-based approach often improves quality because:

• Inconsistencies become visible earlier
• Gaps are easier to spot in a complete draft
• Changes can be applied consistently across documents

The idea that process documents remain unchanged throughout a project is a fiction. Projects evolve. Requirements change. Teams change. Using LLMs enables faster, safer, and more efficient work. That helps avoid the annoying “reworking from scratch,” which often demotivates the team. CORE SPICE Approaches must be easily modifiable, living documents. An Approach is not written once and archived. Only with such “living documents” can approaches serve as references for daily decisions.

This makes CORE SPICE fundamentally different from traditional process frameworks. The goal is not compliance “theater.” The goal is working clarity under real-world constraints.

Conclusion

Modern systems development does not fail because teams lack standards. It fails because the interpretation of standards is too complex, applied too late, and implemented too literally.

CORE SPICE Approaches address this by:

• Defining intent early
• Keeping documentation minimal but sufficient
• Automating everything whenever possible
• Aligning teams around outcomes, not activities

Whether created manually or accelerated with LLMs, CORE SPICE Approaches enable teams to start nearly instantly. In automotive projects, development speed is not a luxury. It is a survival factor. CORE SPICE is not about writing better processes. It is about not needing to “write” processes at all.

---

Appendix

[1] The Issue Management Approach demo draft: https://github.com/CORE-SPICE/DOORLOCK_DEMO/blob/main/Approaches_Demo/Issue%20Management%20Approach.docx

[2] The full prompt:

Context:
In the example project “Door Lock” (see https://github.com/CORE-SPICE/DOORLOCK_DEMO), develop a full draft of the Issue Management Approach.

Use the “Value” sections only as a support narrative and do not include the “Value” chapter in the final result.

Introduce one additional role that is not part of the CORE SPICE Roles Catalog and that reports directly to the Project Lead.

Assumptions

• The issue management system covers defects, change requests, and project tasks.
• Use Atlassian JIRA as the standard issue management tool.
• If applicable, include other tools that support the issue management system.
• Ensure compliance with the project’s goals regarding ASIL D and cybersecurity.
• Ensure full compliance with ASPICE 4.0 in SUP.1, SUP.8, SUP.9, SUP.10, and MAN.3, without cluttering the Approach with explicit ASPICE references—just be compliant.
• Include a lifecycle for each issue type.