[RFC] Dependency SCP should not be trusted to declare it's importance (classification)

[mattvot]

RFC Metadata

Status: Draft
Author: @mattvot
Created: 2026-02-11
Last Updated: 2026-02-12

---

Abstract

Dependency SCP should not be trusted to declare it's importance classification. Instead it should be derived from how important the services that depend on it declare it to be to their services.

From a system level view, whether or not a "Payment API" is important is not really up to the "Payment API" to declare. Only the systems that require payments should elevate the importance of the "Payment API".

---

Motivation

Problem Statement

Each servcie has to declare its own importance, which seems like an anti-pattern as it should not know about its dependencies.

system:
  urn: "urn:scp:service:component"
  name: "Service"
  classification:
    tier: 1

---

Proposed Solution

Schema Changes

system:
  urn: "urn:scp:service:component"
  name: "Service"

depends:
  - system: "urn:scp:service:component"
    type: "rest"
    criticality: "required"
    failure_mode: "fail-fast"
    classification:
      tier: [1|2|3]

---

Open Questions

Q1: Does this solve the problem or just move it.

Context: Does this actually solve the problem as number of dependents != criticality in the strictest sense as cricitality is more about impact to service as a whole than one part.

Options:

• A) Move classifaction to Depends and use a counter / point system to determin critical (perhaps in conjunction with failure-mode)
• B) Keep as is and accept it is sub optimal but the team responsible for the service should know how it impacts as a whole and thus classify appropiately.
• C) instead of service being 'critical' move to hightlight critcal 'paths' this would hightlight impact..

---

Impact Analysis

Breaking Changes

Will this RFC introduce breaking changes to existing SCP manifests?

• [] Yes, breaking changes (requires major version bump)
• No, fully backward compatible
• Partially backward compatible (specify what breaks)

classification would be moved from the System: to the depends: section.

Migration Path:

If we allow both in a point release and target next major for deprecation of classification in system: this would enable a staged migration.
This could be further mitigated by a temp CLI option to specify which classification should be used for outputs.

Ecosystem Impact

Which projects/tools will be affected?

• scp-definition (schema)
• scp-integrations (CLI tooling)
• scp-viewer (visualization)
• scp-demo (examples)
• Third-party integrations

---

Discussion

This section will be populated during the RFC review process.
Maintainers and community members will add comments, questions, and suggestions here.

---

Decision

To be filled in by maintainers after review.

Status: Accepted | Rejected | Deferred
Date: YYYY-MM-DD
Reason: [Brief explanation of decision]

Action Items:

• Update specification
• Implement in scp-integrations
• Add examples to scp-demo
• Update documentation