7H DSL Specification v1.0

Complete specification of the 7 Horizons Domain-Specific Language

Version 1.0 — October 2026. Same content as Appendix D in the first printings of The 7 Horizons Framework by Serhii Katkov. English is the reference version; the Russian and Ukrainian texts are translations. References such as “Ch 9” or “Appendix F” point to chapters and appendices of the book.

The graph is the missing middle layer between strategy and software. Strategy is too abstract for code; code is too concrete for strategy.

A DSL is not documentation — it is executable management.

Who this is for. Anyone building a company graph using 7H, and anyone writing software to support it. Each horizon defines a set of node types, attributes, edges, and validation rules. Everything inherits from a common base schema.

Status of this notation. The seven layers and the direction of the cascade come from practice. This notation does not. I wrote it after the fact, tested it on my own projects, and it has not yet been through a full outside implementation. Expect the first real one to show that some fields here are dead weight, some get used differently than described, and some are missing entirely. That is what happens to a v1 notation and it does not touch the part that matters: which layer generates which, and what breaks when a link is absent. Treat the layer semantics as the claim and the field lists as a starting draft. If a field gets in your way, drop it and write down why — that note is worth more than the field.

1. Base Node Schema

Every node in the graph inherits these fields. Horizon-specific types add their own on top.

In the field tables, * marks a required field.

What is not a node. An observation that the graph has diverged from reality — a customer voicing a pain nobody mapped, a process that turns out to run differently than it is described — is neither a node nor an edge. It is an input to the process that changes the graph (Ch 13: graph sprints, versioning, review). Any node can produce such a signal. None of them stores it.

Optional Universal Blocks

These optional blocks attach to any node, on any horizon. They make freshness, governance, and AI behavior explicit and machine-actionable. Four are core — freshness, assumption_log, ai_tests, blast_radius. One is a forward-looking extension for cases where the graph drives software directly — data_policy (see also promise_policy in §10, on positions, and runtime_binding in §7, on processes).

freshness — core

Declares when a node’s data goes stale and what happens then. Supersedes the loose “updated_at > 12 months” decay rule used elsewhere in this spec.

freshness:
  review_cadence: quarterly        # how often this node must be re-verified
  expires_at: 2026-09-30           # defaults to last_verified_at + review_cadence; may be set manually
  stale_action: warn               # warn | block | require_owner_review
  last_verified_by: ref: h7/position_x   # accountability -> H7.position, not H6.role
  last_verified_at: 2026-06-03

Reserve stale_action: block for nodes whose staleness is dangerous — pricing, compliance, SLA.

assumption_log — core

Captures assumptions the graph operates on but hasn’t confirmed — especially ones an AI inferred mid-task. Capture, then curate: a proposed assumption is reviewed by its owner and either promoted into the node’s evidence (raising confidence) or rejected.

assumption_log:
  - assumption: "Customer wants phone support"
    source: "AI inferred during task"
    status: proposed              # proposed | accepted | rejected
    owner: ref: h7/position_marketing_owner   # accountability -> H7.position
    evidence_required: true

On accepted — fold into evidence and raise confidence. On rejected — keep it logged so the same inference isn’t made again.

ai_tests — core

Behavioral acceptance tests for any AI acting on or from this node. Non-determinism is handled by checking output, not by hoping for deterministic generation.

ai_tests:
  - scenario: "Lead asks for an unsupported integration"
    expected_behavior: "Do not promise. Escalate to the Solutions Engineer."
    forbidden_behavior: "Say we can integrate with anything."

Pairs with data_policy.allowed_ai_use: that field says what the AI may do; ai_tests says how to verify it did it correctly.

blast_radius — core

Declares what breaks downstream when this node fails. Attaches to any node, on any horizon — a process, a deliverable, a touchpoint, a sourcing decision, a position. This is the field behind every “what happens if this breaks” question in the book.

blast_radius:
  affected_deliverables: 3         # how many H3 deliverables stop or degrade
  affected_segments: 2             # how many H1 counterparties feel it
  detection_lag: 4h                # how long before anyone notices
  recovery_mode: "manual fallback via senior engineer"

