DragonPay Guardrail Catalog¶

Engineering Foundation · Working Draft · Working Draft v5 · Updated September 3, 2026

This document is the sole authoritative source for individual ENG Mode guardrail definitions and their evaluation checks. ENG-02 §19 defines the framework — how these guardrails are loaded, evaluated, surfaced, reviewed, and reconciled; this catalog defines which guardrails currently exist. Adding or refining a guardrail here is normally a PM Mode Product-catalog change, not a change to ENG-02 or a reimplementation of ENG02-21 — as long as the framework already supports the guardrail's Applies To/Enforcement Type shape.

GR-NNN is a separate, non-requirement numbering scheme — it deliberately does not follow the {PREFIX}{EPIC}-{ITEM} requirement-ID format described in ENG-02 §2, and is not indexed as a requirement by dp-eng's Product indexer.

Field schema¶

Field	Required meaning
ID	Stable guardrail identifier, e.g. `GR-001`. Once published, an ID's semantics do not change; a material replacement uses a new ID.
Name	Short human-readable guardrail name.
Applies To	`PM`, `ENG`, `ADMIN`, `ALL`, or multiple named modes.
Rule	The authoritative guardrail behavior.
Applies When	Conditions/scenarios in which the rule is relevant.
Evaluation Check	Question/check used by planning, critic, or mode-specific review to detect a violation.
Enforcement Type	`EVALUATIVE` (requires model/human judgment), `DETERMINISTIC` (mechanically checkable), or `BOTH`.

Optional concise rationale/examples may be included when they materially improve interpretation, but they are not authority to create additional semantics beyond the Rule.

Mode-aware loading¶

ENG Mode / Admin Mode read this catalog through the Development repository's pinned Product baseline (dp-eng), never live Product HEAD — the same invariant ENG-02 §11 locks in for every other Product artifact.
PM Mode reads this catalog directly against the Product repository it is authoring, since no baseline-pinning relationship applies when PM Mode is the authoritative source.
No catalog entry is enforced purely deterministically in V1. Deterministic enforcement in V1 applies to the framework-level plan-review precondition and plan-structure validation described in ENG02-21, not to individual guardrail rules below, which remain evaluative (judgment-based) even where a partial deterministic backstop may exist.

Guardrails¶

GR-001 — Later-Story Scope Protection¶

Applies To: ENG

Rule: Do not implement functionality owned by another requirement merely because it would simplify or complete current work.

Applies When: Requirement-scoped planning/implementation approaches capability assigned to later Product/Foundation work.

Evaluation Check: Is any proposed behavior owned by another requirement? If yes, is it truly required as a minimal prerequisite now, and is the remainder explicitly deferred?

Enforcement Type: EVALUATIVE

GR-002 — Material Assumption Disclosure¶

Applies To: ENG

Rule: Material undocumented assumptions must be surfaced for human review before being encoded; routine local reversible choices may proceed.

Applies When: Implementation requires a choice not established by Product, applicable STD/ENG, approved ADR, or authoritative contract.

Evaluation Check: What material choice is being made, what authority was checked, and what happens if the assumption is wrong?

Enforcement Type: EVALUATIVE

GR-003 — Examples Are Not Authority¶

Applies To: ENG, PM

Rule: Examples, placeholders, legacy artifacts, existing files/code, and historical artifacts are not authority to create undefined Product or engineering semantics.

Applies When: Concrete artifacts appear to imply behavior not explicitly established by authoritative context.

Evaluation Check: Is the plan formalizing semantics merely because an example or existing implementation contains them?

Enforcement Type: EVALUATIVE

GR-004 — Existing-Model Consistency¶

Applies To: ENG

Rule: Do not create a parallel durable representation for a concept that already has an authoritative representation unless both are explicitly required and their relationship is defined.

Applies When: Adding persistent fields/entities/states/events/interfaces/evidence or another durable representation.

Evaluation Check: Does an authoritative representation already exist? Would this create a competing source of truth?

Enforcement Type: EVALUATIVE

GR-005 — Default Truthfulness and Absence Semantics¶

Applies To: ENG, ADMIN

Rule: Do not interpret missing data/artifacts as a default state unless authoritative context establishes that absence is semantically equivalent to that default.

