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