Engineering Start Here¶
DragonPay is a payment hub letting credit unions offer modern payment products through their existing digital banking, starting with Person-to-Person payments. Product documentation defines the required domain behavior, interfaces, stories, and acceptance criteria; Engineering documentation defines how those requirements are implemented and traced into working software.
This page is the entry point into that documentation. It routes you to the authoritative source — it does not repeat it.
Documentation Authority¶
Product documentation (PH, PP, CX, OX, CI, and other Product requirement documents) is authoritative for what DragonPay must do. Engineering must not silently alter Product requirements, behavior, terminology, interfaces, or acceptance criteria — a needed Product change goes through the Product-change process, not code or Engineering docs alone.
Engineering documentation (ENG-01, ENG-02, and the Engineering Architecture pages) is authoritative for how DragonPay implements those requirements — traceability, implementation status, and technical architecture. It may reference Product requirements but doesn't duplicate them.
The Decision Register tracks open, proposed,
decided, and deferred cross-cutting engineering questions, with an
Immediate Open Decisions view for what
needs near-term attention. It is a coordination/visibility tool, not
authoritative — a DECIDED item points to the actual authoritative
outcome (resolution_ref / adr_ref); it does not replace it. An OPEN
or PROPOSED decision is not an answer you can assume — see Engineering
Decisions below.
ADRs preserve the rationale for consequential accepted decisions when one is warranted; not every choice needs one, and the Register and ADR mechanism are related but separate.
For Product requirements (PH/PP/CX/OX/CI), what's actually implemented, verified, or released is determined only by ENG-02 §7's traceability model — never by documentation prose or task-tracking state alone. No dedicated MkDocs status/traceability page exists yet; ENG-02 §7 is the authoritative source directly.
Where to Start¶
| If you need to... | Start with |
|---|---|
| Understand DragonPay at a high level | Product Overview |
| Understand the engineering workflow and implementation rules | ENG-02 |
| Implement a Product story | The specific Product requirement + ENG-02 |
| Work on an Engineering/Foundation capability | ENG-01 + ENG-02 |
| Understand the logical system structure | Architecture at a Glance |
| See unresolved decisions needing attention soon | Immediate Open Decisions |
| Review all engineering decisions | Decision Register |
| Understand why a consequential choice was made | ADR index |
| See what's actually implemented, verified, or released (Product requirements) | ENG-02 §7 |
| See current engineering execution work | Jira — pending configuration |
Product to Implementation Flow¶
Informally, work moves through:
Product Requirement → Engineering Context / Applicable Decisions → Implementation + Tests → Commit → Implemented → Verified → Released
The Product requirement ID is the durable link between the requirement and its implementation throughout this flow. Only the three bolded terminal states are ENG-02 §7's authoritative vocabulary for Product requirements; the earlier steps are plain description, not a separate formal lifecycle.
Engineering Decisions¶
Before implementing work that depends on an engineering choice:
- Check the applicable engineering context (ENG-01/ENG-02 or the relevant Architecture page).
- Check the Decision Register.
- Check Immediate Open Decisions when relevant.
- If a decision your work depends on is OPEN or PROPOSED, do not silently choose an implementation — surface or resolve it through the existing decision process. A PROPOSED item's direction is guidance, not an answer.
- Once a decision is DECIDED, use it as implementation context.
required_by names the requirement/area a Register question relates to.
needed_imminently marks whether it currently needs near-term
attention — it's independent of whether a decision is safe to leave
unresolved (step 4 applies to any OPEN or PROPOSED decision your work
depends on, regardless of this flag) and is what the Immediate Open
Decisions view filters on. Both fields are defined in full in ENG-02
§15 (ENG02-25) — not restated here.
Jira¶
Jira is DragonPay's non-authoritative engineering execution tool: backlog, current sprint, assignees, blockers, bugs, and technical tasks. It does not replace Product requirements or acceptance criteria, the Decision Register, ADRs, ENG-02 traceability, or authoritative implementation status.
Jira project/link pending configuration.
AI-Assisted Development / Claude¶
- Product documentation is the authority for required behavior; Engineering documentation provides implementation context.
- The Decision Register records which engineering questions are open, proposed, decided, or deferred — a previously discussed candidate or reference-system technology is not a DragonPay decision until it's DECIDED there.
- Don't silently resolve an OPEN or PROPOSED decision while implementing unrelated work.
- Generated code is held to the same testing, review, and traceability bar as human-written code.
- If Product requirements and an Engineering implementation assumption conflict, surface the conflict rather than silently reconciling it.