# Tradon Exposure Assessments This folder documents the exposure of target accounting reports to TradOn capabilities. TradOn is the project-specific customized version of Tryton and is the selected CTRM / ERP platform from which these reports are intended to run. The purpose is to keep report specifications in `Reports/` clean and stable, while documenting separately: - coverage identified in Tryton and TradOn; - functional or technical gaps; - mapping assumptions; - open questions and recommended answers; - decisions taken after review. ## Scope and limits The current assessments are based on external analysis documents and available documentation. They should not be read as direct validation of the live TradOn implementation unless this is explicitly stated in the relevant assessment. For GL-001, the source analysis refers to Tryton / TradOn source files, but the current repository does not include that code. The assessment therefore preserves the evidence and conclusions as documented in the external GAP analysis. Implementation choices are made per report. For example, a report may use a selected open-source component integrated into TradOn, or require a TradOn customization. These choices belong in the report's `decision_register.md`. ## Structure Each exposed report should have its own folder: ```text Assessments/ Tradon/ / source_documents/ exposure_notes.md gap_mapping.md decision_register.md source_material.md ``` ## Source material intake Initial GAP analysis files for each report are received in the repository root folder `Tradon/`. These files may be pushed by another Git user and should be treated as incoming source material. When an assessment is created or refreshed on request, copy the relevant GAP analysis file from `Tradon/` into the assessment folder under: ```text Assessments/Tradon//source_documents/ ``` The assessment process does not change after intake: use the copied repository source as the retained evidence, document traceability in `source_material.md`, and keep the analysis outputs in the assessment files. ## File roles | File | Role | | --- | --- | | `exposure_notes.md` | Narrative summary of the exposure and main conclusions | | `gap_mapping.md` | Structured gap mapping by functional area | | `decision_register.md` | Single source of truth for open questions, recommended answers, decisions, backlog blockers and validation expectations | | `source_material.md` | Source documents, date, scope and traceability notes | ## Decision register Open questions and answers must be written in `decision_register.md`, except when the user explicitly asks to handle them elsewhere. The register should contain: - a quick answer board listing each question, recommended answer, blocking backlog item and status; - confirmed decisions; - a detailed section for each question with options, decision, rationale, impact and validation. Recommended question detail format: | Field | Meaning | | --- | --- | | `Status` | `Open`, `Confirmed`, `Not blocking`, `Deferred` or another explicit assessment status | | `Area` | Functional or technical area | | `Blocks` | Backlog item IDs blocked by the question, or `Not blocking` | | `Question` | The business, mapping or architecture question to answer | | `Recommended answer` | Assistant or reviewer proposal for arbitration | | `Options` | Practical choices available to the user | | `Decision` | Confirmed answer once arbitrated | | `Rationale` | Why the answer was selected | | `Impact` | Documentation, reporting or implementation impact | | `Validation` | Review, reconciliation or sample check expected | Use stable IDs in the form `-Q###`, for example `GL001-Q016`. After a document review, any new framing question should be added to `decision_register.md`, unless an explicit exception is requested. When a decision is confirmed, update the linked backlog items according to the development readiness rule. ## Recommended statuses | Status | Meaning | | --- | --- | | `Open` | Gap, question or mapping still to be reviewed | | `Confirmed` | Interpretation confirmed by source evidence or stakeholder review | | `Accepted Gap` | Gap accepted without immediate change | | `Requires Change` | Report specification or implementation must be adjusted | | `Out of Scope` | Item acknowledged but excluded from the current scope | ## Documentation principle `Reports/` remains the target functional specification. `Assessments/Tradon/` documents the comparison with TradOn, including its Tryton baseline, and should not silently redefine the target report. Any change to a report specification should be made explicitly in the relevant `Reports/` file and, where useful, recorded in the assessment `decision_register.md`.