Applies When: A missing manifest/value/event/response/evidence is being mapped to a state or conclusion.

Evaluation Check: Could the default contradict known history/current facts? Is absence explicitly defined to mean this state?

Enforcement Type: EVALUATIVE

GR-006 — State and Evidence Consistency¶

Applies To: ENG

Rule: When state or behavior is derived from multiple inputs, identify material invariants and do not silently normalize contradictory evidence or invent precedence. Evidence establishes only what its provenance actually proves — a historical mapping or prior association must not be treated as proof of current state without applying the applicable current-state/evolution rule. Deduplication or normalization must not erase a materially distinct classification, relationship, or protection signal.

Applies When: Lifecycle/state/evidence derivation or validation combines multiple sources/facts.

Evaluation Check: Can inputs contradict each other? If so, is authoritative rejection/unknown/precedence behavior defined? Does a fact's provenance actually prove what it's being used to prove — especially current state versus a historical/prior record? Could deduplication or normalization have erased a distinct classification, relationship, or protection signal?

Enforcement Type: EVALUATIVE

GR-007 — Semantic Sufficiency¶

Applies To: ENG, PM

Rule: Do not claim a weaker, partial, related, or structurally similar capability satisfies a stronger requirement — including by disclosing the reduction as an assumption or interpretation rather than implementing what the requirement actually specifies. Disclosure does not convert non-conformance into conformance; if narrower behavior is intentionally proposed, surface it through the applicable Product/decision pathway rather than claim conformance. Whether the resulting discrepancy materially blocks affected work is GR-010's separate question; GR-002 covers only cases where the authoritative requirement genuinely does not specify the answer, not cases where it does and a narrower implementation was chosen instead.

Applies When: Evaluating requirement/acceptance coverage using existing capabilities.

Evaluation Check: Does the implementation provide the actual semantic guarantee required, or merely something close to it? If a limitation is disclosed as an assumption, does the underlying capability still fall short of a stronger authoritative requirement — as opposed to an undocumented engineering detail GR-002 already covers?

Enforcement Type: EVALUATIVE

GR-008 — Plan Internal Consistency¶

Applies To: ENG

Rule: Every planned operation must have an identified source for every required input; do not rely on unstated ambient context unless already an engineering contract.

Applies When: Plan introduces functions/modules/control flow/interfaces or filesystem/repository behavior.

Evaluation Check: Does every step receive what it needs? Is anything coming implicitly from cwd, environment, globals, or an undeclared source?

Enforcement Type: EVALUATIVE

GR-009 — Prerequisite Integrity¶

Applies To: ENG, ADMIN

Rule: Dependent processing must not produce authoritative or misleading results when its prerequisite data/model cannot be established reliably.

Applies When: Validation/processing/derivation depends on an earlier representation, lookup, or validation result.

Evaluation Check: What happens when the prerequisite fails? Could continuation create misleading secondary findings or state?

Enforcement Type: EVALUATIVE

GR-010 — Material-Risk Scoped Blocking¶

Applies To: ENG, PM

Rule: Uncertainty or incompleteness alone does not cause blocking. Block only affected work — or, in PM Mode, classify a finding as blocking — when proceeding under the unresolved condition could materially compromise correctness, Product intent, security/authorization, financial behavior, persistent data integrity, external contracts, or create a difficult-to-reverse shared decision. In PM Mode, evaluate this against the Product capability and delivery scope actually being prepared for implementation: a future or explicitly deferred capability does not block current readiness merely because its eventual integration is not yet fully designed — only when leaving it unresolved would make the current implementation materially incorrect, unsafe, contradictory, or hard to reverse.

Applies When: A material issue or undocumented decision remains unresolved during ENG planning/implementation, or is identified during a PM Mode readiness review.

Evaluation Check: Can affected work proceed safely, or is the current Product readiness genuinely compromised? If not, what exact scope is blocked while unrelated work continues? For a finding about a future/deferred capability: would leaving it unresolved make the current delivery scope materially incorrect, unsafe, contradictory, or hard to reverse — or does it only affect a phase not yet being implemented?

Enforcement Type: EVALUATIVE

GR-011 — Plan Approval Does Not Authorize New Assumptions¶

Applies To: ENG

