SDLCProfile

Purpose and scopesCopy Anchor Link

An SDLCProfile is the join table of the configuration. Other kinds are referenced by name (stages, playbooks, packs, toolchains, knowledge connections); adapters, autonomy, residency and budgets are inline. A profile can be written at SCOPE_ORG, SCOPE_REPO or SCOPE_COMPONENT. An absent field is unset and comes from a wider scope.

A policy-bearing field has authority only when the profile is loaded from a protected path or a signed policy bundle. Any other copy, even one claiming SCOPE_ORG, is RepositoryAuthored and has no authority.

Field referenceCopy Anchor Link

The envelope (apiVersion, kind, metadata, extensions) is described in Configuration. The loader also requires that playbooks, control_packs, architecture_packs and toolchains have no duplicate element, and that each name and each adapter provider, instance and knowledge name is made of /-joined ASCII segments.

Example: organization baselineCopy Anchor Link

apiVersion: numinance.dev/v1
kind: SDLCProfile
metadata: {name: org-baseline, scope: SCOPE_ORG}
spec:
  stages: trunk-with-cab
  control_packs: [controls/payments/pci-dss/4.0.1]
  autonomy:
    defaults: {level: AUTONOMY_LEVEL_PR}
    rules:
      - {match: {playbook: dependency-upgrade, risk: RISK_CLASS_LOW}, level: AUTONOMY_LEVEL_MERGE}
  residency: {floors: {floor: RESIDENCY_CLASS_IN_ACCOUNT}, regions: [eu-central-1], cross_region: false}
  budgets: {tokens: 400000, wall_clock: 7200s, tool_calls: 300, files_changed: 40}

This is the only place the org picks the stage registry, applies a control pack, sets residency and fixes budgets. Everything below it can only add.

Example: component profileCopy Anchor Link

apiVersion: numinance.dev/v1
kind: SDLCProfile
metadata: {name: payments-api, scope: SCOPE_COMPONENT}
spec:
  playbooks: [dependency-upgrade, bugfix-bounded, runtime-eol-upgrade]
  architecture_packs: [layered-service]
  toolchains: [go-1.27]
  adapters:
    scm: {provider: dev.numinance.official/github, instance: main}
    ciexecutor: {provider: dev.numinance.official/jenkins, instance: ci-prod}
    knowledge: [confluence-eng, jira-pay]

$ numi validate --files schemas/examples/SDLCProfile
revision: "files"
ok       file "org-baseline.yaml" SDLCProfile "org-baseline"
ok       file "payments-api.yaml" SDLCProfile "payments-api"

The component profile sets no stages, control_packs, residency or budgets. They come from the org profile.

Merge and resolution semanticsCopy Anchor Link

A repository that asks for an ungranted playbook, toolchain or adapter name gets it recorded as ignored (outside the org-granted set) and not applied.

Security implicationsCopy Anchor Link

• A repo cannot pick its own gates: stages is org-only.
• A repo cannot drop a compliance pack: control_packs only appends.
• A repo cannot raise budgets or relax residency: both are org-only.
• Adapter bindings only name providers. They do not grant credentials; the credential broker issues material per step.

Common misconfigurationsCopy Anchor Link

$ numi validate --files stages-repo.yaml
revision: "files"
invalid  file "stages-repo.yaml": kind: invalid: numinance.kinds.v1.SDLCProfileSpec.stages is set only at the org scope

An unknown key such as extras is rejected with "/spec/extras": additionalProperties and exit 3.

What validation checks, and what it does notCopy Anchor Link

The open build checks keys, enums, duration form, uniqueness and the org-only rules. It does not check that stages names an existing StageRegistry, that a playbook exists, that a provider is installed, or that the merged result satisfies the floors. Ordinary numi validate on a repository passes the schema and then exits 7: profile resolution needs the Numinance engine build.

Next stepsCopy Anchor Link