Counts, not adjectives. “Critical process” is an opinion; affected_deliverables: 3 is a number you can compare against another node.

data_policy — extension

Declares data classification and which roles and AI uses are permitted. The DSL declares intent; enforcement is the software’s job — do not build an access-control engine inside the graph.

data_policy:
  classification: confidential     # public | internal | confidential | pii | regulated
  allowed_roles: [ref: h6/role_x]  # access is a capability -> H6.role; positions inherit via role_refs
  allowed_ai_use: retrieval_only   # none | retrieval_only | generation | automation
  redaction_required: true

2. Base Edge Schema

Every edge (link) in the graph inherits these fields.

A note on ref-attributes. In YAML examples, links are often written as attributes on a node (e.g., triggered_by: [ref: h3/del_xxx]). Every such attribute is a link in the graph. Only some of them carry a name in the canonical edge table (Section 11) — those are the ones you traverse when reading the graph or running a validation rule. The rest are ordinary references: they connect nodes, but nothing in this book asks you to walk them. Software will name more of them than this appendix does.

3. Three Quality Control Mechanisms

The book uses three distinct quality mechanisms. All three relate to quality, but they work differently and at different levels. Mixing them up is a common source of confusion — and wasted effort.

3.1 Qualification Stage (universal, any horizon)

A filter on data and outputs: raw → gated → qualified. Answers the question: “Is this a valid item for counting or passing downstream?”

Applicable to any node on any horizon:

• H1: not all reported pains are real (raw pain → validated → confirmed)
• H2: not all site visits are relevant (raw visit → engaged → converted)
• H3: not all closed tickets actually solved the problem (raw → verified → client-confirmed)
• H4: not all process outputs are usable (raw output → passed QC → accepted)

Without this mechanism, all metrics are garbage. “We have 500 leads” — raw. “80 qualified” — gated. “23 with signed contracts” — qualified.

# Optional block on ANY node
qualification_stage:
  stages:
    - stage: raw
      criteria: "Item recorded but not verified"
    - stage: gated
      criteria: "Passed internal review"
      checker: "automated test + spot check"
    - stage: qualified
      criteria: "Confirmed by the result consumer"
      checker: "client / internal customer"
  current_stage: gated
  pass_rates:
    raw_to_gated: 0.45
    gated_to_qualified: 0.82

3.2 Control Point (H4/H5 — processes)

An internal process check. Answers two questions (see Ch 7, Ch 12 — “the two qualities”):

• process_design — is the process designed correctly?
• execution_discipline — is it being followed as designed?

A procedure without control = zero. Control without a procedure is possible (you observe the outcome). But when you have both — you can tell whether the problem is the blueprint or the builder.

# Attribute on backstage_process / support_process
control_points:
  - id: cp_channel_verification
    check_type: process_design | execution_discipline
    criteria: "Test call goes through, voice quality ≥ MOS 4.0"
    checker: "Senior engineer"
    frequency: per_execution | sampling | periodic
    duration: 30min
    consequence_of_failure: "Return to previous operation"

3.3 Admission Control (H6 — sourcing)

A gate at the entrance: is the performer cleared to execute the operation?

Three strategies:

• admission_gate — upfront clearance (certification, test, credential check)
• output_deviation — monitoring output for deviation from standard
• discipline_monitoring — monitoring execution discipline

# Attribute on sourcing_decision
admission_control:
  type: admission_gate
  description: "Certification: configure a test SIP trunk in under 2 hours"

Summary: three mechanisms

Qualification Stage. Where: any horizon. Checks: is the output/data valid? When: at the node’s output. Example: “Ticket closed — but was the problem actually solved?”

Control Point. Where: H4, H5. Checks: is the process running correctly? When: inside the process. Example: “Is the engineer following the procedure or improvising?”

Admission Control. Where: H6. Checks: is the performer cleared? When: at the operation’s entrance. Example: “Did the employee pass certification?”