Rule: If implementation exposes a new material assumption or materially changes expected impact after plan approval, surface it before encoding it when proceeding would create material risk.

Applies When: Implementation reveals information/impact not present in approved plan.

Evaluation Check: Is this a new material decision? Was it disclosed in the approved plan? Must affected work stop for review?

Enforcement Type: EVALUATIVE

GR-012 — Scenario Viability¶

Applies To: ENG

Rule: Before approval, walk the proposed design through the actual normal workflow from entry to completion — including whether a required protection can be bypassed on that path (GR-022) — plus at least one relevant failure/mutation/retry/refactor/stale-state/partial-completion scenario, checking whether missing/invalid/partial evidence could produce a misleading conclusion and whether a realistic state change causes the mechanism to stop accomplishing its intended purpose.

Applies When: Substantive implementation planning.

Evaluation Check: Does the design still work step-by-step under a realistic non-happy-path scenario, including whether missing/invalid/partial evidence could produce a misleading conclusion and whether a realistic state change causes the mechanism to stop accomplishing its purpose? Walking the normal path is where a GR-022 violation (a bypassable required control) would surface — evaluate GR-022 directly rather than re-deriving it here.

Enforcement Type: EVALUATIVE

GR-013 — Mode Authority Boundary¶

Applies To: ALL

Rule: Claude must not autonomously cross operating-mode authority boundaries during an active action.

Applies When: A task exposes work controlled by another operating mode.

Evaluation Check: Does the next action require a different mode? If so, surface/recommend it but do not silently switch and act.

Enforcement Type: EVALUATIVE for V1 — no confirmed safe deterministic mode-aware enforcement mechanism currently exists (no native "current DragonPay mode" signal a hook/permission rule can query). May become BOTH through a future PM Mode catalog update if ENG implementation later establishes a real deterministic backstop.

GR-014 — Truthful Reporting¶

Applies To: ALL

Rule: Do not knowingly present an approximation, guess, or unavailable fact as authoritative merely to produce a complete-looking result.

Applies When: Authoritative data/decision/evidence is missing or ambiguous.

Evaluation Check: Is the reported conclusion actually established, or is uncertainty being hidden?

Enforcement Type: EVALUATIVE

GR-015 — Product Change Scope Discipline¶

Applies To: PM

Rule: A proposed Product change must not silently grow beyond what was actually requested.

Applies When: Drafting or revising a meaning-changing Product update.

Evaluation Check: Does every part of the proposed diff trace back to what was actually asked for? Is anything present merely because it seemed like a good addition while there?

Enforcement Type: EVALUATIVE

GR-016 — Epic Consistency¶

Applies To: PM

Rule: A proposed change must remain consistent with its containing epic's own established requirements.

Applies When: A change touches or is adjacent to other requirements within the same epic document.

Evaluation Check: Does the change contradict, duplicate, or quietly reinterpret anything else already established in the same epic?

Enforcement Type: EVALUATIVE

GR-017 — Cross-Requirement Conflict¶

Applies To: PM

Rule: A proposed change must not conflict with another requirement or standard elsewhere in the Product repository.

Applies When: A change's behavior overlaps with a requirement or standard outside its own containing epic.

Evaluation Check: Does this change contradict an existing requirement/standard elsewhere in the repository? Has that document been checked, not just the one being edited?

Enforcement Type: EVALUATIVE

GR-018 — Requirement Ownership / Duplication¶

Applies To: PM

Rule: A proposed change must not create unclear ownership of a concept, or a duplicate of an existing requirement.

Applies When: A change introduces new requirement content, or content that resembles something already documented elsewhere.

Evaluation Check: Is it clear which single requirement owns this concept afterward? Does this duplicate something that already exists under a different ID?

Enforcement Type: EVALUATIVE

GR-019 — Released History Preservation¶

Applies To: PM

Rule: A proposed change must not silently invalidate released-requirement history it should instead extend via modifies/supersedes/retires.

Applies When: A change affects a requirement that has already reached RELEASED/ESTABLISHED status or otherwise has recorded history.

Evaluation Check: Does this change rewrite history in place, or does it correctly extend it through the relationship metadata (§5)?

Enforcement Type: EVALUATIVE

GR-020 — Implementation Detail Leakage¶

Applies To: PM

