Set up a SW System project with the applicable ASIL level, Automotive SPICE capability target, and standards profile.

Creating a SW System project

A project in Assurance-as-Code represents a SW System — the software being developed and assessed. Before you create any artefacts, you define the project’s profile: which standards apply, what ASIL level the system is developed to, what Automotive SPICE capability is targeted, and which relevance flags apply.

What a project profile controls

Profile setting	What it affects
ASIL level	Which artefact types are mandatory, and how validation severity is treated at the release gate
Automotive SPICE target capability	Default expected capability level for in-scope ASPICE processes
ASPICE process scope	The processes in scope and any per-process capability overrides
Cybersecurity relevance	Whether UNECE R155 / TARA-related rules are evaluated
Software-update relevance	Whether UNECE R156 / update-management rules are evaluated
Applicable standards	Which regulation sections the validation rule catalog checks against
Team members and roles	Who can create, edit, review, approve, release, and administer

Supported ASIL levels: QM, A, B, C, D

Supported ASPICE capability levels: CL2, CL3, CL4

Supported standards: ISO_26262, UNECE_R155, UNECE_R156, ISO_29119, ASPICE_PAM_4_0

Creating a project via the web console

Only an Admin can create a project. If no project exists yet, the first administrator is taken directly to the first-project form after sign-in.

Open the web console.
Open Administration.
Enter project name, key, description, ASIL level, and Automotive SPICE target capability.
Set the cybersecurity-relevance and software-update-relevance flags for this SW System.
Under ASPICE process scope and expected capability, select the in-scope processes and set per-process capability overrides where they differ from the project default.
Evaluate the active profile — the tool lists mandatory, conditional, optional, and not-applicable artefact classes for confirmation.
Save.

The project is created with an empty artefact store and the validation rule catalog loaded for your profile.

Creating a project via the API

curl -X POST http://localhost/api/v1/projects \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer <your-token>" \
  -d '{
    "project_id": "OTA_MGR_V2",
    "name": "OTA Update Manager v2",
    "description": "Software update service for gateway ECU — subject to UNECE R156",
    "asil_level": "B",
    "aspice_target_capability": "CL3",
    "cybersecurity_relevant": true,
    "software_update_relevant": true,
    "standards": ["UNECE_R155", "UNECE_R156", "ISO_29119", "ASPICE_PAM_4_0"]
  }'

The response includes the project’s identifier, which you will use in all subsequent API calls for this project.

Understanding project roles

The tool defines four roles. Admin is a global role; the other three are assigned per project.

Role	Scope	What they can do
`admin`	Global	Full configuration; create users; assign roles; configure repository connectors; delete or archive projects; suppress validation issues; obsolete released artefacts
`project_lead`	Project	Update project metadata; add/remove members; approve tailoring decisions; create baselines; approve baselines
`quality_engineer`	Project	Release artefacts; release baselines; trigger release-gate evaluation; update released-artefact revisions
`user`	Project	Create and edit draft artefacts; run imports, validation, traceability, and impact analysis

Roles are not hierarchical. Project Lead and Quality Engineer have distinct, controlled responsibilities. Admin has global administrative privileges and does not require project membership for project-scoped operations.

Assign roles when adding team members:

curl -X POST http://localhost/api/v1/projects/<project-id>/members \
  -H "Authorization: Bearer <your-token>" \
  -d '{"user_id": "user-123", "role": "quality_engineer"}'

See Authorization for the full per-operation authorization matrix.

ASPICE tailoring approval

Changing the Automotive SPICE default capability, process scope, or per-process capability target is a controlled tailoring decision. Before saving such a change, provide:

Rationale — why the process scope or capability level is being adjusted
Evidence references — at least one supporting record (assessment scope record, project tailoring record, process tailoring plan, or management approval)

The saving administrator is recorded as the approver, and audit events are created for both the configuration change and the approved tailoring decision.

Use tailoring decisions when a mandatory artefact class is genuinely not applicable — never as a shortcut around a real compliance gap.

Importing from Sphinx-Needs

If your team already manages requirements in Sphinx-Needs, you can import an existing needs JSON export directly:

curl -X POST http://localhost/api/v1/projects/<project-id>/imports/sphinx \
  -H "Authorization: Bearer <your-token>" \
  -F "file=@needs.json" \
  -F "version_update_mode=automatic_new_version"

Imported items arrive in draft state. The import runs as an asynchronous job; conflicts (matching source IDs already present) can be resolved automatically or paused for user decisions depending on the mode selected.

Next steps

Managing artifacts — create and link requirements, hazard analyses, test cases
Authorization — full role and per-operation authorization matrix
Release baselines — generate a baseline for regulatory submission