Appendix D — How it works

D.1 — Six steps, end-to-end

Two actors. One schema. A state machine in between.

Service Owner$ netorca publish

Defines a service and its schema on the platform.

Allowed inputs, validation rules, required fields, approvers, SLAs. This is the contract consumers will program against.

Platformgit repo provisioned

Consumer gets a Git repo with a standard structure.

One repo per consumer / team. Pre-populated with the service catalogue they're entitled to and working examples.

Consumeryaml commit

Declares what they want — in YAML or JSON.

No implementation detail. No vendor knowledge required. "I need an internal web app exposed on 443 with these backends."

NetOrcaChangeInstance::CREATE

Detects the change, validates against the schema, creates a Change Instance.

Every commit resolves to CREATE, MODIFY, DELETE, or NO-OP. Invalid requests fail in CI with structured feedback — no ticket needed.

Service Ownerautomation picks up

Service Owner's automation picks up the Change Instance and executes.

Ansible, Terraform, an internal API, a vendor tool — whatever the service owner already uses. NetOrca doesn't care.

Consumerstatus · feedback

Sees the result in the same interface.

Success, failure, or structured feedback — in the same repo / UI they submitted from. No hunting across systems.

If nothing changes, nothing happens. Full lifecycle through state, not tickets. NetOrca only reacts to declared intent — the consumer's Git is the source of truth.

D.2 — The three Change Instance states

One primitive. Three verbs.

CREATE

New declaration.

Consumer added a new service block. Automation provisions it.

MODIFY

Declaration changed.

Consumer edited values — new backend, updated port, additional rule. Automation reconciles.

DELETE

Declaration removed.

Consumer removed the block. Automation tears it down — same pipeline, same governance.

How it works, step by step.