export declare const SHIPPED_CATALOGUE_SOURCE = "format: yarramate/question-catalogue/v1\nid: core-enrichment\nversion: \"2.0\"\nprofile: yarramate/core@0.1\npresentation:\n  title: Core enrichment interview\n  description: >-\n    The guided design path: motivation, interaction, business, application,\n    technology, and implementation waves plus cross-cutting hygiene. Each\n    question\n    states the decision its answer changes; a question that cannot is\n    deleted, not softened. Adequacy is enforced by linkage depth and\n    attestation, never by reading words. Versioning is additive within a\n    major version: every question records the catalogue version it arrived\n    in (ADR 0063), and a completed interview honestly reopens when the\n    path deepens.\n\nwaves:\n  - id: motivation\n    name: Motivation\n    description: Why the system exists and what constrains it.\n  - id: interaction\n    name: Interaction\n    description: >-\n      Load-bearing hops: the behavior a component is assigned to or the\n      interface it composes, the serving/triggering/flow mechanism,\n      payload, trust, reliability, and capacity. Hygiene waits.\n    opensWhen:\n      - condition: has-any-subject\n  - id: business\n    name: Business\n    description: Who acts, what is served, and what information matters.\n    opensWhen:\n      - condition: has-any-subject\n  - id: application\n    name: Application\n    description: >-\n      How declared services are realized, performed, and fed with\n      information. Waits for a declared service, because that is what this\n      wave asks about the realization of. The kinds here are exactly the ones\n      `no-service-declared` asks for, so this wave opens precisely when that\n      question closes.\n    opensWhen:\n      - condition: has-subject-of-kind\n        kinds:\n          - yarramate/core@0.1#businessService\n          - yarramate/core@0.1#applicationService\n          - yarramate/core@0.1#technologyService\n  - id: technology\n    name: Technology\n    description: >-\n      Where the declared applications actually run and what materializes\n      them. Waits for a declared application component, because asking\n      where something runs before anything is declared to run is a question\n      with no subject.\n    opensWhen:\n      - condition: has-subject-of-kind\n        kinds:\n          - yarramate/core@0.1#applicationComponent\n  - id: implementation\n    name: Implementation\n    description: >-\n      How the planned architecture becomes real: work, deliverables, and\n      the plateaus between here and there. NOT phase-gated, deliberately:\n      every candidate gate names something this wave exists to elicit, and\n      a declared state compiles to a plateau, which closes this wave's own\n      lead question. See ADR 0136.\n    opensWhen:\n      - condition: has-any-subject\n  - id: hygiene\n    name: Model hygiene\n    description: Cross-cutting completeness that keeps every wave honest.\n    opensWhen:\n      - condition: has-any-subject\n\nquestions:\n  # ---- motivation ----------------------------------------------------------\n  - id: outcome-missing\n    wave: motivation\n    since: \"0.1\"\n    scope: workspace\n    trigger:\n      - condition: no-subject-of-kind\n        kinds:\n          - yarramate/core@0.1#goal\n          - yarramate/core@0.1#outcome\n    question: >-\n      What outcome justifies this system's existence?\n    askPlain: >-\n      What would success look like for this system? What should be\n      different in the business because it exists?\n    materiality: >-\n      Without a declared goal or outcome, no alternative can be selected or\n      rejected on grounds anyone can review; every later trade-off becomes\n      taste.\n    authority: human\n    resolution: >-\n      Add at least one goal or outcome concept and relate principal services\n      to it with realization.\n\n  - id: stakeholders-missing\n    wave: motivation\n    since: \"0.1\"\n    scope: workspace\n    trigger:\n      - condition: no-subject-of-kind\n        kinds:\n          - yarramate/core@0.1#stakeholder\n          - yarramate/core@0.1#driver\n    question: >-\n      Which stakeholders and drivers shape this architecture?\n    askPlain: >-\n      Who cares about this system, and what outside pressures are\n      pushing on it: customers, regulators, costs, deadlines?\n    materiality: >-\n      Drivers decide which qualities dominate when requirements conflict;\n      unstated drivers get re-litigated in every review.\n    authority: human\n    resolution: >-\n      Add stakeholder and driver concepts; use influence relationships toward\n      the goals they shape.\n\n  - id: constraints-missing\n    wave: motivation\n    since: \"0.1\"\n    scope: workspace\n    trigger:\n      - condition: no-subject-of-kind\n        kinds:\n          - yarramate/core@0.1#constraint\n          - yarramate/core@0.1#requirement\n    question: >-\n      Which constraints and requirements are non-negotiable?\n    askPlain: >-\n      What are the hard rules here? Is there anything we absolutely\n      must do, or must never do, no matter which option we pick?\n    materiality: >-\n      Non-negotiable constraints eliminate alternatives outright; discovering\n      them after design selection invalidates the selection.\n    authority: human\n    resolution: >-\n      Add constraint or requirement concepts and attach constraint references\n      from the subjects they bind.\n\n  - id: goal-unrealized\n    wave: motivation\n    since: \"0.1\"\n    scope: subject\n    subjects:\n      kinds:\n        - yarramate/core@0.1#goal\n        - yarramate/core@0.1#outcome\n    trigger:\n      - condition: missing-relationship\n        kinds:\n          - yarramate/core@0.1#realization\n        direction: incoming\n    question: >-\n      Nothing realizes {subject.name}. What fulfils it \u2014 or is it\n      aspirational?\n    askPlain: >-\n      Nothing in the plan currently delivers \"{subject.name}\". What is\n      going to get us there? Or is it more of an aspiration for now?\n    materiality: >-\n      An unrealized goal either reprioritizes the roadmap or should be\n      declared aspirational so it stops steering design.\n    authority: either\n    resolution: >-\n      Add realization relationships from the fulfilling capability or\n      service, record the aspirational status in the goal's description,\n      or retire the goal (status: retired) to record that it no longer\n      steers design. A goal may also be authored retired from the start:\n      status retired with the rationale in its description is the\n      declared non-goal record, and exports render it under a Non-goals\n      heading (ADR 0073).\n\n\n  - id: goal-no-driver\n    wave: motivation\n    since: \"0.3\"\n    scope: subject\n    subjects:\n      kinds:\n        - yarramate/core@0.1#goal\n        - yarramate/core@0.1#outcome\n    trigger:\n      - condition: missing-linkage\n        kinds:\n          - yarramate/core@0.1#influence\n        direction: incoming\n        counterpartKinds:\n          - yarramate/core@0.1#driver\n          - yarramate/core@0.1#assessment\n          - yarramate/core@0.1#stakeholder\n    question: >-\n      What pressure produces {subject.name}?\n    askPlain: >-\n      Why is \"{subject.name}\" a goal at all? Who or what is pushing\n      for it?\n    materiality: >-\n      A goal with no driver behind it cannot be reprioritized when the\n      environment changes; it floats free of the forces that would retire\n      or sharpen it.\n    authority: human\n    resolution: >-\n      Add the driver, assessment, or stakeholder that motivates the goal\n      and connect it with an influence relationship.\n\n  - id: driver-influences-nothing\n    wave: motivation\n    since: \"0.3\"\n    scope: subject\n    subjects:\n      kinds:\n        - yarramate/core@0.1#driver\n    trigger:\n      - condition: missing-relationship\n        kinds:\n          - yarramate/core@0.1#influence\n        direction: outgoing\n    question: >-\n      What does {subject.name} actually push on?\n    askPlain: >-\n      We say \"{subject.name}\" matters. What would we decide differently\n      because of it? If nothing, does it belong in this conversation?\n    materiality: >-\n      A driver that influences nothing cannot participate in any trade-off;\n      it is context theatre until it points at a goal or principle.\n    authority: either\n    resolution: >-\n      Add influence relationships toward the goals, principles, or\n      assessments the driver shapes, or remove it.\n\n  - id: stakeholder-unconcerned\n    wave: motivation\n    since: \"0.3\"\n    scope: subject\n    subjects:\n      kinds:\n        - yarramate/core@0.1#stakeholder\n    trigger:\n      - condition: missing-relationship\n        kinds:\n          - yarramate/core@0.1#influence\n          - yarramate/core@0.1#association\n        direction: any\n    question: >-\n      What does {subject.name} care about here?\n    askPlain: >-\n      What does {subject.name} actually care about in all this? What\n      would make them push back, and what would make them happy?\n    materiality: >-\n      A stakeholder with no stated concern cannot veto or endorse anything;\n      their objections will arrive as surprises at review time.\n    authority: human\n    resolution: >-\n      Relate the stakeholder to the goals or drivers they care about, or\n      remove them from the model.\n\n  - id: requirement-unrealized\n    wave: motivation\n    since: \"0.3\"\n    scope: subject\n    subjects:\n      kinds:\n        - yarramate/core@0.1#requirement\n    trigger:\n      - condition: missing-relationship\n        kinds:\n          - yarramate/core@0.1#realization\n        direction: incoming\n    question: >-\n      Nothing realizes {subject.name}. What will fulfil it \u2014 or is it\n      out of scope?\n    askPlain: >-\n      Who or what is going to make \"{subject.name}\" happen? Or should\n      we agree to drop it?\n    materiality: >-\n      An unrealized requirement is either unplanned work hiding in plain\n      sight or scope that should be explicitly declined; both change the\n      roadmap.\n    authority: either\n    resolution: >-\n      Add realization from the fulfilling service, component, or\n      behavior; to descope instead, retire the requirement (status:\n      retired) \u2014 retirement preserves the decision on record and closes\n      the question (ADR 0064). Descoping at inception is the same\n      motion: a requirement authored with status retired, rationale in\n      its description, is the standing non-goal record and exports\n      render it under a Non-goals heading (ADR 0073). Delete only when\n      the history itself is noise.\n\n  - id: principle-unapplied\n    wave: motivation\n    since: \"0.3\"\n    scope: subject\n    subjects:\n      kinds:\n        - yarramate/core@0.1#principle\n    trigger:\n      - condition: missing-relationship\n        kinds:\n          - yarramate/core@0.1#influence\n          - yarramate/core@0.1#realization\n        direction: any\n    question: >-\n      Where does {subject.name} bite?\n    askPlain: >-\n      Where does the principle \"{subject.name}\" actually change how we\n      work? Can you point to a decision it has shaped, or would shape?\n    materiality: >-\n      A principle applied nowhere constrains nothing; naming what it\n      influences is what makes it enforceable in review.\n    authority: either\n    resolution: >-\n      Add influence from the principle to the goals, outcomes, or\n      requirements it shapes, or realization from the requirements and\n      constraints that make it concrete. Influence only points at\n      motivation elements; a decision is recorded as the requirement it\n      produced.\n  - id: assessment-unlinked\n    wave: motivation\n    since: \"0.3\"\n    scope: subject\n    subjects:\n      kinds:\n        - yarramate/core@0.1#assessment\n    trigger:\n      - condition: isolated\n    question: >-\n      What does the finding {subject.name} bear on?\n    askPlain: >-\n      We recorded the finding \"{subject.name}\". What does it actually\n      tell us, and what should change because of it?\n    materiality: >-\n      An assessment that touches nothing changes no decision; link it to\n      the driver or goal it evaluates or drop it.\n    authority: either\n    resolution: >-\n      Relate the assessment to its driver or goal with influence or\n      association.\n\n  - id: motivation-unattested\n    wave: motivation\n    since: \"0.3\"\n    scope: subject\n    subjects:\n      kinds:\n        - yarramate/core@0.1#goal\n        - yarramate/core@0.1#outcome\n        - yarramate/core@0.1#requirement\n    trigger:\n      - condition: missing-attestation\n        topic: adequacy\n    question: >-\n      Has an accountable reviewer accepted {subject.name} as adequately\n      stated?\n    askPlain: >-\n      Is everyone happy with how \"{subject.name}\" is written up? Who in\n      this room is willing to put their name on it as correct?\n    materiality: >-\n      Linkage proves the wiring exists; only a recorded judgment says the\n      words are right. Without an attestation, adequacy is nobody's\n      decision on record.\n    authority: human\n    resolution: >-\n      Review the subject's description and linkage, then record an\n      attestation with topic \"adequacy\" (revoke by deleting it; Git\n      reviews both).\n\n  # ---- interaction ---------------------------------------------------------\n  - id: authn-standard-missing\n    wave: interaction\n    since: \"0.9\"\n    scope: workspace\n    trigger:\n      - condition: exists-linkage\n        kinds:\n          - yarramate/core@0.1#serving\n          - yarramate/core@0.1#flow\n          - yarramate/core@0.1#triggering\n        direction: either\n        counterpartKinds:\n          - yarramate/core@0.1#applicationComponent\n          - yarramate/core@0.1#applicationInterface\n          - yarramate/core@0.1#businessActor\n      - condition: no-subject-of-kind\n        kinds:\n          - yarramate/policy@0.1#authentication-constraint\n    question: >-\n      What is the default authentication mechanism for interactions in this\n      architecture?\n    askPlain: >-\n      When one system talks to another here, how do they prove who they\n      are? Pick the default now so each hop is not inventing its own.\n    materiality: >-\n      An unauthenticated hop to another system is a trust-boundary decision\n      nobody recorded. Implementers will pick a mechanism in code, and the\n      next hop will assume a different one. This question does not cover\n      authorization or transport security.\n    authority: human\n    resolution: >-\n      Add an authentication-constraint (the standard, or a not-applicable\n      subject with the reason in its description) in a document that\n      selects yarramate/policy@0.1.\n\n  - id: ratelimit-standard-missing\n    wave: interaction\n    since: \"0.9\"\n    scope: workspace\n    trigger:\n      - condition: exists-linkage\n        kinds:\n          - yarramate/core@0.1#serving\n        direction: either\n        counterpartKinds:\n          - yarramate/core@0.1#businessActor\n      - condition: no-subject-of-kind\n        kinds:\n          - yarramate/policy@0.1#rate-limit-constraint\n    question: >-\n      Where is rate limiting a requirement, and what is the default rule?\n    askPlain: >-\n      Do caller-facing APIs have a capacity cap? If yes, what is it? If\n      no, say so so we do not keep asking per hop.\n    materiality: >-\n      Caller-facing hops without a capacity rule are sized by whoever\n      implements first. An explicit none is a decision; silence is not.\n    authority: human\n    resolution: >-\n      Add a rate-limit-constraint for the default cap, or a\n      ratelimit-not-applicable subject. Bind hop-specific values with\n      expects on the binding.\n\n  - id: reliability-standard-missing\n    wave: interaction\n    since: \"0.9\"\n    scope: workspace\n    trigger:\n      - condition: exists-linkage\n        kinds:\n          - yarramate/core@0.1#flow\n          - yarramate/core@0.1#triggering\n        direction: either\n        counterpartKinds:\n          - yarramate/core@0.1#applicationComponent\n          - yarramate/core@0.1#applicationInterface\n          - yarramate/core@0.1#applicationService\n          - yarramate/core@0.1#applicationProcess\n          - yarramate/core@0.1#applicationFunction\n          - yarramate/core@0.1#applicationInteraction\n          - yarramate/core@0.1#applicationEvent\n          - yarramate/core@0.1#businessActor\n      - condition: no-subject-of-kind\n        kinds:\n          - yarramate/policy@0.1#reliability-constraint\n    question: >-\n      What is the default delivery, retry, and idempotency rule for\n      asynchronous or content-moving interactions?\n    askPlain: >-\n      When a message or payload does not arrive, do we retry, and what\n      makes a retry safe to repeat?\n    materiality: >-\n      Retry without idempotency duplicates work; no retry without a\n      recorded choice leaves timeout behaviour to each implementer.\n    authority: human\n    resolution: >-\n      Add a reliability-constraint (the standard, or not-applicable with\n      the reason in its description).\n\n  - id: hop-unrealised\n    wave: interaction\n    since: \"0.9\"\n    scope: subject\n    subjects:\n      kinds:\n        - yarramate/core@0.1#applicationComponent\n      statuses:\n        - planned\n        - current\n    trigger:\n      - condition: has-linkage\n        kinds:\n          - yarramate/core@0.1#serving\n          - yarramate/core@0.1#flow\n          - yarramate/core@0.1#triggering\n        direction: either\n        counterpartKinds:\n          - yarramate/core@0.1#applicationComponent\n          - yarramate/core@0.1#applicationInterface\n          - yarramate/core@0.1#applicationService\n          - yarramate/core@0.1#businessActor\n      - condition: missing-linkage\n        kinds:\n          - yarramate/core@0.1#assignment\n        direction: outgoing\n        counterpartKinds:\n          - yarramate/core@0.1#applicationProcess\n          - yarramate/core@0.1#applicationFunction\n          - yarramate/core@0.1#applicationInteraction\n          - yarramate/core@0.1#applicationEvent\n      - condition: missing-linkage\n        kinds:\n          - yarramate/core@0.1#composition\n          - yarramate/core@0.1#aggregation\n        direction: outgoing\n        counterpartKinds:\n          - yarramate/core@0.1#applicationInterface\n    question: >-\n      {subject.name} participates in an application interaction, but\n      nothing it is assigned to or composes is that interaction. What\n      process, function, interaction, event, or interface is the hop?\n    askPlain: >-\n      {subject.name} talks to something else, but the model never names\n      the work it does in that talk. What is the actual step?\n    materiality: >-\n      A component-to-component edge with no assigned behavior or composed\n      interface is inventory. Protocol, trust, payload, and failure have\n      nowhere to bind until the hop is a subject.\n    authority: either\n    resolution: >-\n      Add the application process, function, interaction, or event this\n      component performs and assign the component to it, or add the\n      application interface it exposes and compose it into the component;\n      then relate that behavior or interface with serving, triggering, or\n      flow to its counterpart. Realizing a service does not close this:\n      the service is what the hop offers, the process or interface is the\n      hop. Do not answer by deleting the component.\n\n  - id: interaction-protocol-unbound\n    wave: interaction\n    since: \"0.9\"\n    scope: subject\n    subjects:\n      kinds:\n        - yarramate/core@0.1#applicationProcess\n        - yarramate/core@0.1#applicationFunction\n        - yarramate/core@0.1#applicationInteraction\n        - yarramate/core@0.1#applicationEvent\n        - yarramate/core@0.1#applicationInterface\n      statuses:\n        - planned\n        - current\n    trigger:\n      - condition: has-linkage\n        kinds:\n          - yarramate/core@0.1#serving\n        direction: either\n        counterpartKinds:\n          - yarramate/core@0.1#applicationComponent\n          - yarramate/core@0.1#applicationInterface\n          - yarramate/core@0.1#applicationService\n          - yarramate/core@0.1#applicationProcess\n          - yarramate/core@0.1#applicationFunction\n          - yarramate/core@0.1#applicationInteraction\n          - yarramate/core@0.1#applicationEvent\n          - yarramate/core@0.1#businessActor\n      - condition: missing-constraint\n        kinds:\n          - yarramate/policy@0.1#mechanism-constraint\n    question: >-\n      {subject.name} is a serving hop. Which protocol is it \u2014 REST/HTTP,\n      SOAP, GraphQL, or something else?\n    askPlain: >-\n      When {subject.name} is called, what is the wire protocol?\n    materiality: >-\n      Serving names the pattern, not the contract. A REST hop and a SOAP\n      hop fail, version, and authenticate differently.\n    authority: either\n    resolution: >-\n      Bind a mechanism-constraint on this behavior or interface (or a not-applicable\n      subject if the serving kind is already the whole answer).\n\n  - id: interaction-content-unknown\n    wave: interaction\n    since: \"0.9\"\n    scope: subject\n    subjects:\n      kinds:\n        - yarramate/core@0.1#applicationProcess\n        - yarramate/core@0.1#applicationFunction\n        - yarramate/core@0.1#applicationInteraction\n        - yarramate/core@0.1#applicationEvent\n        - yarramate/core@0.1#applicationInterface\n      statuses:\n        - planned\n        - current\n    trigger:\n      - condition: missing-flow-content\n    question: >-\n      {subject.name} sends a flow with no content. What moves?\n    askPlain: >-\n      {subject.name} sends something on. What is that something called?\n    materiality: >-\n      A flow with no content is an unnamed payload. Retry, scanning, and\n      the counterpart contract have nothing to name.\n    authority: either\n    resolution: >-\n      Set content on the flow relationship.\n\n  - id: interaction-contract-unknown\n    wave: interaction\n    since: \"0.9\"\n    scope: subject\n    subjects:\n      kinds:\n        - yarramate/core@0.1#applicationProcess\n        - yarramate/core@0.1#applicationFunction\n        - yarramate/core@0.1#applicationInteraction\n        - yarramate/core@0.1#applicationEvent\n        - yarramate/core@0.1#applicationInterface\n        - yarramate/core@0.1#applicationService\n      statuses:\n        - planned\n        - current\n    trigger:\n      - condition: has-linkage\n        kinds:\n          - yarramate/core@0.1#serving\n          - yarramate/core@0.1#flow\n          - yarramate/core@0.1#triggering\n        direction: either\n        counterpartKinds:\n          - yarramate/core@0.1#applicationComponent\n          - yarramate/core@0.1#applicationInterface\n          - yarramate/core@0.1#applicationService\n          - yarramate/core@0.1#applicationProcess\n          - yarramate/core@0.1#applicationFunction\n          - yarramate/core@0.1#applicationInteraction\n          - yarramate/core@0.1#applicationEvent\n          - yarramate/core@0.1#businessActor\n      - condition: missing-linkage\n        kinds:\n          - yarramate/core@0.1#access\n        direction: outgoing\n        counterpartKinds:\n          - yarramate/core@0.1#dataObject\n          - yarramate/core@0.1#contract\n    question: >-\n      {subject.name} participates in a hop but accesses no contract or\n      data object. What information does it read or write?\n    askPlain: >-\n      What record or contract is {subject.name} working with?\n    materiality: >-\n      Schema ownership, identifiers, and classification have nowhere to\n      attach until the hop names the information it moves.\n    authority: either\n    resolution: >-\n      Add access from this behavior to a dataObject or contract.\n\n  - id: interaction-trust-unbound\n    wave: interaction\n    since: \"0.9\"\n    scope: subject\n    subjects:\n      kinds:\n        - yarramate/core@0.1#applicationProcess\n        - yarramate/core@0.1#applicationFunction\n        - yarramate/core@0.1#applicationInteraction\n        - yarramate/core@0.1#applicationEvent\n        - yarramate/core@0.1#applicationInterface\n      statuses:\n        - planned\n        - current\n    trigger:\n      - condition: has-linkage\n        kinds:\n          - yarramate/core@0.1#serving\n          - yarramate/core@0.1#flow\n          - yarramate/core@0.1#triggering\n        direction: either\n        counterpartKinds:\n          - yarramate/core@0.1#applicationComponent\n          - yarramate/core@0.1#applicationInterface\n          - yarramate/core@0.1#applicationService\n          - yarramate/core@0.1#applicationProcess\n          - yarramate/core@0.1#applicationFunction\n          - yarramate/core@0.1#applicationInteraction\n          - yarramate/core@0.1#applicationEvent\n          - yarramate/core@0.1#businessActor\n      - condition: missing-constraint\n        kinds:\n          - yarramate/policy@0.1#authentication-constraint\n    question: >-\n      How is trust established for {subject.name}?\n    askPlain: >-\n      Who does {subject.name} authenticate as, and with what?\n    materiality: >-\n      An unauthenticated hop to another system is a trust-boundary\n      decision nobody recorded. This is authentication only \u2014 not\n      authorization or transport security.\n    authority: either\n    resolution: >-\n      Bind an authentication-constraint on this behavior, or a\n      not-applicable subject if this hop is deliberately unauthenticated.\n\n  - id: interaction-reliability-unbound\n    wave: interaction\n    since: \"0.9\"\n    scope: subject\n    subjects:\n      kinds:\n        - yarramate/core@0.1#applicationProcess\n        - yarramate/core@0.1#applicationFunction\n        - yarramate/core@0.1#applicationInteraction\n        - yarramate/core@0.1#applicationEvent\n        - yarramate/core@0.1#applicationInterface\n      statuses:\n        - planned\n        - current\n    trigger:\n      - condition: has-linkage\n        kinds:\n          - yarramate/core@0.1#triggering\n          - yarramate/core@0.1#flow\n        direction: either\n        counterpartKinds:\n          - yarramate/core@0.1#applicationComponent\n          - yarramate/core@0.1#applicationInterface\n          - yarramate/core@0.1#applicationService\n          - yarramate/core@0.1#applicationProcess\n          - yarramate/core@0.1#applicationFunction\n          - yarramate/core@0.1#applicationInteraction\n          - yarramate/core@0.1#applicationEvent\n          - yarramate/core@0.1#businessActor\n      - condition: missing-constraint\n        kinds:\n          - yarramate/policy@0.1#reliability-constraint\n    question: >-\n      What happens when {subject.name} fails \u2014 retry, idempotency,\n      dead-letter, compensation?\n    askPlain: >-\n      If {subject.name} does not finish, do we retry, and what makes a\n      retry safe?\n    materiality: >-\n      A content-moving hop without a reliability rule duplicates or\n      drops work at the first timeout.\n    authority: either\n    resolution: >-\n      Bind a reliability-constraint. A named failure process is stronger\n      and may come later; the constraint is the 0.9 closer.\n\n  - id: interaction-capacity-unbound\n    wave: interaction\n    since: \"0.9\"\n    scope: subject\n    subjects:\n      kinds:\n        - yarramate/core@0.1#applicationProcess\n        - yarramate/core@0.1#applicationFunction\n        - yarramate/core@0.1#applicationInteraction\n        - yarramate/core@0.1#applicationEvent\n        - yarramate/core@0.1#applicationInterface\n      statuses:\n        - planned\n        - current\n    trigger:\n      - condition: has-linkage\n        kinds:\n          - yarramate/core@0.1#serving\n        direction: either\n        counterpartKinds:\n          - yarramate/core@0.1#businessActor\n      - condition: missing-constraint\n        kinds:\n          - yarramate/policy@0.1#rate-limit-constraint\n    question: >-\n      What is the capacity rule for {subject.name}?\n    askPlain: >-\n      How hard may callers hit {subject.name}, or is there no cap?\n    materiality: >-\n      An Experience-facing hop without a capacity rule is sized by\n      whoever implements first. Explicit none is a decision.\n    authority: either\n    resolution: >-\n      Bind a rate-limit-constraint, with expects on the binding for the\n      numeric cap, or a not-applicable subject.\n\n  # ---- business ------------------------------------------------------------\n  - id: service-consumer-unknown\n    wave: business\n    since: \"0.1\"\n    scope: subject\n    subjects:\n      kinds:\n        - yarramate/core@0.1#businessService\n        - yarramate/core@0.1#applicationService\n        - yarramate/core@0.1#technologyService\n    trigger:\n      - condition: missing-relationship\n        kinds:\n          - yarramate/core@0.1#serving\n        direction: outgoing\n    question: >-\n      Who or what consumes {subject.name}?\n    askPlain: >-\n      Who actually uses \"{subject.name}\"? If we cannot name anyone,\n      why do we offer it?\n    materiality: >-\n      A service with no consumer is either the system boundary stated\n      implicitly, missing model detail, or scope to delete.\n    authority: either\n    resolution: >-\n      Add serving relationships to the consuming actor, process, or\n      component; if the consumer is external, model it as an actor.\n\n  - id: owner-missing\n    wave: business\n    since: \"0.1\"\n    scope: subject\n    subjects:\n      kinds:\n        - yarramate/core@0.1#businessService\n        - yarramate/core@0.1#applicationService\n        - yarramate/core@0.1#applicationComponent\n        - yarramate/core@0.1#capability\n    trigger:\n      - condition: missing-claim\n        predicate: yarramate/ownership/owner\n    question: >-\n      Who is accountable for {subject.name}?\n    askPlain: >-\n      If something goes wrong with \"{subject.name}\", whose desk does\n      it land on?\n    materiality: >-\n      Ownership decides who accepts changes, budgets maintenance, and\n      adjudicates constraint conflicts for the subject.\n    authority: either\n    resolution: >-\n      Add an owner reference to an accountable actor (evidence such as\n      CODEOWNERS may propose it; a human confirms accountability).\n\n  - id: responsible-missing\n    wave: business\n    since: \"1.33\"\n    scope: subject\n    subjects:\n      kinds:\n        - yarramate/core@0.1#businessService\n        - yarramate/core@0.1#applicationService\n        - yarramate/core@0.1#applicationComponent\n        - yarramate/core@0.1#capability\n    trigger:\n      - condition: missing-linkage\n        kinds:\n          - yarramate/policy@0.2#responsible\n        direction: incoming\n        counterpartKinds:\n          - yarramate/core@0.1#businessActor\n          - yarramate/core@0.1#businessRole\n          - yarramate/core@0.1#businessCollaboration\n          - yarramate/core@0.1#stakeholder\n    question: >-\n      Who is responsible for {subject.name}?\n    askPlain: >-\n      Who actually builds, runs or delivers \"{subject.name}\" day to day?\n    materiality: >-\n      Accountability says whose desk a failure lands on; responsibility says\n      whose hands are on it. A subject with nobody responsible has nobody to\n      hand the work to, and a RACI row with no R is a gap the matrix reports.\n    authority: either\n    resolution: >-\n      Add a `responsible` relationship from the actor, role or collaboration\n      that does the work to the subject (a support contract or CODEOWNERS may\n      propose it; a person confirms it).\n  - id: role-idle\n    wave: business\n    since: \"1.33\"\n    scope: subject\n    subjects:\n      kinds:\n        - yarramate/core@0.1#businessActor\n        - yarramate/core@0.1#businessRole\n        - yarramate/core@0.1#businessCollaboration\n    trigger:\n      - condition: missing-reference\n        predicate: yarramate/ownership/owner\n        direction: incoming\n      - condition: missing-relationship\n        kinds:\n          - yarramate/policy@0.2#responsible\n          - yarramate/policy@0.2#consulted\n          - yarramate/policy@0.2#informed\n        direction: outgoing\n      - condition: missing-relationship\n        kinds:\n          - yarramate/core@0.1#serving\n        direction: incoming\n    question: >-\n      What does {subject.name} answer for?\n    askPlain: >-\n      \"{subject.name}\" is in the model but owns nothing, is responsible for\n      nothing, and is neither consulted nor informed about anything. What is\n      their part, or should they go?\n    materiality: >-\n      A person with no letter is either missing the edges a delivery depends\n      on or a name that outlived its role. A served actor is a consumer, not\n      a responsibility holder, and is not asked.\n    authority: human\n    resolution: >-\n      Give the person a letter (an owner claim on what they answer for, or a\n      responsible, consulted or informed relationship) or retire the subject.\n  - id: risk-threatens-nothing\n    wave: motivation\n    since: \"1.34\"\n    scope: subject\n    subjects:\n      kinds:\n        - yarramate/policy@0.3#risk\n    trigger:\n      - condition: missing-linkage\n        kinds:\n          - yarramate/core@0.1#influence\n        direction: outgoing\n        counterpartKinds:\n          - yarramate/core@0.1#goal\n          - yarramate/core@0.1#requirement\n          - yarramate/core@0.1#constraint\n    question: >-\n      What does {subject.name} threaten?\n    askPlain: >-\n      If \"{subject.name}\" comes true, which goal, requirement or constraint\n      takes the hit?\n    materiality: >-\n      A risk that threatens nothing named cannot be prioritised or retired:\n      its severity has nothing to be measured against, and nobody can say\n      when it has passed.\n    authority: either\n    resolution: >-\n      Add an `influence` relationship from the risk to the goal, requirement\n      or constraint it threatens.\n  - id: risk-unmitigated\n    wave: motivation\n    since: \"1.34\"\n    scope: subject\n    subjects:\n      kinds:\n        - yarramate/policy@0.3#risk\n    trigger:\n      - condition: missing-linkage\n        kinds:\n          - yarramate/core@0.1#influence\n          - yarramate/core@0.1#association\n        direction: incoming\n        counterpartKinds:\n          - yarramate/core@0.1#workPackage\n          - yarramate/core@0.1#deliverable\n          - yarramate/core@0.1#constraint\n          - yarramate/core@0.1#courseOfAction\n    question: >-\n      What mitigates {subject.name}?\n    askPlain: >-\n      \"{subject.name}\" is on the log. What work, deliverable, rule or decision\n      is in place, or planned, to reduce it?\n    materiality: >-\n      A risk on the log with no mitigation is a bet the engagement is making\n      without saying so; the log exists to make that visible.\n    authority: either\n    resolution: >-\n      Add an `influence` relationship from the work package, deliverable,\n      constraint or decision that mitigates it to the risk, or retire the risk.\n  - id: risk-unowned\n    wave: motivation\n    since: \"1.34\"\n    scope: subject\n    subjects:\n      kinds:\n        - yarramate/policy@0.3#risk\n    trigger:\n      - condition: missing-claim\n        predicate: yarramate/ownership/owner\n    question: >-\n      Who owns {subject.name}?\n    askPlain: >-\n      Whose name is on \"{subject.name}\": who reviews it and decides when it\n      has passed?\n    materiality: >-\n      The risk owner is who a review date is asked of; without one,\n      risk-reviewed has no authority to sign it.\n    authority: either\n    resolution: >-\n      Add an owner reference to the actor or role that carries the risk.\n  - id: assumption-unconfirmed\n    wave: motivation\n    since: \"1.34\"\n    scope: subject\n    subjects:\n      kinds:\n        - yarramate/policy@0.3#assumption\n    trigger:\n      - condition: missing-attestation\n        topic: assumption-confirmed\n    question: >-\n      Has anyone confirmed {subject.name}?\n    askPlain: >-\n      \"{subject.name}\" is being built on. Has the person who can confirm it\n      said so, and when?\n    materiality: >-\n      An unconfirmed assumption is a risk wearing a calmer name; the\n      confirmation, with its date, is what turns it into a fact the delivery\n      can rest on.\n    authority: human\n    resolution: >-\n      Record an `assumption-confirmed` attestation by the role or actor that\n      can confirm it, dated; or retire the assumption.\n  - id: assumption-bears-on-nothing\n    wave: motivation\n    since: \"1.34\"\n    scope: subject\n    subjects:\n      kinds:\n        - yarramate/policy@0.3#assumption\n    trigger:\n      - condition: missing-relationship\n        kinds:\n          - yarramate/core@0.1#association\n        direction: outgoing\n    question: >-\n      What does {subject.name} bear on?\n    askPlain: >-\n      If \"{subject.name}\" turned out false, what in this design would change?\n    materiality: >-\n      An assumption that bears on nothing named is either decorative or\n      missing its edges, and the log cannot say which.\n    authority: either\n    resolution: >-\n      Add an `association` relationship from the assumption to the goal,\n      requirement, constraint or subject it bears on, or retire it.\n  - id: actor-unassigned\n    wave: business\n    since: \"0.1\"\n    scope: subject\n    subjects:\n      kinds:\n        - yarramate/core@0.1#businessActor\n        - yarramate/core@0.1#businessRole\n    trigger:\n      - condition: missing-relationship\n        kinds:\n          - yarramate/core@0.1#assignment\n        direction: outgoing\n    question: >-\n      What behavior is {subject.name} actually responsible for?\n    askPlain: >-\n      What does {subject.name} actually do in this picture? What work\n      are they on the hook for day to day?\n    materiality: >-\n      An actor with no assignment is either decorative or hiding an\n      undeclared responsibility boundary.\n    authority: either\n    resolution: >-\n      Add assignment relationships to the processes, functions, or services\n      the actor performs, or remove the actor.\n\n  - id: information-unaccessed\n    wave: business\n    since: \"0.1\"\n    scope: subject\n    subjects:\n      kinds:\n        - yarramate/core@0.1#businessObject\n        - yarramate/core@0.1#dataObject\n    trigger:\n      - condition: missing-relationship\n        kinds:\n          - yarramate/core@0.1#access\n          - yarramate/core@0.1#realization\n        direction: any\n    question: >-\n      Which behavior creates and maintains {subject.name}?\n    askPlain: >-\n      Where does \"{subject.name}\" come from? Who creates it, and who\n      keeps it up to date?\n    materiality: >-\n      Information nothing accesses cannot be owned, persisted, or exchanged\n      correctly; write responsibility determines consistency boundaries.\n    authority: either\n    resolution: >-\n      Add access relationships (with modes) from the behavior that reads and\n      writes it.\n\n  - id: no-service-declared\n    wave: business\n    since: \"0.1\"\n    scope: workspace\n    trigger:\n      - condition: no-subject-of-kind\n        kinds:\n          - yarramate/core@0.1#businessService\n          - yarramate/core@0.1#applicationService\n          - yarramate/core@0.1#technologyService\n    question: >-\n      What does this system offer its environment, and to whom?\n    askPlain: >-\n      In plain terms: what does this system do for people, and who are\n      those people?\n    materiality: >-\n      Declared services define the solution boundary; without them the model\n      cannot say what is inside versus outside.\n    authority: human\n    resolution: >-\n      Add the externally meaningful services and serve them to their\n      consumers.\n\n  - id: no-capability-declared\n    wave: business\n    since: \"1.2\"\n    scope: workspace\n    trigger:\n      - condition: no-subject-of-kind\n        kinds:\n          - yarramate/core@0.1#capability\n    question: >-\n      No capability is declared. What can this system do, in its own terms?\n    askPlain: >-\n      Forget the parts list for a moment: what are the handful of things\n      this system is actually able to do for the people it serves?\n    materiality: >-\n      Capabilities name what the system can do apart from how it currently\n      does it; without them, investment and sourcing trade-offs can only be\n      argued in component names, and nothing in the model can say which\n      parts serve the same ability. A subject-driven interview never asks\n      about a layer with zero subjects, so an absent capability map reads\n      as a covered one until this question opens it.\n    authority: human\n    resolution: >-\n      Add the small set of capabilities this system provides \u2014 four to\n      seven usually carries the whole conversation \u2014 and relate each to\n      the services or components that realize it with realization.\n\n  - id: no-component-declared\n    wave: business\n    since: \"2.0\"\n    scope: workspace\n    trigger:\n      - condition: no-subject-of-kind\n        kinds:\n          - yarramate/core@0.1#applicationComponent\n    question: >-\n      What software actually implements these services?\n    askPlain: >-\n      In plain terms: which applications or systems does this run on?\n    materiality: >-\n      A model with services and nothing implementing them cannot say where\n      anything runs, so the whole technology conversation has no subject.\n      This question exists to keep that conversation reachable: the\n      technology wave opens exactly when this question closes (ADR 0136).\n    authority: human\n    resolution: >-\n      Add the application components that implement the declared services.\n  - id: no-contract-declared\n    wave: business\n    since: \"1.2\"\n    scope: workspace\n    trigger:\n      - condition: exists-linkage\n        kinds:\n          - yarramate/core@0.1#serving\n          - yarramate/core@0.1#flow\n          - yarramate/core@0.1#triggering\n        direction: either\n        counterpartKinds:\n          - yarramate/core@0.1#applicationComponent\n          - yarramate/core@0.1#applicationInterface\n          - yarramate/core@0.1#applicationService\n          - yarramate/core@0.1#businessActor\n      - condition: no-subject-of-kind\n        kinds:\n          - yarramate/core@0.1#contract\n    question: >-\n      Interactions exist and no contract governs any of them. Which\n      agreements bind what this architecture exchanges?\n    askPlain: >-\n      Things here talk to each other and to the outside. Where is it\n      written down what each side may expect \u2014 the API description, the\n      published schema, the service agreement?\n    materiality: >-\n      A hop with no contract is renegotiated by every implementer who\n      touches it; compatibility and versioning obligations exist only\n      where the agreement is a subject someone can change deliberately.\n    authority: human\n    resolution: >-\n      Add a contract for each formal agreement and access it from the\n      behavior bound by it; realization from the data object or artifact\n      that embodies the agreement says where it lives.\n\n  - id: service-realizes-no-motivation\n    wave: business\n    since: \"0.3\"\n    scope: subject\n    subjects:\n      kinds:\n        - yarramate/core@0.1#businessService\n        - yarramate/core@0.1#capability\n    trigger:\n      - condition: missing-linkage\n        kinds:\n          - yarramate/core@0.1#realization\n        direction: outgoing\n        counterpartKinds:\n          - yarramate/core@0.1#requirement\n          - yarramate/core@0.1#goal\n          - yarramate/core@0.1#outcome\n    question: >-\n      Which requirement or goal does {subject.name} exist to satisfy?\n    askPlain: >-\n      Why do we have \"{subject.name}\" at all? If we dropped it\n      tomorrow, which goal or promise would suffer?\n    materiality: >-\n      A service with no motivation link cannot be traded off against\n      anything; when budgets tighten nobody can say what breaks if it\n      goes.\n    authority: either\n    resolution: >-\n      Add realization from the service or capability to the requirement,\n      goal, or outcome it satisfies.\n\n  - id: process-untriggered\n    wave: business\n    since: \"0.3\"\n    scope: subject\n    subjects:\n      kinds:\n        - yarramate/core@0.1#businessProcess\n    trigger:\n      - condition: missing-relationship\n        kinds:\n          - yarramate/core@0.1#triggering\n          - yarramate/core@0.1#assignment\n        direction: incoming\n    question: >-\n      What starts {subject.name}?\n    askPlain: >-\n      How does \"{subject.name}\" get kicked off? Does somebody start\n      it, or does something happen that sets it in motion?\n    materiality: >-\n      A process nothing triggers or performs either runs on an undeclared\n      schedule or does not actually happen; both are design facts worth\n      stating.\n    authority: either\n    resolution: >-\n      Add the triggering event or the assignment from its performer.\n\n  - id: business-service-unrealized\n    wave: business\n    since: \"0.3\"\n    scope: subject\n    subjects:\n      kinds:\n        - yarramate/core@0.1#businessService\n      statuses:\n        - planned\n        - current\n    trigger:\n      - condition: missing-linkage\n        kinds:\n          - yarramate/core@0.1#realization\n        direction: incoming\n        counterpartKinds:\n          - yarramate/core@0.1#businessProcess\n          - yarramate/core@0.1#businessFunction\n          - yarramate/core@0.1#applicationService\n          - yarramate/core@0.1#applicationComponent\n    question: >-\n      What actually delivers {subject.name}?\n    askPlain: >-\n      We promise \"{subject.name}\". Walk me through how it actually\n      gets delivered today, or how it will be.\n    materiality: >-\n      A business service with no realizing behavior or application is a\n      promise with no mechanism; the gap is where delivery estimates go\n      wrong.\n    authority: either\n    resolution: >-\n      Add realization from the business process or function that delivers\n      it, or from the application service or component that automates it.\n      A capability is realized by the service, not the other way round.\n  # ---- application ---------------------------------------------------------\n  - id: app-service-unrealized\n    wave: application\n    since: \"0.3\"\n    scope: subject\n    subjects:\n      kinds:\n        - yarramate/core@0.1#applicationService\n      statuses:\n        - planned\n        - current\n    trigger:\n      - condition: missing-linkage\n        kinds:\n          - yarramate/core@0.1#realization\n        direction: incoming\n        counterpartKinds:\n          - yarramate/core@0.1#applicationComponent\n          - yarramate/core@0.1#applicationFunction\n          - yarramate/core@0.1#applicationProcess\n          - yarramate/core@0.1#applicationCollaboration\n    question: >-\n      Which component or behavior realizes {subject.name}?\n    materiality: >-\n      An application service with no realizer is interface without\n      implementation; implementers cannot be handed a slice that names no\n      mechanism.\n    authority: either\n    resolution: >-\n      Add realization from the component, function, or process that\n      implements the service.\n\n  - id: component-realizes-nothing\n    wave: application\n    since: \"0.3\"\n    scope: subject\n    subjects:\n      kinds:\n        - yarramate/core@0.1#applicationComponent\n      statuses:\n        - planned\n        - current\n    trigger:\n      - condition: missing-relationship\n        kinds:\n          - yarramate/core@0.1#realization\n          - yarramate/core@0.1#assignment\n        direction: outgoing\n    question: >-\n      What does {subject.name} contribute?\n    materiality: >-\n      A component that realizes and performs nothing is either missing its\n      purpose links or is inventory the build does not need.\n    authority: either\n    resolution: >-\n      Add realization to the services it implements or assignment to the\n      behavior it performs, or remove it.\n\n  - id: behavior-unassigned\n    wave: application\n    since: \"0.3\"\n    scope: subject\n    subjects:\n      kinds:\n        - yarramate/core@0.1#applicationFunction\n        - yarramate/core@0.1#applicationProcess\n      statuses:\n        - planned\n        - current\n    trigger:\n      - condition: missing-linkage\n        kinds:\n          - yarramate/core@0.1#assignment\n        direction: incoming\n        counterpartKinds:\n          - yarramate/core@0.1#applicationComponent\n          - yarramate/core@0.1#applicationCollaboration\n          - yarramate/core@0.1#applicationInterface\n    question: >-\n      Who or what performs {subject.name}?\n    materiality: >-\n      Behavior with no performer cannot be placed in any component\n      boundary; it will be implemented wherever the first builder happens\n      to put it.\n    authority: either\n    resolution: >-\n      Add assignment from the application component, collaboration, or\n      interface that performs the behavior. A business actor or role does\n      not perform application behavior: assign the actor to the business\n      process that uses it and let the application service serve that\n      process.\n  - id: no-event-declared\n    wave: application\n    since: \"1.2\"\n    scope: workspace\n    trigger:\n      - condition: no-subject-of-kind\n        kinds:\n          - yarramate/core@0.1#applicationEvent\n          - yarramate/core@0.1#businessEvent\n    question: >-\n      Nothing in this model reacts to an event. Does state change only\n      when something is called, or are there happenings the architecture\n      responds to?\n    askPlain: >-\n      Is everything here a direct request, or do things also happen on\n      their own \u2014 a message arrives, a job finishes, a threshold is\n      crossed \u2014 that the system has to react to?\n    materiality: >-\n      Whether change propagates by call or by event decides coupling,\n      ordering, and failure isolation. An event-driven seam modelled as\n      silence leaves every consumer to discover the event stream on its\n      own, and a repository full of event definitions the interview never\n      asked about reads as covered when it is absent.\n    authority: human\n    resolution: >-\n      Add the application or business events the system emits or responds\n      to and wire each with triggering from what raises it to what\n      responds. If there are genuinely none, that is a coupling decision\n      worth stating in a principle or a service description; this question\n      then stays on the agenda as the standing record that nobody has\n      declared one.\n\n  - id: event-triggers-nothing\n    wave: application\n    since: \"0.3\"\n    scope: subject\n    subjects:\n      kinds:\n        - yarramate/core@0.1#applicationEvent\n        - yarramate/core@0.1#businessEvent\n    trigger:\n      - condition: missing-relationship\n        kinds:\n          - yarramate/core@0.1#triggering\n        direction: outgoing\n    question: >-\n      What responds to {subject.name}?\n    materiality: >-\n      An event that triggers nothing is either an unhandled condition \u2014\n      a real design gap \u2014 or noise; deciding which changes the build.\n    authority: either\n    resolution: >-\n      Add triggering to the responding process or function, or remove the\n      event.\n\n  - id: information-unowned\n    wave: application\n    since: \"0.3\"\n    scope: subject\n    subjects:\n      kinds:\n        - yarramate/core@0.1#dataObject\n        - yarramate/core@0.1#businessObject\n    trigger:\n      - condition: missing-claim\n        predicate: yarramate/ownership/owner\n    question: >-\n      Who is accountable for {subject.name} \u2014 its meaning, retention, and\n      access?\n    materiality: >-\n      Unowned information has no one to adjudicate schema changes,\n      retention, or access disputes; ownership is where data governance\n      starts.\n    authority: human\n    resolution: >-\n      Add an owner reference to the accountable actor.\n\n  - id: planned-design-unattested\n    wave: application\n    since: \"0.3\"\n    scope: subject\n    subjects:\n      kinds:\n        - yarramate/core@0.1#businessService\n        - yarramate/core@0.1#applicationService\n        - yarramate/core@0.1#applicationComponent\n      statuses:\n        - planned\n    trigger:\n      - condition: missing-attestation\n        topic: design-review\n    question: >-\n      Has the design of {subject.name} been reviewed before it is built?\n    materiality: >-\n      A planned element carries every unbuilt decision; a recorded\n      design-review attestation is the difference between a reviewed\n      intention and a hopeful one.\n    authority: human\n    resolution: >-\n      Review the planned element's slice, then record an attestation with\n      topic \"design-review\" (revoke by deleting it when the design\n      changes).\n\n  # ---- technology ----------------------------------------------------------\n  - id: component-unhosted\n    wave: technology\n    since: \"0.4\"\n    scope: subject\n    subjects:\n      kinds:\n        - yarramate/core@0.1#applicationComponent\n      kindMatching: exact\n      statuses:\n        - planned\n        - current\n    trigger:\n      - condition: missing-linkage\n        kinds:\n          - yarramate/core@0.1#realization\n          - yarramate/core@0.1#serving\n        direction: incoming\n        counterpartKinds:\n          - yarramate/core@0.1#node\n          - yarramate/core@0.1#device\n          - yarramate/core@0.1#systemSoftware\n          - yarramate/core@0.1#technologyService\n          - yarramate/core@0.1#artifact\n    question: >-\n      Where does {subject.name} run?\n    materiality: >-\n      The hosting boundary decides latency, failure domain, scaling\n      model, and data residency; a component with no declared runtime is\n      deployed by whoever gets there first. Matching is exact by intent:\n      profile-derived module kinds inherit their deployable parent's\n      hosting rather than answering separately.\n    authority: either\n    resolution: >-\n      Add realization or serving from the node, device, or system\n      software that hosts it, or from the technology service it runs on;\n      or add the artifact that materializes it, with realization to the\n      component and assignment from the node that deploys the artifact.\n      Technology is never assigned to a component: assignment runs from a\n      node to the artifacts and technology behavior it carries.\n  - id: node-serves-nothing\n    wave: technology\n    since: \"0.4\"\n    scope: subject\n    subjects:\n      kinds:\n        - yarramate/core@0.1#node\n        - yarramate/core@0.1#device\n        - yarramate/core@0.1#systemSoftware\n    trigger:\n      - condition: missing-relationship\n        kinds:\n          - yarramate/core@0.1#serving\n          - yarramate/core@0.1#realization\n          - yarramate/core@0.1#assignment\n        direction: outgoing\n    question: >-\n      What does {subject.name} host or serve?\n    materiality: >-\n      Declared infrastructure that serves nothing is either cost without\n      purpose or missing the links that justify it; both change the\n      deployment budget.\n    authority: either\n    resolution: >-\n      Add realization or serving to the application components it hosts,\n      or assignment to the artifacts it deploys and the technology\n      behavior it performs, or remove it.\n  - id: technology-service-unrealized\n    wave: technology\n    since: \"0.4\"\n    scope: subject\n    subjects:\n      kinds:\n        - yarramate/core@0.1#technologyService\n      statuses:\n        - planned\n        - current\n    trigger:\n      - condition: missing-linkage\n        kinds:\n          - yarramate/core@0.1#realization\n        direction: incoming\n        counterpartKinds:\n          - yarramate/core@0.1#node\n          - yarramate/core@0.1#systemSoftware\n          - yarramate/core@0.1#technologyFunction\n          - yarramate/core@0.1#technologyProcess\n    question: >-\n      What provides {subject.name}?\n    materiality: >-\n      A technology service with no realizing node or behavior is a\n      dependency assumed rather than provided; outages and upgrades have\n      no owner in the model.\n    authority: either\n    resolution: >-\n      Add realization from the node, system software, or technology\n      behavior that provides the service.\n\n  - id: no-artifact-declared\n    wave: technology\n    since: \"1.2\"\n    scope: workspace\n    trigger:\n      - condition: no-subject-of-kind\n        kinds:\n          - yarramate/core@0.1#artifact\n    question: >-\n      No artifact is declared. What do the declared components actually\n      ship as?\n    askPlain: >-\n      When this system is deployed, what is the thing that moves \u2014 an\n      image, a package, a bundle? What are those called?\n    materiality: >-\n      Release engineering starts where a build output becomes a subject.\n      An architecture with components but no artifacts can say what should\n      exist and nothing about what is deployed, so drift between built and\n      declared has nowhere to register.\n    authority: human\n    resolution: >-\n      Add the artifacts the build produces, assignment from the node that\n      deploys each one, and realization from the artifact to the component\n      or data object it materializes.\n\n  - id: artifact-unassigned\n    wave: technology\n    since: \"0.4\"\n    scope: subject\n    subjects:\n      kinds:\n        - yarramate/core@0.1#artifact\n      kindMatching: exact\n    trigger:\n      - condition: missing-relationship\n        kinds:\n          - yarramate/core@0.1#assignment\n          - yarramate/core@0.1#realization\n        direction: any\n    question: >-\n      What deploys {subject.name}, and what does it materialize?\n    materiality: >-\n      An artifact with no deployment target and nothing it realizes is a\n      build output the architecture cannot place; release engineering\n      starts from exactly these links.\n    authority: either\n    resolution: >-\n      Add assignment from the node that deploys the artifact and\n      realization from the artifact to the component or data object it\n      materializes.\n  # ---- implementation ------------------------------------------------------\n  - id: implementation-path-missing\n    wave: implementation\n    since: \"1.2\"\n    scope: workspace\n    trigger:\n      - condition: no-subject-of-kind\n        kinds:\n          - yarramate/core@0.1#workPackage\n          - yarramate/core@0.1#deliverable\n          - yarramate/core@0.1#plateau\n    question: >-\n      No work package, deliverable, or plateau is declared. How does the\n      planned architecture become real?\n    askPlain: >-\n      Who is doing what to get from here to there? What are the packages\n      of work, and what does each one hand over?\n    materiality: >-\n      A model that names a target but no work reaching it is a wish with\n      an architecture diagram; committed work packages and their\n      deliverables are what make progress reviewable rather than\n      reported. A repository mid-migration that models none of the\n      migration is the sharpest form of the gap: the change is in the\n      tree and invisible in the model.\n    authority: human\n    resolution: >-\n      Add the work packages in flight, realization to the deliverables\n      each produces, and plateaus where an intermediate state needs a\n      name. An architecture genuinely at rest keeps this question open,\n      which is itself information: the model is saying nothing is\n      changing.\n\n  - id: workpackage-delivers-nothing\n    wave: implementation\n    since: \"0.4\"\n    scope: subject\n    subjects:\n      kinds:\n        - yarramate/core@0.1#workPackage\n    trigger:\n      - condition: missing-relationship\n        kinds:\n          - yarramate/core@0.1#realization\n          - yarramate/core@0.1#aggregation\n        direction: outgoing\n    question: >-\n      What does {subject.name} produce?\n    materiality: >-\n      Work with no deliverable cannot be accepted or declared done; the\n      deliverable link is what makes progress reviewable rather than\n      reported.\n    authority: either\n    resolution: >-\n      Add realization from the work package to its deliverables.\n\n  - id: workpackage-unassigned\n    wave: implementation\n    since: \"0.4\"\n    scope: subject\n    subjects:\n      kinds:\n        - yarramate/core@0.1#workPackage\n    trigger:\n      - condition: missing-linkage\n        kinds:\n          - yarramate/core@0.1#assignment\n        direction: incoming\n        counterpartKinds:\n          - yarramate/core@0.1#businessActor\n          - yarramate/core@0.1#businessRole\n    question: >-\n      Who is committed to {subject.name}?\n    materiality: >-\n      An unassigned work package is a plan without capacity; commitment\n      is the difference between a roadmap and a wish list.\n    authority: human\n    resolution: >-\n      Add assignment from the actor or role that owns the work.\n\n  - id: deliverable-realizes-nothing\n    wave: implementation\n    since: \"0.4\"\n    scope: subject\n    subjects:\n      kinds:\n        - yarramate/core@0.1#deliverable\n      kindMatching: exact\n    trigger:\n      - condition: missing-relationship\n        kinds:\n          - yarramate/core@0.1#realization\n        direction: outgoing\n    question: >-\n      What does {subject.name} make real?\n    materiality: >-\n      A deliverable that realizes no architecture element is effort\n      disconnected from the design; its acceptance criteria cannot be\n      stated architecturally.\n    authority: either\n    resolution: >-\n      Add realization from the deliverable to the plateau, requirement,\n      or element it brings into being.\n\n  - id: plateau-aggregates-nothing\n    wave: implementation\n    since: \"0.4\"\n    scope: subject\n    subjects:\n      kinds:\n        - yarramate/core@0.1#plateau\n    trigger:\n      - condition: missing-relationship\n        kinds:\n          - yarramate/core@0.1#aggregation\n          - yarramate/core@0.1#composition\n        direction: outgoing\n    question: >-\n      Which architecture does {subject.name} stabilize?\n    materiality: >-\n      A plateau that aggregates nothing describes no state anyone can\n      stand on; migration planning needs to know what is stable when.\n    authority: either\n    resolution: >-\n      Aggregate the elements that are current during this plateau, or use\n      architecture states instead and remove it.\n\n  - id: gap-unaddressed\n    wave: implementation\n    since: \"0.4\"\n    scope: subject\n    subjects:\n      kinds:\n        - yarramate/core@0.1#gap\n    trigger:\n      - condition: missing-relationship\n        kinds:\n          - yarramate/core@0.1#association\n        direction: any\n    question: >-\n      What closes {subject.name}?\n    materiality: >-\n      A named gap nothing addresses is a known risk with no plan; either\n      work closes it or the acceptance of it should be on record.\n    authority: human\n    resolution: >-\n      Associate the gap with the plateaus it separates and with the\n      deliverable or work package that closes it - a gap is only ever\n      associated, never realized - or associate it with the assessment\n      that records the decision to accept it.\n  # ---- hygiene -------------------------------------------------------------\n  - id: concept-isolated\n    wave: hygiene\n    since: \"0.1\"\n    scope: subject\n    subjects:\n      kinds:\n        - yarramate/core@0.1#capability\n        - yarramate/core@0.1#businessService\n        - yarramate/core@0.1#applicationService\n        - yarramate/core@0.1#applicationComponent\n        - yarramate/core@0.1#businessActor\n        - yarramate/core@0.1#dataObject\n        - yarramate/core@0.1#businessObject\n    trigger:\n      - condition: isolated\n    question: >-\n      {subject.name} relates to nothing. How does it participate in the\n      architecture \u2014 or should it be removed?\n    materiality: >-\n      An isolated concept either misses relationships the design depends on\n      or inflates the model with noise that dilutes trust.\n    authority: either\n    resolution: >-\n      Connect it with its real relationships or delete it; do not keep\n      unexplained inventory.\n\n  - id: concept-undescribed\n    wave: hygiene\n    since: \"0.1\"\n    scope: subject\n    subjects:\n      kinds:\n        - yarramate/core@0.1#businessService\n        - yarramate/core@0.1#applicationService\n        - yarramate/core@0.1#applicationComponent\n        - yarramate/core@0.1#capability\n        - yarramate/core@0.1#dataObject\n    trigger:\n      - condition: missing-claim\n        predicate: yarramate/concept/description\n    question: >-\n      What does {subject.name} mean \u2014 and what does it deliberately not\n      include?\n    materiality: >-\n      Undescribed subjects accumulate contradictory interpretations; the\n      description is where scope disputes are settled once.\n    authority: either\n    resolution: >-\n      Add a description claim stating meaning and explicit exclusions.\n\n  - id: capability-uncited\n    wave: hygiene\n    since: \"1.2\"\n    scope: subject\n    subjects:\n      kinds:\n        - yarramate/core@0.1#capability\n    trigger:\n      - condition: missing-reference\n        predicate: yarramate/reference/refers-to\n        direction: outgoing\n    question: >-\n      {subject.name} cites nothing. Where is this ability specified,\n      decided, or documented?\n    askPlain: >-\n      If someone asked where it says the system can do\n      \"{subject.name}\", what would you point at?\n    materiality: >-\n      A capability with no citation floats free of every record that\n      could confirm or correct it: an audit has nothing to grade the\n      claim against, and when its scope is disputed the dispute starts\n      from memory. The reference is where the model meets the\n      repository's own account of itself.\n    authority: either\n    resolution: >-\n      Add a references entry from the capability to the subject that\n      specifies it \u2014 the decision record, the published schema, the\n      guide that documents the journey. Model that record as a subject\n      first where it is not one yet.\n\n  - id: status-missing\n    wave: hygiene\n    since: \"0.1\"\n    scope: subject\n    subjects:\n      kinds:\n        - yarramate/core@0.1#businessService\n        - yarramate/core@0.1#applicationService\n        - yarramate/core@0.1#applicationComponent\n        - yarramate/core@0.1#capability\n    trigger:\n      - condition: missing-claim\n        predicate: yarramate/lifecycle/status\n    question: >-\n      Is {subject.name} current, planned, or retired?\n    materiality: >-\n      Lifecycle status separates the architecture that exists from the one\n      that is intended; conflating them corrupts both discovery and design.\n    authority: either\n    resolution: >-\n      Add a lifecycle status claim; planned subjects should also appear in a\n      target architecture state where states are used.\n\n  - id: subjects-near-duplicate\n    wave: hygiene\n    since: \"0.7\"\n    scope: subject\n    subjects:\n      kinds:\n        - yarramate/core@0.1#capability\n        - yarramate/core@0.1#businessService\n        - yarramate/core@0.1#applicationService\n        - yarramate/core@0.1#applicationComponent\n        - yarramate/core@0.1#businessActor\n        - yarramate/core@0.1#dataObject\n        - yarramate/core@0.1#businessObject\n    trigger:\n      - condition: near-duplicate\n    question: >-\n      {subject.name} closely resembles {counterparts}. Is this one subject\n      recorded twice, or are they genuinely different things?\n    materiality: >-\n      Identity is the first thing the model promises: one subject, one name,\n      one place to change it. Two records for one thing silently fork every\n      decision made about it, and both halves still pass check.\n    authority: human\n    resolution: >-\n      If they are the same subject, keep one and delete or retire the other,\n      moving its relationships across, and record the discarded name in the\n      survivor's aka list so the old word still finds it. If they are\n      genuinely different, say so in the model: add the counterpart's id to\n      this subject's distinctFrom list. That answer is itself a claim, so it\n      closes the question permanently and survives re-running the interview.\n      A third answer is ordinary in a repository mid-migration: they are\n      different subjects and one is taking over from the other. Record the\n      succession with supersedes, scoped where the takeover is partial\n      (ADR 0109), and record distinctFrom alongside it. Succession says what\n      the pair is to each other and distinctness is what this question asks,\n      so only the second closes it.\n\n  - id: states-undefined\n    wave: hygiene\n    since: \"0.1\"\n    scope: workspace\n    trigger:\n      - condition: no-state-defined\n    question: >-\n      Does change shape matter here \u2014 should baseline, transition, or target\n      states be declared?\n    askPlain: >-\n      Are we describing how things are, how they should become, or both?\n      If the repository already carries a migration plan or a target\n      design, that document is the answer.\n    materiality: >-\n      Without architecture states, current and target intent share one\n      undifferentiated model and comparisons are impossible. The answer is\n      often already on the record: a repository that carries its own\n      migration plan or target design in-tree has declared that change\n      shape matters, so evidence can bring this question its answer rather\n      than waiting for someone to remember it.\n    authority: human\n    resolution: >-\n      Declare architecture states and mark presence with present-in where the\n      distinction carries decisions; explicitly decline states otherwise.\n      Where in-tree documents already describe the target, model that\n      record and cite it with references from the subjects it changes, so\n      the declared states stand on evidence a reviewer can open.\n\n  - id: kind-untested\n    wave: hygiene\n    since: \"0.8\"\n    scope: subject\n    subjects:\n      kinds:\n        - yarramate/core@0.1#resource\n        - yarramate/core@0.1#businessActor\n        - yarramate/core@0.1#businessRole\n        - yarramate/core@0.1#businessCollaboration\n        - yarramate/core@0.1#businessInterface\n        - yarramate/core@0.1#applicationComponent\n        - yarramate/core@0.1#applicationCollaboration\n        - yarramate/core@0.1#applicationInterface\n        - yarramate/core@0.1#node\n        - yarramate/core@0.1#device\n        - yarramate/core@0.1#systemSoftware\n        - yarramate/core@0.1#technologyCollaboration\n        - yarramate/core@0.1#technologyInterface\n        - yarramate/core@0.1#path\n        - yarramate/core@0.1#communicationNetwork\n        - yarramate/core@0.1#equipment\n        - yarramate/core@0.1#facility\n        - yarramate/core@0.1#distributionNetwork\n    trigger:\n      - condition: unconstrained-kind\n    question: >-\n      Nothing in the model tests that {subject.name} is a structural element\n      at all: every relationship it has would be just as legal if it were\n      a service, an object, or a goal. What does it run, host, or perform?\n    askPlain: >-\n      What does {subject.name} actually do, or what runs on it? The model\n      says what it is but nothing says what it takes part in.\n    materiality: >-\n      A structural kind is a promise that something behaves through this\n      element. ArchiMate permits a different set of relationships for\n      every pair of kinds, so a subject whose relationships would all\n      survive reclassification to another aspect carries a kind no check\n      can contradict \u2014 the choice between a node, a piece of system\n      software, and an application component stops carrying information,\n      and diagrams inherit a distinction the model never made.\n    authority: either\n    resolution: >-\n      Assign {subject.name} to the behaviour it performs \u2014 the process,\n      function, or interaction it carries; an interface to the service it\n      exposes; a node to the artifacts and system software it runs; a\n      resource to the capability it supports. Assignment from an active\n      structure is the claim no behavior, object, or motivation element\n      could make in its place, so recording it makes the classification\n      falsifiable. If nothing in scope is assigned to it, reclassify it\n      to a kind that does carry a claim, or retire it with a description\n      saying why it sits outside this architecture.\n\n  - id: succession-unscoped\n    wave: hygiene\n    since: \"1.1\"\n    scope: subject\n    subjects: {}\n    trigger:\n      - condition: unscoped-succession\n    question: >-\n      {subject.name} supersedes a predecessor that is still current. In what\n      respect does it supersede it, and what remains of the predecessor?\n    askPlain: >-\n      {subject.name} takes over from something that is still here. What part\n      does it take over, and what is the old one still needed for?\n    materiality: >-\n      A succession that replaced its predecessor outright says so by the\n      predecessor being gone. One where both are still current is usually\n      partial, and the part it does not cover is exactly what a reader\n      planning against the model needs to know. An unqualified claim reads\n      as a total replacement to every surface that consumes the field, and\n      `ask --compare` reads the field rather than the prose beside it, so a\n      partial succession recorded without its scope turns into a declared\n      removal of something nobody is removing.\n    authority: either\n    resolution: >-\n      Record the respect on the succession entry:\n      `supersedes: [{ subject: <predecessor>, inRespectOf: <the part taken\n      over> }]`. If the succession really is total, retire the predecessor,\n      which says the same thing without a qualifier. If the two subjects\n      simply coexist and neither takes over from the other, the succession\n      is the wrong claim; remove it.\n\n  - id: evidence-unchallenged\n    wave: hygiene\n    since: \"1.2\"\n    scope: workspace\n    trigger:\n      - condition: unchallenged-evidence\n    question: >-\n      Every observation this workspace records is a frictionless\n      confirmation. Did the inspection ever test a claim it might fail?\n    askPlain: >-\n      The evidence agrees with the model everywhere. Did we ever look\n      for something that might not be there \u2014 a documented piece missing\n      from the tree, a declared dependency nothing carries?\n    materiality: >-\n      An overlay that only ever says confirmed is indistinguishable from\n      one that only looked where success was guaranteed. One recorded\n      search or one honest non-confirmation is what makes the agreement\n      between model and reality worth believing; a reconcile summary of\n      pure confirmations has never put a claim at risk.\n    authority: either\n    resolution: >-\n      Probe at least one claim the sources assert that the tree might not\n      honour, and record the observation with its honest result. A\n      not-observed carries the searches that came back empty (ADR 0107);\n      a confirmed negative claim carries them too, because the empty\n      search is the confirmation. Either closes this.\n";