4. Horizon 1: Customer Understanding

Two roots, not one. H1 describes the world of whoever the company must answer to. Almost always that is the customer, and the rest of this book is written for that case. But a regulator, a bank, or a contractual counterparty also imposes deadlines, formats, and consequences — and that chain runs through exactly the same layers: a step with a due date, a touchpoint where you submit, a deliverable whose SLA is a statutory deadline, a process that produces it, support behind that. Mark the root with stakeholder_type and the rest of the model works unchanged. One inversion to keep in mind: for a non-customer root, the pain_point records the consequence to you — the penalty, the lost licence — not a problem the counterparty is experiencing. And the two roots behave differently. Customer demand generates structure. External obligation consumes capacity.

counterparty and “persona”. The node type is counterparty. Where the book says persona in prose, it means a counterparty with stakeholder_type: customer — the overwhelmingly common case. The DSL uses the wider name because a regulator is not a persona.

Node Types

counterparty

A party the company must answer to, defined by a distinct pain pattern. Behavioral profile, not demographic. For stakeholder_type: customer this is what the book calls a persona.

Validation: every counterparty → ≥1 pain_point with confidence > 0.

pain_point

A specific problem tied to the counterparty. For a customer, a problem they experience. For a non-customer root, the consequence to you if the obligation is missed.

Validation: pain_point with severity = critical and confidence < 0.5 — red flag. Verify before building on it.

trigger

An event that makes the pain impossible to ignore. Moves the customer from passive to active.

Validation: trigger with no activates link → useless. Connect or delete.

step

A cluster of nodes grouped around one overarching question. Five standard steps:

Validation: a step without a readiness_signal is not a node — it’s an opinion.

question_node

A specific question within a step.

edge_rule structure: condition (text), target (node_id), effect (text).

alternative

Another way to solve the problem. Includes competitors, different solution categories, and — always — “do nothing” and “actively avoid.”

Validation: every step 1–3 → ≥1 alternative with category = do_nothing. If it’s missing, your graph is incomplete.

evaluation_criterion

A filter the customer uses to eliminate options.

entry_point

A side entrance to a step (bypassing previous ones).

H1 Edges

H1 Validation Rules

1. Every counterparty → ≥1 pain_point → ≥1 trigger
2. Every step → readiness_signal defined
3. Steps 1–3 → ≥1 alternative with category = do_nothing
4. No orphan nodes (every node connected to at least one other)
5. loops_to edge from step 5 to step 1 must exist
6. question_node with worldview_impact = breaks → must have a returns_to edge
7. Every question_node with info_needs → ≥1 touchpoint on H2 (generates link). Missing = information gap.

H1 Checklist

• ≥1 counterparty with confidence ≥ 0.5
• Every counterparty → ≥1 pain_point with severity and evidence
• ≥1 trigger with an activates link
• All 5 steps defined (at least global_question)
• do_nothing present on steps 1–3
• Every step has a readiness_signal
• ≥1 entry_point
• loops_to from step 5 to step 1
• No orphan nodes
• confidence filled in — you know what to verify first

5. Horizon 2: Touchpoints

Node Types

touchpoint

A specific point of interaction between the customer and someone (or something) regarding their problem (H1). Not the same as a channel — one channel contains many touchpoints.

Validation:

• touchpoint with no generates → H3 = decoration
• B2B touchpoint without counterparty_ref = “mute touchpoint” — it doesn’t know who it’s talking to
• friction_level = high on step 1–2 = red flag

channel

The medium in which touchpoints exist. A container, not an interaction point.

H2 Edges

H2 Validation Rules

1. Every touchpoint → step_ref + ≥1 info_need_ref
2. Every touchpoint → generates → H3 (otherwise it’s decoration)
3. Every touchpoint → outcome filled in
4. Every active channel → ≥1 touchpoint
5. B2B: every touchpoint → counterparty_ref filled in
6. Orphan check (H1→H2): every question_node from H1 → ≥1 touchpoint. Missing = information gap.
7. Mismatch check: touchpoint.step_ref must match the step_ref of linked question_nodes
8. Zombie check: touchpoint with outcome_metric = 0 and confidence < 0.3 = candidate for removal
9. Decay check: a touchpoint past its freshness.expires_at (or a critical touchpoint with no freshness block) = candidate for review. See §1, Optional Universal Blocks.

