Deck / Appendix D
The mechanism

How it works, step by step.

NetOrca is a state machine on top of Git. Service owners publish schemas. Consumers declare intent. Change Instances drive the lifecycle. If nothing changes, nothing happens. Full lifecycle through state, not tickets.

Use when a technical audience wants to see the mechanism before the economics
D.1 — Six steps, end-to-end

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

01
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.

02
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.

03
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."

04
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.

05
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.

06
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.

Request lifecycle

CONSUMER git commit NETORCA validate CHANGE INSTANCE CREATE / MODIFY / DELETE SERVICE OWNER automation RESULT status feedback · same interface
← Back to main deck