Automotive Guardrail Development Manifest - Frequently Asked Questions
This is the Frequently Asked Questions page for the Automotive Guardrail Development Manifest. The main page can be foundhere.
1. Is this just Agile with more documentation?
No. It is a new paradigm. While it borrows useful ideas from Agile, it fundamentally rethinks development through reusable core assets, claim-based architecture, and intelligent guardrails.
2. Why not just use pure Agile?
Pure Agile works extremely well in pure software environments. However, in automotive it quickly reaches its limits due to safety-critical systems, hardware integration, regulatory requirements, and long validation cycles.
3. How does this approach achieve high speed?
By stabilizing the foundation—core assets, supply chain, and safety elements—and allowing fast transactional development on top. This eliminates massive rework cycles that slow down traditional projects.
4. Is this compatible with ASPICE and ISO 26262?
Yes. The approach is explicitly designed to work with — and even enhance — ASPICE and functional safety standards through claim-based development and selective traceability.
5. What are "dedicated, defined claims" and why are they important?
A "dedicated, defined claim" is a specific safety or security guarantee that an out-of-context element implements. These claims allow safety elements to evolve safely and incrementally.
6. How do you handle different validation cadences (e.g., AI models vs. simple logic updates)?
Not all changes can move at the same speed. Principle 7 explicitly supports heterogeneous validation cadences. Most changes can be validated incrementally, while some artifacts require longer cycles.
7. Can we use this with legacy platforms?
Absolutely. Principle 1 explicitly supports incremental migration by encapsulating existing assets behind defined claims — avoiding big-bang rewrites.
8. What does "solutional vs. transactional work" mean?
Solutional items are long-term core assets and reusable IP. Transactional items are project-specific increments. This separation is fundamental to balancing stability and speed.
9. How do you manage safety and security without slowing everything down?
Through out-of-context elements with dedicated claims and continuous, integrated safety practices rather than big-bang end-stage audits.
10. What about supply chain challenges in multi-tier, opaque networks?
We rely on verifiable claims and boundary testing. Each supplied element must demonstrate it fulfills its dedicated claims.
11. How does this enable "China Speed" without sacrificing quality?
Through reusable core assets, claim-based supply chain contracts, and heterogeneous validation cadences that enable parallel development while maintaining high quality and safety.
12. Is this just SAFe for automotive?
No. It is purpose-built for software-defined vehicles with deep focus on claim-based safety, solutional traceability, and supply chain management.
13. What if requirements change after validation has started?
Changes are allowed within protected boundaries through safety-gated, traceable updates that preserve core asset integrity.
14. How do you measure progress?
Primarily by validated short-term releases built on mature core assets.
15. Who is this manifesto for?
It is for automotive engineers, architects, project managers, and leaders working on software-defined vehicles who want to combine speed with safety and long-term platform thinking.
16. How do I get started with Guardrail Development?
The manifesto is licensed under CC BY 4.0. You are free to use and adapt it. For implementation support, feel free to contact us.
17. Is continuous compliance really possible with functional safety standards?
Yes. Continuous compliance integrates safety assessments into the development pipeline, making compliance iterative rather than a big-bang end-stage activity.
18. How do you resolve conflicts between safety and responsiveness?
Safety remains non-negotiable. However, claim-based architecture and protected boundaries significantly reduce the frequency and severity of such conflicts.
19. Does this replace system engineering?
No. It strengthens system engineering by shifting from pure top-down decomposition to claim-based composition and incremental integration.
20. What about open source and third-party software?
They are treated as supply chain elements. Each component must fulfill verifiable claims through boundary testing.
21. How does this work with functional safety standards like ISO 26262 in practice?
It provides a practical framework that makes compliance with ISO 26262 more efficient through claim-based development and continuous practices.
22. What if my organization is not ready for this level of architectural change?
You can start small. Principle 1 supports incremental evolution. Even partial adoption can deliver significant value.