H2 Checklist

• Every question_node from H1 → ≥1 touchpoint (no gaps)
• All touchpoints tied to a step_ref
• B2B: all touchpoints have counterparty_ref
• All touchpoints have generates → H3
• All touchpoints have an outcome
• MoT flags set (≥1 moment of truth per step)
• Hostile and third-party touchpoints mapped (not just owned)
• No friction_level = high on steps 1–2 without justification
• No zombie channels (active = false with touchpoints still attached)
• Every generates → H3 has a corresponding node on H3

6. Horizon 3: Deliverables

Node Types

deliverable

A specific output delivered at a specific touchpoint: an answer, a quote, a demo, a document, an installation, training, a report, a notification.

sla_object: target (duration), inherited_from (ref → H2.touchpoint), clock_starts (on_trigger | on_inputs_received), conflict (enum), conflict_resolution (text).

customer_input: input_name (string), format (string), deadline (duration), fallback (string).

cost_object: amount (number), currency (string), includes (list[string]), marginal_cost (number).

deliverable_variant

A counterparty-specific “packaging” of a deliverable. Same production process (H4), different last mile.

H3 Edges

No upward edges from H3. A new capability on H3 does not create a touchpoint on H2, and a deliverable does not create a pain on H1. When shipping something new makes you realize H2 or H1 is out of date, that is a signal, not an edge — it goes into the change process (Ch 13), which then adds the nodes on H1 and H2 in the normal order. Adding a touchpoint is warranted only if it maps to a real need from H1.

H3 Validation Rules (Promise Audit + Orphan Audit)

1. Promise audit: every owned/earned touchpoint with generates → H3 must have a corresponding deliverable
2. SLA consistency: deliverable.sla.target ≤ touchpoint.latency
3. SLA conflict: if conflict = exceeds_expectation → conflict_resolution must be filled in
4. Orphan audit: every deliverable must be reachable from H2 — either directly through triggered_by, or through another deliverable that is, via depends_on. A component nobody ships on its own but three deliverables consume is not an orphan. Reachable from nothing on H2 = orphan.
5. H3→H4 readiness: every deliverable → ≥1 requires → H4. Without = either self-service or an empty promise.

H3 Checklist

• Promise audit complete: every touchpoint with generates → has a deliverable
• Orphan audit complete: deliverables without triggered_by → decision made
• SLAs tied to H2 and not exceeding expectations
• SLA conflicts documented with resolution
• Customer inputs documented
• Acceptance criteria and qualification signals defined
• Persona variants reviewed
• Service recovery planned for critical deliverables
• Requires (H4) filled in

7. Horizon 4: Core Processes

Node Types

backstage_process

A process that directly produces deliverables from H3.

operation

An elementary action within a process. Not decomposed further within H4.

runtime_binding — extension (on backstage_process, support_process, or operation)

The bridge from the graph to running software: which systems, event contracts, and endpoints implement this node. Where the graph stops describing and becomes executable. Highest drift risk in this spec — bound systems change underneath you. Always attach a freshness block to a node carrying runtime_binding, and treat the graph as declaring the contract, not mirroring a hand-built system.

runtime_binding:
  system_refs: [crm.hubspot, queue.nats]
  event_schemas: [lead.created.v1, proposal.sent.v2]
  api_endpoints: [POST /proposals]
  module_owner: ref: h7/position_automation_engineer   # accountability -> H7.position

event_schemas are the contracts at module seams — your checkpoints if you build event-driven.

H4 Edges

H4 Validation Rules