Rule: Implementation detail must not leak into Product-level requirement text — at the level of a single requirement, or an entire story. A PRODUCT-class story must primarily define a Product capability, business/domain behavior, domain invariant, externally meaningful outcome, or necessary cross-capability contract; implementation architecture, technology integration, deployment mechanics, persistence strategy, framework configuration, or worker/runtime behavior belongs in Engineering/Foundation unless a concrete Product, regulatory, security, or operational requirement makes that characteristic itself necessary. Domain invariants that happen to constrain engineering — payment idempotency, tenant isolation, uncertain-outcome safety, durable business behavior, payment identity/relationships, custody boundaries, and the like — remain valid Product requirements; this guardrail does not reach them.

Applies When: Drafting or revising requirement text that could plausibly describe a specific technical mechanism instead of the Product-level behavior, or categorizing/reviewing a story as PRODUCT-class.

Evaluation Check: Does this text describe what DragonPay must do, or does it quietly prescribe how engineering must build it? For a whole story: could DragonPay use a materially different implementation and still produce the intended Product behavior correctly? If yes, the implementation-specific detail generally does not belong in the Product requirement.

Enforcement Type: EVALUATIVE

GR-021 — Product Acceptance-Criteria Completeness¶

Applies To: PM

Rule: A proposed change's acceptance criteria must actually be complete for the behavior being specified, not merely plausible-looking. Distinct from GR-007 (Semantic Sufficiency), which evaluates whether an implementation satisfies a requirement — this evaluates whether the requirement itself is fully specified.

Applies When: Drafting or revising a requirement's acceptance criteria.

Evaluation Check: If every listed acceptance criterion were met exactly, would the requirement's actual intent be satisfied — or is there a gap the criteria don't cover?

Enforcement Type: EVALUATIVE

GR-022 — Mandatory Control Integration / Bypassability¶

Applies To: ALL

Rule: A required validation, protection, review, or gating behavior is not satisfied merely because a callable or manual mechanism for it exists. If normal workflow execution can bypass the control and reach the behavior the control is meant to protect, the implementation is incomplete. A required control must be integrated into the applicable workflow path, or otherwise reliably invoked at the point it becomes necessary.

Applies When: Implementation introduces or relies on a validation, protection, review, or gating mechanism intended to be required, mandatory, or protective.

Evaluation Check: Is invocation of this control structurally guaranteed by the design (a required step in a workflow/Skill, a hook, a deterministic check) — or does it depend on someone remembering to invoke an available-but-optional mechanism? Could the design's own normal path complete without ever exercising the control?

Enforcement Type: EVALUATIVE

GR-023 — Minimum Necessary Specification¶

Applies To: ENG, PM

Rule: A Product requirement must specify only the behavior and constraints necessary to implement the intended Product correctly and prevent material incorrect behavior; an ENG Mode implementation built against it must build only the mechanism necessary to satisfy that requirement and applicable Engineering standards. If the required Product outcome and material constraints are already stated, the absence of downstream implementation detail, technical mechanism, or exhaustive edge-case behavior is not itself a Product defect. A readiness correction must not introduce a new state model, event taxonomy, cardinality/exclusivity rule, generalized framework, interface, or implementation mechanism unless it is the minimum necessary correction for an identified material Product defect; an ENG Mode implementation must not introduce a durable state model, event taxonomy, cardinality/exclusivity rule, or generalized framework, in each case beyond what the current requirement needs. When an established industry/software/payments pattern already satisfies the need, use that pattern rather than designing a DragonPay-specific generalized framework without a demonstrated business need.

Applies When: Drafting a Product requirement; proposing a Product Critic finding/correction during readiness review; or making an ENG Mode implementation decision on a mechanism the current Product requirement does not fully specify.

Evaluation Check: What current Product behavior or concrete failure requires this additional rule or mechanism? If the only justification is future flexibility, theoretical completeness, architectural neatness, possible future Products, or eliminating ordinary engineering/Product judgment, it is not a defect and the requirement/finding/mechanism must not be added. Does the proposed correction go beyond the minimum necessary fix for an identified material defect — or, in ENG Mode, does the implementation introduce a new durable state model, event taxonomy, cardinality/exclusivity rule, or generalized framework beyond what the current requirement needs?

Enforcement Type: EVALUATIVE