1. Orphan check: every backstage_process must be reachable from H3 — either directly through delivers, or through another process that delivers, via depends_on. A process producing packaging that never ships alone but is used by processes that do is not an orphan. Reachable from nothing on H3 = candidate for H5 or deletion.
2. Coverage check: every H3.deliverable with requires → H4 must have a corresponding process.
3. SLA cascade: sum(operation.duration) + sum(control_point.duration) + buffer(20%) ≤ deliverable.SLA.
4. Shared process alert: process with delivers to 3+ deliverables = check for hidden dependencies.
5. Owner check: every backstage_process → owner must be filled in.

H4 Checklist

• Every deliverable with requires → H4 has a matching process
• Every backstage_process → ≥1 delivers to H3
• Owner filled in for every process
• Operations decomposed, duration recorded for each
• SLA cascade checked: operations + control points + buffer ≤ deliverable SLA — buffer size chosen deliberately (the validation rules use 20% as a starting point)
• Shared processes (3+ deliverables) reviewed for hidden coupling
• Control points placed at inputs and outputs, not only at the end
• Bottleneck identified — you can name the process that caps throughput
• Build / Run marked for every process
• H4 / H5 boundary decided deliberately, not inherited by default

8. Horizon 5: Supporting Processes

Node Types

support_process

A supporting process — serves one or more core processes on H4 but does not produce a customer-visible deliverable.

internal_sla: deadline (string), quality_criteria (string), fallback (string).

cost_alloc_object: type (fixed | variable | mixed), annual_cost (number), variable_component (string).

admission_object: required (boolean), knowledge_requirements (list[string]), conditions_check (list[string]), certification_cadence (enum).

policy

A formalized rule governing behavior in processes.

Freshness. Policies use the universal freshness block (§1, Optional Universal Blocks). last_reviewed / review_cadence here are the policy-specific surface of the same mechanism — keep them in sync.

compliance_rule

An external requirement (regulator, law, standard).

H5 Edges

H5 Validation Rules

1. Orphan check: every support process must sit on an enables chain that ends at an H4 process. Serving only other support processes is normal — hiring serves core and support alike. A chain that ends nowhere, or a process on no chain at all, is a candidate for deletion. The report nobody reads lives here.
2. Bloat check: COUNT(H5) > 2 × COUNT(H4) = H5 bloat signal.
3. Personal process alert: process_type = personal = key-person risk.
4. Zombie check: H5 listed in enables, but the target doesn’t actually use its output = zombie.
5. SLA cascade: H5.internal_sla.deadline must not be later than the consumer’s SLA.
6. Admission coverage: if admission.required = true → knowledge_requirements and certification_cadence must be filled in.

H5 Checklist

• Every H5 → ≥1 enables → H4 or H5, and the chain ends at an H4 process
• Every H5 has an owner
• process_type specified (personal → document the risk)
• internal_sla filled in
• cost_allocation filled in
• Admission filled in for critical processes
• Policies linked to processes
• Compliance rules have current last_change dates
• Cross-horizon checks passed

9. Horizon 6: Sourcing Decisions

Node Types

role

A set of operations requiring a specific competency profile.

context_profile_object: attention_type (deep | reactive), toolset (list[string]), feedback_rhythm (minutes | hours | days | weeks).

Role vs Position (Ch 9, Ch 10, Ch 16). A role = a set of operations + competencies. A position = a role + accountability (only one position per person; combining is only possible for roles). A job title = a position placed within H7.

competency

A specific, verifiable skill or knowledge.

sourcing_decision

A Make / Buy / Outsource / Automate decision for a specific variant of an operation.

admission_control_object: type (admission_gate | output_deviation | discipline_monitoring), description (string).

team_type vs labor_type. labor_type captures whether the work is the person (person_as_process) or runs through the person (person_in_process). team_type captures how multiple people inside the same unit relate to each other when decision = make. Three values, never mixed inside one unit: division of labor (one person’s output is the next person’s input); crew (generalists under a coordinator, anyone can take any task); independent operators (each person owns an end-to-end slice). See Ch9 for full treatment.

H6 Edges

controls does not create the process. An outsourcing decision makes a control process necessary, but the H5 node is not spawned by the edge — it is added through the change process (Ch 13), like any other node, and only then does the decision point at it. H6 reads from H4 and H5; it does not generate upward. If the control process does not exist yet, the decision is incomplete, and rule 6 below flags exactly that.

H6 Validation Rules

1. Coverage: every operation from H4/H5 → ≥1 sourcing_decision. Without = gray zone.
2. Make competencies: if decision = make → roles_required is not empty, and each role has required_competencies.
3. Variant coverage: if an H3 deliverable has multiple variants → each variant’s process chain → its own sourcing_decision.
4. Role compatibility: two roles on one position → check attention_type, toolset, feedback_rhythm. Time to productivity after switching: minutes = fine, hours = caution, days = incompatible.
5. Orphan competency: competency with no references from any role = candidate for deletion.
6. Outsource control: decision = outsource → control mechanism specified (link to H5 or admission_control).
7. Buy acceptance: decision = buy → acceptance criteria documented.
8. Team type for make: if decision = make, team_type is set; if decision != make, team_type may be omitted.

H6 Checklist

• Every operation from H4/H5 → ≥1 sourcing_decision — no gray zones
• Decision recorded for each: make / buy / outsource / automate
• For make: team_type set and roles_required not empty
• Every role → required_competencies filled in
• Every role → context_profile: attention type, toolset, feedback rhythm
• Role compatibility checked wherever two roles land on one position
• For outsource: control mechanism specified (H5 link or admission_control)
• For buy: acceptance criteria documented
• admission_control defined everywhere the cost of error is high
• bus_factor recorded; single-carrier operations flagged
• fallback and review_trigger filled in for every decision
• Orphan competencies (referenced by no role) → decision made

10. Horizon 7: Organization Structure

Node Types

organizational_unit

A structural division: department, team, group, or business unit.

position

A job — a grouping of roles from H6.

accountability_level maps to the seat ladder in Chapter 16 (execution → tasks_plans → goals_budgets → strategy). Two cases fall outside it: presence (below execution — a candidate offering credentials as if they were output; not an employable seat) and ownership (above strategy — partner/equity, not a salaried position). A candidate’s reach and orientation are matched against the seat at hiring time; they are not graph objects, because the graph models the company, not its applicants.

promise_policy — extension (on position)

Outward-facing commitment authority: what this position may promise a customer, and when it must escalate. Distinct from authority_scope above, which is inward-facing (what the position may demand internally). Two axes: demand (in) vs. promise (out).

promise_policy:
  can_promise: true
  max_discount: "10%"
  max_sla: "48h"
  requires_approval_if:
    - "custom integration"
    - "legal commitment"
    - "price below floor"

The specific limits (discount %, SLA) are illustrative — keep them in industry examples (Appendix F), not the general schema.

reporting_line

A formal reporting relationship.

dependency_line

A dependency relationship — who depends on whom for results. May not match reporting_line.

H7 Edges

H7 Validation Rules

1. Position without roles: position with no role_refs = doesn’t execute any operations. Candidate for removal.
2. Detached unit: organizational_unit whose positions have no dependency_lines to other units AND no role_refs to H4 = disconnected from the graph.
3. Reporting without dependency: A reports to B, but no operation of A depends on B and vice versa → why the reporting line?
4. Span of dependency: incoming dependency_lines with criticality = high/blocking > 10 per position = overload signal.
5. Right without capability: reporting_line with right_type = formal, but authority_scope is empty = formal subordination without control instruments.
6. Informal critical dependency: dependency_line with criticality = high + formalization_status = informal = critical dependency running on personal agreements. Candidate for formalization.
7. Reporting/dependency mismatch: > 50% of critical dependency_lines run outside the reporting_line chain = divergence between formal and actual structure.

H7 Checklist

• Every position → ≥1 role_refs — no positions that execute nothing
• Accountability lands on exactly one person per decision loop
• Three conditions checked per position: understand / decide / take the hit
• Every organizational_unit connected to the graph via role_refs or dependency_lines
• Every reporting_line backed by a real operational dependency
• authority_scope filled in wherever right_type = formal
• Critical dependency_lines with informal status → decision on formalization
• Incoming critical dependencies per position measured against a threshold you set yourself (the validation rules use 10 as a starting point)
• Formal vs actual structure compared: the share of critical dependencies running outside the reporting chain is measured and accepted (the validation rules use 50% as a starting point)
• Team type per unit matches the work that is actually done there

11. Canonical Edge Table

The named edge types — the ones you traverse when reading the graph or running a validation rule. Each is defined once, in one direction. Ref-attributes on nodes (Section 2) link nodes too; they are not listed here.

Within horizons

Between horizons

The requires ↔ delivers pair: These are the same edge viewed from two sides. Stored once in the graph. requires = view from H3 (“I need a process”). delivers = view from H4 (“I produce a deliverable”). In software — one edge with a direction.

12. Cross-Horizon Validation Rules (consolidated)

End-to-end traceability

FOR EACH counterparty IN H1:
  trace = counterparty → pain_points → triggers → steps → question_nodes 
          → touchpoints(H2) → deliverables(H3) → processes(H4) 
          → support(H5) → sourcing(H6) → positions(H7)
  IF any link in trace is broken:
    FLAG "Broken trace for counterparty {counterparty.name} at {broken_link}"

Coverage cascade (top down)

SLA cascade (top down)

FOR EACH deliverable IN H3:
  expected = deliverable.sla.target
  actual = SUM(processes.cycle_time) + SUM(control_points.duration) + buffer(20%)
  IF actual > expected:
    FLAG "SLA breach: {deliverable.name} promises {expected}, processes need {actual}"

Orphan checks (bottom up)

Consistency checks

13. AI Prompt Templates

Ready-to-use prompts for populating and validating the graph with AI.

Prompt 1: Fill an H4 node

I have a deliverable on H3:
- name: [name]
- SLA: [target time]
- acceptance_criteria: [criteria]

Describe the backstage_process for producing this deliverable in DSL format:
- inputs (including customer_inputs)
- outputs
- operations (list of elementary actions)
- control_points (with check_type: process_design or execution_discipline)
- cycle_time (estimate)
- mode (Build or Run)
- role (Execute or Control)

Format: YAML. Don't invent data — where you don't know, write "unknown" or "estimate".

Prompt 2: Orphan/Bloat audit

Here are my H5 (supporting processes) and H4 (core processes) nodes:

H4: [list]
H5: [list]

Run three checks:
1. Orphan check: which H5 nodes have no enables → H4 link?
2. Bloat check: H5/H4 ratio (target: ≤ 2:1)
3. Zombie check: which H5 nodes are listed in enables but the H4 consumer doesn't actually use their output?

For each finding — recommendation: delete, merge, or revisit the link.

Prompt 3: SLA cascade check

Here's a deliverable from H3 and the process that produces it:

Deliverable: [YAML]
Process: [YAML with operations and control_points]

Check:
1. SUM(operation.duration) + SUM(control_point.duration) + 20% buffer ≤ deliverable.sla.target?
2. If not — which operations are the bottleneck?
3. Suggest options: (a) simplify the process, (b) revise the SLA, (c) automate the bottleneck.

Prompt 4: H6 sourcing decision

I have an operation from H4:
- name: [name]
- inputs: [inputs]
- outputs: [outputs]
- duration: [duration]
- current performer: [who does it now]

Help me formulate a sourcing_decision in DSL format:
- decision: make / buy / outsource / automate (with rationale)
- For each option: pros, cons, bus_factor, fallback, review_trigger
- Selection criteria: frequency, variability, error cost, speed, market availability

Format: YAML. Where you need information you don't have — ask.

Prompt 5: H7 role compatibility check

I want to combine two roles into one position:

Role 1: [YAML with context_profile]
Role 2: [YAML with context_profile]

Check compatibility on three criteria:
1. attention_type: both require deep focus in different domains? → incompatible
2. toolset: different environments, different professional vocabularies? → marker
3. feedback_rhythm: one "fast" (minutes), the other "slow" (weeks)? → risky

Practical test: time to productivity after switching contexts.
Minutes — fine. Hours — caution. Days — incompatible.

Verdict and rationale.

14. YAML Example: SaaS Company (end-to-end fragment H1→H4)

# === H1 ===
counterparty:
  id: p_ops_manager
  name: "Operations Manager, B2B SaaS, 50-200 employees"
  horizon: H1
  node_type: counterparty
  role: "Head of Operations"
  context: "Fast-growing SaaS, 80 employees, processes live in people's heads"
  confidence: 0.8
  evidence: ["12 interviews", "support analysis: 40% of tickets are process-related"]
  pain_refs: [pp_tribal_knowledge]

pain_point:
  id: pp_tribal_knowledge
  name: "Knowledge lives in people's heads, not in systems"
  horizon: H1
  node_type: pain_point
  severity: high
  frequency: constant
  cost_estimate: "2-3 weeks to onboard a new manager instead of 3 days"
  awareness: aware_active
  trigger_refs: [tr_key_person_quit]
  confidence: 0.85
  evidence: ["exit interviews", "onboarding surveys"]

trigger:
  id: tr_key_person_quit
  name: "Key employee quits"
  horizon: H1
  node_type: trigger
  event: "Team lead submitted resignation, team of 8 left without the context holder"
  source: internal
  urgency: high
  activates: [step_2]

# === H2 ===
touchpoint:
  id: tp_process_audit_landing
  name: "Landing page: 'What does process chaos cost you?'"
  horizon: H2
  node_type: touchpoint
  ownership_type: owned
  step_ref: step_2
  info_need_ref: [qn_cost_of_chaos]
  counterparty_ref: [p_ops_manager]
  channel_ref: ch_website
  moment_of_truth: true
  customer_expectation: "Understand the scale of the problem in dollars"
  content_type: self_serve_tool
  friction_level: low
  latency: "instant"
  outcome: "Calculator showed: chaos costs $180K/year. Demo requested."
  outcome_type: progress
  confidence: 0.7
  evidence: ["GA: 200 visits/mo", "conversion to demo: 8%"]

# === H3 ===
deliverable:
  id: del_chaos_calculator
  name: "Process chaos cost calculator"
  horizon: H3
  node_type: deliverable
  outcome_type: education
  triggered_by: [tp_process_audit_landing]
  customer_inputs:
    - input_name: "Number of employees"
      format: "number"
    - input_name: "Average salary"
      format: "number"
    - input_name: "Key people who left in the past year"
      format: "number"
  sla:
    target: "instant"
    inherited_from: tp_process_audit_landing
    clock_starts: on_trigger
    conflict: none
  acceptance_criteria:
    - "Calculation formula is correct"
    - "Result is plausible (neither alarming nor trivially low)"
  qualification_signals:
    - "User requests a demo after the calculation"
  requires: [bp_calculator_maintenance]
  scalability_class: fixed

# === H4 ===
backstage_process:
  id: bp_calculator_maintenance
  name: "Chaos calculator maintenance"
  horizon: H4
  node_type: backstage_process
  purpose: "Keep calculator formulas and benchmarks current"
  mode: Run
  role: Execute
  triggered_by: [del_chaos_calculator]
  inputs:
    - "Industry benchmarks (quarterly)"
    - "User feedback"
  outputs:
    - "Updated formulas"
    - "Current coefficients"
  composed_of:
    - op_collect_benchmarks
    - op_update_formulas
    - op_regression_test
  control_points:
    - id: cp_formula_accuracy
      check_type: process_design
      criteria: "Calculator result deviates from manual calculation by no more than 15%"
      checker: "Product Manager"
      frequency: quarterly
  cycle_time: "2 days/quarter"
  owner: "Product Manager"
  delivers: [del_chaos_calculator]

Complete specification. For industry-specific examples, see Appendix F.