1. System context and trust boundaries
One central web application used by ship crews and shore staff of one company (ADR-01, ADR-02). Users reach it over the internet with TLS; the hosting party runs the infrastructure but has no business role; a company-held anchor store sits outside the hosting party's reach so that log tampering is detectable.
Core componentProvisionalOptionalExternal or platformControl or decision point— solid arrow: synchronous call · - - dashed: asynchronous or worker · ··· dotted: optional
Trust boundaries
| Boundary | Between | Controls |
|---|---|---|
| TB-1 Internet | Browsers on ship and shore networks, and phones; the application | TLS only; authentication on every function (NFR-PMS-016); rate limits on sign-in; MFA for administrators and shore approvers |
| TB-2 Vessel | One vessel's data and another's | Vessel scope checked on every request, list, report and export (ENG-14); composite foreign keys; row-level security as a second line (ADR-06) |
| TB-3 Application administrator | Web administrator and operational users | Separate system roles; administrators do not approve maintenance; every administrator action in the security log (ENG-34) |
| TB-4 Hosting | The application and whoever operates the database and hosts | No application function can alter logs; database roles without UPDATE or DELETE on log tables; the anchor held by the company detects alteration of anchored entries by anyone with database access (ADR-11; UD-22, UD-23) |
| TB-5 Company-held anchor | The hosting party and the company | The anchor store is outside the hosting party's control (FQ-23) |
| TB-6 Environments | Production and verification or development | No production credentials, data or channels in other environments unless Q-38's conditions are met (testing policy §12) |
Users
| User (position or role) | Where | Main tasks | Evidence |
|---|---|---|---|
| Engine officers (2/E, 3/E, 4/E, E/L) and deck officers (C/O, 2/O, 3/O), as P.I.C. | Ship; desktop; phone for photographs | See their due work; record completions with evidence; enter running hours | DATA-PMS-006; Q-04 b; Q-37 a; journeys J1–J3 |
| Chief Engineer (and Master for deck work, UD-11) | Ship; desktop | First approval level; review the vessel's plan; request extensions; propose task changes | Q-14 b, Q-17 b; FQ-28 |
| Shore department head (technical superintendent) | Office; desktop | Second approval level for the vessels in scope; fleet overview | Q-14 b ("trưởng bộ phận") |
| Final approver | Office; desktop | Last approval level | Q-14 b, Q-17 b |
| Web administrator | Office (company and/or delivery side, UD-12) | Vessels, users, positions and assignments; configuration; import; read-only access to the audit and security logs; exports on company request | Owner decisions 4, 6; NK-4, NK-6 |
| Company log requester | Company | Asks for log or full-data exports | Owner decision 4; NK-4 b blank (UD-12) |
| Hosting operator | Outside the application | Runs the infrastructure and database backups; has no business role in the application | ENG-34; R-009 |
2. Application architecture
A modular monolith: one codebase, a web process and a background worker, one PostgreSQL database and one object store (ADR-03, ADR-04). Arrows point from a module to the module it depends on. Optional and provisional modules depend on the core, never the reverse (NFR-PMS-011).
Core componentProvisionalOptionalExternal or platformControl or decision point— solid arrow: synchronous call · - - dashed: asynchronous or worker · ··· dotted: optional
Modules
| Module | Responsibility | Owns (section 5) | Depends on | Status |
|---|---|---|---|---|
| M01 Identity and access | Sign-in, MFA, sessions, accounts, positions, assignments, roles, permissions, scope evaluation | Area A | M12 | Core |
| M02 Organisation | Company, vessels, departments | Company, Vessel, Department | M12 | Core |
| M03 Equipment and plan | Equipment tree, groups, tasks, limits, task changes, templates link | Area B | M02, M01, M07 | Core |
| M04 Running hours | Counters, readings, counter events, rate estimation | RunningHourCounter, CounterReading, CounterEvent | M03, M07 | Core |
| M05 Scheduling engine | The one definition of due points and statuses (NFR-PMS-010); policy versions; schedule projection; warning stages | SchedulingPolicy, TaskScheduleState | M03, M04 (read interfaces). The last closed execution and any active extension are passed in by M06 when it calls M05, so there is no cycle | Core; rules pending signed examples |
| M06 Work execution | Work orders, execution data, extension requests, risk assessments, corrections | WorkOrder, DueExtension, RiskAssessment, CorrectionRequest | M03, M04, M05, M07, M09 | Core |
| M07 Approval workflow | Chain definitions and versions; approval requests and decisions; separation-of-duties rules | ApprovalChain, ApprovalStep, ApprovalRequest, ApprovalDecision | M01 | Core |
| M08 Monitoring and reports | Monitoring view, in-app staged warnings, monthly plan, history, uncompleted and overdue list, Form M008 for all groups (RPT-PMS-001 to 003, 010, 011); the further documented report groups (overdue analysis, critical, KPI; RPT-PMS-004 to 009) later | ExportRecord (reads others) | M05, M06, M01 | Core |
| M09 Files | Upload checks, storage, authorised download, links | StoredFile, AttachmentLink | M01 | Core |
| M10 Import | Workbook parsing, validation-only runs, mapping, complete-or-nothing load, reversal, provenance | ImportBatch, ImportIssue | M02, M03, M04, M06, M09 | Core |
| M11 Audit and security log | Log writer function, chains, anchors, integrity checks, log viewer, log export | Area H | — (lowest layer) | Core |
| M12 Configuration | Module switches, value lists, i18n resources, settings | ModuleSetting, ValueListItem | M11 | Core |
| M13 Defects and unplanned work | Optional module | Defect | M06 | Optional |
| M14 Event-based maintenance | Optional module | MaintenanceEvent, EVENT limits | M03, M05 | Optional |
| M15 Notifications | Optional e-mail module | NotificationMessage | M05, M01 | Optional |
| M16 Documents | Optional controlled documents | ControlledDocument, DocumentRevision | M09, M07 | Optional |
| M17 Materials and stores | Provisional module | Area F | M06 (work-order interface only), M07 | Provisional |
Data flows
| Flow | Path | Transaction and integrity |
|---|---|---|
| FL-1 Interactive command (for example, submit a completion) | Browser → TLS → web process → application service (authorise, check scope, validate, idempotency key) → database transaction (business rows + audit entries by trigger) → response | One transaction per user action; a retry with the same key returns the first result (NFR-PMS-022, 026) |
| FL-2 Query (monitoring view) | Browser → web process → read model (tasks, schedule projection, open work orders, counter values) filtered by scope → status evaluated by M05 for today's vessel date | No writes; nothing to audit |
| FL-3 File upload | Phone or desktop → web process (type and size check, fingerprint, optional scan) → object storage (private bucket, content-addressed key) → StoredFile + AttachmentLink in the database | File stored before the database commit; an orphaned object (commit failed) is reported by a sweep and kept, never served (no deletion, IN-13) |
| FL-4 File download | Browser → web process (entitlement to the owning record) → short-lived signed URL or streamed response → security event | No direct public object URLs |
| FL-5 Reading entry | Browser → M04 (validation BR-PMS-017, confirmation step) → CounterReading → M05 recompute for the tasks on that counter → TaskScheduleState | One transaction; at most a few hundred tasks per counter |
| FL-6 Approval | Approver → M07 (position held, scope, separation of duties) → ApprovalDecision → subject transition; on the final step M06 closes the work order and M05 recomputes the task | One transaction |
| FL-7 Import | Administrator uploads workbook → StoredFile → M10 parse (no macros, no recalculation) → staging → validation-only report (ImportIssue) → sign-off → load as one transaction → provenance and one creation entry per record (P-19) | Complete-or-nothing (NFR-PMS-030); reversal (NFR-PMS-031) |
| FL-8 Export | User or administrator → M08 query within scope → file → StoredFile + ExportRecord (manifest) → security event → download | Log and full-data exports require a company request reference (owner decision 4) |
| FL-9 Audit capture | Every write to an audited table → database trigger → log writer function → AuditEntry (chain head locked, hash computed) | Same transaction as the change (P-17) |
| FL-10 Log protection | Worker, hourly → copies new log entries as signed segments to versioned object storage; daily → IntegrityAnchor to the company-held store; daily → full chain verification → security event | Detects alteration, removal, insertion and gaps (AC-5) |
| FL-11 Backup | Database write-ahead log streamed continuously to backup storage; daily base backup; object storage versioning and replication | Point-in-time recovery (R2) |
| FL-12 Operational logs | Web and worker processes → structured lines to the platform log collector → bounded retention | No business values, no secrets (ENG-26) |
| FL-13 Optional notification | Worker → NotificationMessage → e-mail relay | Only with M15 enabled |
Devices and tasks
| Device | Tasks | Evidence | Status |
|---|---|---|---|
| Desktop or laptop browser, ship and shore | All functions: monitoring, recording, approvals, planning, reports, administration | Q-37 a ("chỉ trên máy tính") | INPUT |
| Phone browser (no app) | Take and attach photographs to an open work order (J2); view "my open work orders"; possibly enter a reading ("các thao tác dùng điện thoại") | Q-37 a; Q-33 | Photo capture INPUT; other phone tasks TA (UX-G1) |
| Tablet | Same as desktop, responsive | — | Not stated; supported by responsive layout |
3. Entity relationship model
56 entities in 8 subject areas (36 core, 14 provisional, 5 optional module, 1 derived) and 97 relationships. Generated from the same model file as section 5 of the proposal. Choose an area, then select an entity for its keys, attributes, constraints, lifecycle, audit relevance and evidence. Actor columns (…_by → UserAccount) are listed in the boxes but drawn only where UserAccount appears.
Select an entity in a diagram, or a name in the overview, to open its details. Press Escape to close them.
CoreProvisionalOptional moduleDerived (recomputable)Entity of another area (click to open)Crow's foot: ┤├ exactly one · o┤ zero or one · o< zero or many · ┤< one or many (symbol next to an entity = how many of it per one of the other)
Provisional relationships and entities
| Item | Why provisional | Decided by | Effect if it changes |
|---|---|---|---|
| GROUP 0 mapping (task → equipment) | 2a or 2b (OD-2, UI-10) | Owner (UD-10) | Import mapping only; schema unchanged |
| Job key (vessel, group, job code) | Q-11 b "likely unique vessel-wide" conflicts with the files (317 codes repeat across sheets) | Owner, then company (FQ-08) | A unique index changes |
TaskTemplate link | T2 staged (IB-16) | Owner | Template maintenance added later |
CounterEvent, reading entry_form | Q-04 b, c unclear | Company (FQ-04) | Input format and procedure only |
DueExtension effect and limits | FQ-10 | Company | Policy parameters |
RiskAssessment gate and content | Q-16 delegated; safety-relevant | Owner proposes; company confirms before go-live (UD-06) | Gate parameter; form fields |
CorrectionRequest | Disabled until enabled (Q-04 d) | Owner and company (UD-04) | None structurally |
SchedulingPolicy values | IB-1 to IB-5 | Company signs examples (UD-03) | New policy version |
| Area F (materials) | Extent unknown; no data (Q-21) | Company, then owner (UD-07) | Module added or reduced |
WorkOrder holding execution data | Q-17 c "for now 1" | Company | Split into two tables is a planned migration (D13) |
TaskScheduleState not audited | Derived; P-4 proposed auditing recalculated due points | Owner (UD-14) | If audited, recomputation writes entries (volume) |
WorkOrder.measurements (jsonb) | Structured checklists and measurement parameters are documented but have no source data (5.12) | Owner, then company | A child table replaces the column |
Defect.blocks_origin_close | Q-19 c asks for flexibility (R1 or R2) | Company (FQ-12) | Default value only |
Dual control (confirmed_by) | Administrative safeguard proposed by this design | Owner (UD-25) | Columns unused if not adopted |
LogChain.epoch, LogArchiveManifest | Restore and archive handling (8.7, 8.8) | Owner (UD-26) | Procedure only |
4. Authorisation, ranks, scope and approval authority
Personal accounts; rights follow the position (rank) a person holds on a vessel for a dated period (ADR-05, ID-B). An action is allowed only if all five checks pass; the default is deny (ADR-06). The matrix below is a provisional default, held as configuration and confirmed with the company before go-live (UD-11).
Core componentProvisionalOptionalExternal or platformControl or decision point— solid arrow: synchronous call · - - dashed: asynchronous or worker · ··· dotted: optional
How the parts relate
| Concept | Entities | Evidence |
|---|---|---|
| Who the person is | UserAccount, Credential | NFR-PMS-016; NK-3 |
| What rank they hold, where and when | PositionAssignment, AssignmentVessel | Q-32 b; Q-14 b |
| What a rank may do | PositionRole, RolePermission (matrix as configuration) | Q-14 a, b delegated; reassessment §10 |
| System powers | UserRoleGrant with system roles | NFR-PMS-017; owner decision 4 |
| Who approves each level | ApprovalChain, ApprovalStep | Q-14 b, Q-17 b |
Proposed default permission matrix (provisional, UD-11)
| Permission group | Ship ranks (P.I.C.) | Chief Engineer / Master | Shore department head | Final approver | Web administrator |
|---|---|---|---|---|---|
| View plan, history and reports of the vessel(s) in scope | Own vessel | Own vessel | Scoped vessels | Scoped vessels | All (read) |
| Record completion; attach evidence | Own vessel, own department | Own vessel | — | — | — |
| Enter running hours | Engine ranks, own vessel | Own vessel | — | — | — |
| Approve completion | — | Level 1, own vessel and department | Level 2, scoped | Last level | — |
| Request extension | Own vessel | Own vessel | — | — | — |
| Approve extension | — | Level 1 | Level 2 | Last level | — |
| Propose task change or new task | — | Own vessel | Scoped vessels | — | — |
| Approve task change | — | — | Level 1 (shore) | Last level | — |
| Correction of a reading or closed record (when enabled) | — | Request | Approve | Approve | — |
| Users, assignments, roles, vessels, configuration, import | — | — | — | — | Yes (no approval powers) |
| View and export audit and security logs | — | — | — | — | Yes, export only with a company request reference (owner decision 4) |
5. Maintenance job lifecycle and approval transitions
A work order holds the execution record for now (Q-17 c). Approval levels run on an ApprovalRequest for the configured chain (ADR-07). There is no deferral; an extension is a separate approved record (Q-15, ADR-08). States marked provisional depend on open decisions.
Core componentProvisionalOptionalExternal or platformControl or decision point— solid arrow: synchronous call · - - dashed: asynchronous or worker · ··· dotted: optional
Work order transitions
| From | Event | To | Guard | Effects |
|---|---|---|---|---|
| — | Task enters its first warning stage or becomes overdue (system), or a permitted user opens one | OPEN | No other open work order for the task; task ACTIVE | Due snapshot stored; P.I.C. position assigned (FR-PMS-009) |
| OPEN | Start | IN_PROGRESS | Only where a start gate applies; an APPROVED risk assessment if the gate is BEFORE_START (UD-06) | — |
| OPEN, IN_PROGRESS, RETURNED | Submit | SUBMITTED | Mandatory fields (OD-6); performed_on ≤ today (BR-PMS-018); the reading for hour-limited tasks; the confirmation step; risk assessment if the gate is BEFORE_SUBMIT | A reading is created with source = WORK_ORDER where given; an ApprovalRequest is opened on the active chain for the department |
| SUBMITTED | Approve at step k < n | SUBMITTED | M07 guards (position, scope, separation of duties) | Request moves to step k+1 |
| SUBMITTED | Approve at the last step | CLOSED | As above | The row becomes immutable; M05 recomputes Last Done and Next Due under the policy in force (with the default basis, from performed_on, not the approval date) |
| SUBMITTED | Return at any step, with reason | RETURNED | Reason required (FR-PMS-014) | The request ends RETURNED; a resubmission opens a new request from step 1 |
| OPEN, RETURNED | Cancel, with reason (proposed; no source names a cancelled state) | CANCELLED | Permission held by C/E or shore; never after submission | Task's next work order may open |
| CLOSED | Correction (proposed; off by default) | CLOSED | Approved CorrectionRequest | Amendment overlay; the closed row is unchanged. Q-17 d ("Không thay đổi được") has no exception; BR-PMS-007 and [PMS] 4.11 document correction with audit; the conflict stays open (UD-04) |
Other approval subjects
| Subject | States | Effect of approval |
|---|---|---|
DueExtension | DRAFT → PENDING → APPROVED or REJECTED or WITHDRAWN; APPROVED → LAPSED when the job closes or the extended point passes | The approved point governs this cycle's status. An extension marker is shown, not a "Deferred" status (OD-1). Under the LAST_COMPLETION basis the next cycle counts from the actual completion |
TaskChangeRequest | DRAFT → PENDING → APPROVED or REJECTED or WITHDRAWN | The task is updated (revision +1) in the same transaction; M05 recomputes |
RiskAssessment | DRAFT → SUBMITTED → APPROVED or RETURNED | Opens the gate of its work order |
CorrectionRequest | PENDING → APPROVED or REJECTED | A superseding reading or an amendment overlay; M05 recomputes |
CounterEvent | PENDING → APPROVED or REJECTED | A new counter segment begins; validation of later readings uses it |
6. Audit-log flow: business audit trail, security log, operational log
Three separate concerns (ADR-11, owner decisions 1–7). The two audit chains are append-only and hash-chained in the database, copied hourly to versioned storage and anchored daily in a store the company holds. No application, administrator or migration role can update or delete an entry; the hosting operator cannot alter one undetected.
Core componentProvisionalOptionalExternal or platformControl or decision point— solid arrow: synchronous call · - - dashed: asynchronous or worker · ··· dotted: optional
The three logs
| Business audit trail | Security-monitoring log | Operational diagnostic log | |
|---|---|---|---|
| Purpose | Who changed which business record, when, from what to what (owner decisions 1–3) | Access and control events (owner decision 6) | Fault finding and service health (NFR-PMS-034; ENG-26) |
| Store | AuditEntry in the audit schema, own chain | SecurityEvent in the audit schema, own chain | Platform log collector, outside the database |
| Written by | Database trigger and log writer function, in the business transaction | Application security services and the log writer function | Web and worker processes |
| Values | Before and after per field, masking per 8.6 | Event detail; never passwords, tokens or file content | No business field values and no secrets; identifiers are allowed (account, record, request id), as NFR-PMS-034 needs |
| Readers | Web administrator only (owner decision 4); exports on company request | Web administrator (owner decision 6); exports on request | Delivery lead and the operator, unless the owner extends decision 4 to this log (UD-13) |
| Retention | Permanent (decision 5) | Permanent (decision 5, applied by the owner's NK-6 agreement) | Bounded; values open (UD-13) |
| Integrity | Append-only; hash chain; anchors (decision 7) | Same | Platform protections only |
Access and the administrator boundary
| Actor | Can | Cannot |
|---|---|---|
| Operational users | See business history of records in scope | Open the audit or security log (owner decision 4) |
| Web administrator | View and search both logs (read-only); export with a company request reference; see integrity status | Edit, delete or reorder an entry: no function exists, and the application's database role has no UPDATE or DELETE on log tables. Approve maintenance. Disable logging |
| Application database role | Call the log writer function (INSERT through a definer-rights function) | UPDATE, DELETE or TRUNCATE on audit.* |
| Release and migration role | Schema changes through the reviewed release pipeline; who reviews the pipeline is an owner decision (UD-25) | Rewrite log rows through the application; a structural change carries logs unchanged (P-16). It technically could disable triggers: detected, not prevented (8.2) |
| Hosting operator or database superuser | Technically could alter, remove or insert rows, or disable capture | Alter anchored entries undetected. Entries written since the last anchor are protected only by the hourly segments, which sit in hosting-controlled storage; a superuser can recompute an unanchored chain. Shorter anchor intervals and a company-side verifier narrow this window (UD-23) |
7. Deployment, persistence, backups and recovery
A portable deployment (containers, standard PostgreSQL, S3-compatible storage, infrastructure as code). H3 is the proposed hosting model and recovery tier R2 the proposed minimum; both are owner decisions with the company's acceptance of cost and values (UD-01). High availability is not assumed (NFR-PMS-033).
Core componentProvisionalOptionalExternal or platformControl or decision point— solid arrow: synchronous call · - - dashed: asynchronous or worker · ··· dotted: optional
Hosting options
| H1 Company premises | H2 Delivery side hosts | H3 Company's own cloud account, operated by the delivery side | |
|---|---|---|---|
| Custody of data and logs (Q-36 c) | Company | Delivery side; exit needs a contract (NFR-PMS-028) | Company |
| Who can reach the database (TB-4) | Company IT | Delivery staff | Delivery operators, under the company's account |
| Anchor holder independence (R-009) | Natural | Needs a company-held anchor | Natural, if the anchor store is in a separate company area |
| Reach from ships | Needs an internet-facing endpoint or VPN (BWT_VPN_Connect.rar was listed but is absent; UNKNOWN) | Internet-facing | Internet-facing |
| 24-hour operation (Q-35 a) | Company IT and its link | Delivery side support commitment | Delivery side support under the company's account |
| Managed PostgreSQL with point-in-time recovery, object storage with versioning | Must be built and operated | Available | Available |
| Lock-in | Low | High | Medium (portable build) |
Backups
| Asset | Mechanism | Proposed candidate values (for the owner's proposal to the company; not targets) |
|---|---|---|
| Database | Continuous write-ahead-log archiving with point-in-time recovery, daily base backups, encrypted, stored outside the production account or zone | Recovery window 35 days; monthly copies kept 12 months |
| Files | Object storage versioning; replication to a second location | Versions kept permanently (no deletion) |
| Log segments | Versioned object storage (optionally object-locked) | Permanent |
| Configuration and infrastructure | Infrastructure as code in the repository; secrets in the platform secrets store with its own backup | — |
Integrity checks
| Check | Frequency | Failure handling |
|---|---|---|
| Audit and security chain verification against anchors | Daily; before every log export; after every restore | Security event, alert, runbook |
| Database constraint and reference verification (orphans, composite-key consistency) | Weekly, in a read-only job | Operational alert; investigation |
Object storage: every StoredFile has its object with a matching fingerprint | Weekly sample, full monthly | Operational alert |
| Schedule projection rebuilt from inputs and compared | Weekly sample | Defect: the derived data disagrees with the rule |
| Restore rehearsal | Before go-live; then on a schedule | Restore report (ENG-25) |
8. Decisions, assumptions, blockers and risks
Every table here is taken from the proposal. Inputs are owner-confirmed company answers (handoff §0.14); ADRs are recommendations awaiting the owner; assumptions are temporary; unresolved decisions name what they block.
Unresolved decisions
| ID | Decision | Blocks | Decided by (role) | Latest moment | Recommendation |
|---|---|---|---|---|---|
| UD-01 | Hosting model (H1, H2, H3), recovery tier and RPO and RTO values, end-of-service custody | Ordering production; G4 at the latest | Owner proposes; company accepts cost and values | Before the production environment is ordered | H3; R2 minimum (ADR-15) |
| UD-02 | Acceptance of the identity model ID-B, which reads "Quản lý theo chức danh" as rank-based rights rather than shared rank logins | G1 (identity ADR) | Owner (model); company confirms the reading (NFR-PMS-016) | G1 | ID-B (ADR-05) |
| UD-03 | Scheduling rules: basis, month length, quarter and year, first due, hour mode, warning stages and their source, time zone | Production code of M05 and M08 | Company authority signs worked examples | G0 of the scheduling increment | TA-01 defaults |
| UD-04 | Corrections: enabled or not; who requests and approves | Enabling the correction function | Owner and company | Before go-live | Built, disabled; senior approval |
| UD-05 | Extension rules: effect, limits, critical jobs, lapse | Extension feature | Company (FQ-10) | G0 of the work-order increment | THIS_DUE_ONLY; critical extensions require the last level |
| UD-06 | Risk-assessment trigger, gate, approver, content | Risk-assessment feature; go-live | Owner proposes (OD-5); company confirms | Before go-live (safety) | BEFORE_START for critical tasks |
| UD-07 | Materials extent (levels 1–4) and the source of materials data | M17 | Company, then owner (FQ-14) | Before M17 design | Level 1 first |
| UD-08 | Data that must not be logged (NK-2 b); masking rule | First production audit entry | Company, then owner | Before the first production entry | Classification of 8.6 |
| UD-09 | Workbook to load; treatment of typed Last Done values and anomalies; who signs off | Import load (G4) | Owner position (O-06), then company | G4 | Decide with FQ-07, FQ-15 |
| UD-10 | GROUP 0 mapping; job key; equipment code rule | Import mapping | Owner proposes; company confirms (FQ-08) | Before load design | 2a; (vessel, group, job code); OD-3 |
| UD-11 | Approval levels per process and department; office position titles; deck chain through the Master | Go-live configuration | Company (FQ-28) | Before go-live | Example chains of 6.3 |
| UD-12 | Who holds the web administrator role (company, delivery side, both) and who may request exports (NK-4 b) | Threat model; G5 | Owner and company | G1 for the threat model | Named persons on both sides; company requester list |
| UD-13 | Operational log: retention, who may read it, and whether decisions 4, 5 and 7 cover it | Observability design; NFR-PMS-034 merged view | Owner | G5 | Bounded retention; not immutable; delivery lead and operator read it |
| UD-14 | Exclusions from the business audit trail: the derived schedule projection, sessions, caches, notification delivery status | Audit design | Owner | G1 | Exclude (sections 7.4, 8.2) |
| UD-15 | Supported devices, screen sizes, browsers; accessibility reference | UX-G1 | Owner (O-13) | UX-G1 | WCAG 2.2 AA as internal reference |
| UD-16 | Which parts are bilingual; Vietnamese names for master data | UX-G1; data model detail (name_vi) | Company (FQ-19) | UX-G1 | Switchable interface; optional Vietnamese names |
| UD-17 | Optional modules: built now and hidden, or built on request | Build plan | Owner, then company (FQ-20) | Build planning | On request |
| UD-18 | Programming language, framework and libraries | G2 | Delivery lead, recorded as an ADR | G2 | Criteria: mature authentication, ORM with migrations, server-rendered pages, PostgreSQL support, team skill |
| UD-19 | Time-zone rule for business dates on board | Scheduling examples | Owner proposes; company confirms (IB-15) | With UD-03 | Vessel's zone at entry, stored with the record |
| UD-20 | Network address and device details in the security log | Security log content | Owner (privacy) | G1 | Record address; no device fingerprinting |
| UD-21 | Erasure route ("none" or a legal-order procedure); inline or referenced personal values in logs; legal and sector assessment | First production entry (the storage choice); G5 (the legal note); option I3 | Owner (ENG-19, ENG-33) | Before the first production entry | Referenced personal values (8.6); "none" as the route until a legal need appears; no I3 until decided |
| UD-22 | Detection versus prevention for the logs: accept that privileged database roles can bypass or alter, with detection (I2), or add write-once storage (I3) | G1 (audit ADR) | Owner | G1 | I2 with bypass detection (8.2) |
| UD-23 | Anchor holder at the company; anchor interval; a company-side verifier; who may change the anchor destination (FQ-23) | First production entry | Company names the holder; owner decides the rest | Before the first production entry | Daily anchors; destination change needs company acknowledgement |
| UD-24 | Audit interpretations: I-1 ("important"), I-2 (which exports), which history is business-visible (P-3), which attachment actions count, failed sign-in volume and aggregation | Audit build | Owner | Before the audit build is finished | As read in 8.1 to 8.3 |
| UD-25 | Administrator safeguards: dual control for approver-capable assignments and HIGH grants; at least two administrators; one account per person; who oversees the administrators; who reviews the release pipeline; emergency access | G1 (threat model); G5 | Owner; company for oversight | G1 | As proposed in 4.2 |
| UD-26 | Restore policy: who authorises a restore; epochs; roll-forward of lost changes from segments or re-entry from paper (Q-35 c) | G5 | Owner | G5 | Epochs; roll-forward reviewed case by case |
| UD-27 | When production logging starts; how test and training data are kept out (P-22) | First production entry | Owner | Before go-live | Start at the first production import |
| UD-28 | Delivery channel for log and full-data exports; a company-side check of export manifests | Log export | Owner; company | Before go-live | Delivery to the named requester; manifest checked by the company |
Architecture decision records (all Proposed)
| ADR | Decision | Status | Decides | Revisit when |
|---|---|---|---|---|
| ADR-01 | One central online installation (A1, reading S1) | Proposed | Owner | ships report frequent or long outages (FQ-24), or the company asks to keep working without a link. |
| ADR-02 | One company, data scoped by vessel (M2) | Proposed | Owner | a second company is to share one installation. |
| ADR-03 | Modular monolith: one application, a web process and a worker | Proposed | Delivery lead, with the owner's acceptance | a module needs independent scaling or release, or a separate team owns one. |
| ADR-04 | PostgreSQL as the system of record; object storage for files | Proposed | Delivery lead, with the owner's acceptance | a company IT policy mandates another database. |
| ADR-05 | Personal accounts; rights follow dated position assignments (ID-B) | Proposed | Owner (model); the company confirms the reading of Q-32 b (UD-02) | the company confirms the literal reading, shared rank logins. That conflicts with NK-3 and goes to the owner. |
| ADR-06 | Authorisation: deny by default; position-derived roles; vessel and department scope; workflow rules | Proposed | Owner | the company requires rules the matrix cannot express, such as time-of-day or location rules. |
| ADR-07 | Configurable sequential approval chains (W2, bounded) | Proposed | Owner | the company needs parallel approval or delegation. |
| ADR-08 | Extension replaces deferral; status set without "Deferred" | Proposed | Owner (model); company (rules, FQ-10) | the company asks for deferral as a distinct act. |
| ADR-09 | One scheduling engine with versioned policies; status evaluated at read time | Proposed (mechanism) | Owner (mechanism); company authority (rules) | the company signs rules that the parameters cannot express, for example usage-based months (M3). |
| ADR-10 | Running hours as appended cumulative readings; corrections only as approved linked entries | Proposed | Owner and company (enabling corrections, UD-04) | the company forbids corrections entirely, or asks for a different procedure. |
| ADR-11 | Audit realisation I2: database-captured, append-only, hash-chained logs with a company-held anchor | Proposed | Owner. The company names the anchor holder (FQ-23) | a regulation requires write-once storage (add I3), or a legal erasure route is required (UD-21). |
| ADR-12 | Files in private object storage, fingerprinted, never deleted | Proposed | Delivery lead, with the owner's acceptance | a legal requirement to erase personal images appears (UD-21). |
| ADR-13 | Optional modules behind installation-level switches; built when scheduled | Proposed | Owner (timing, UD-17) | the owner decides to build a module now. |
| ADR-14 | Materials as a separate, provisional module | Proposed | Company (extent), then owner | FQ-14 is answered. |
| ADR-15 | Portable deployment; H3 recommended; recovery tier R2 as the minimum | Proposed | Owner proposes; the company accepts cost and values (UD-01) | company IT policy or cost rules out H3. |
| ADR-16 | Bilingual interface and outputs | Proposed | Owner; parts confirmed by the company (UD-16) | the company wants job texts translated. |
| ADR-17 | Time handling: UTC instants, business dates, two times | Proposed | Owner; the company confirms the zone rule (UD-19) | the company fixes one fleet time zone. |
| ADR-18 | Staged import with validation-only runs, complete-or-nothing load and provenance | Proposed | Owner; the company signs off the data (G4) | the company chooses L-B or L-C. |
Temporary assumptions
| ID | Assumption | Basis | Used for | Review point |
|---|---|---|---|---|
| TA-01 | Scheduling defaults: LAST_COMPLETION, DAYS_30, Q = 3 M (90 days), Y = 365 days, EARLIEST_OF, stages {14, 10, 6, 3} days, first due = start date or entry date | Workbook practice (A19, A20; GROUP 6 year = 365; GROUPs 0, 5, 9 TODAY() + interval); Q-06 b example; UI-03 to UI-05 | Prototype example tables only | Signed examples (UD-03) |
| TA-02 | GROUP 0 mapped to the same physical equipment (2a) | OD-2 | Import prototype | UD-10 |
| TA-03 | Task key (vessel, group, job code); job codes unchanged | OD-3; 317 codes repeat across sheets | Model and import | FQ-08 |
| TA-04 | Counters: Main Engine and No.1 to No.3 generators. M/E auxiliary and shafting hour jobs on the Main Engine counter. No radar counter unless the company confirms a meter | Workbook counter rows (7.1); M/E-hour comments on 2 of 30 auxiliary and shafting jobs (INFERRED for the rest); radar J = I + 30 days | Import mapping | FQ-05 |
| TA-05 | Default projection rates: about 12 h/day for the Main Engine counter and 16.7 h/day for the generators, as [PIONEER] implies ([M008-FINAL] implies 15.4 h/day on six generator jobs). The 19 GROUP 1 jobs at 40,000 H are time-limited at 5 years, which the TIME limit covers | GROUP 1's 14 day constants; GROUP 2 ×0.06; workbook review 2026-10-18 | Hour-limit projection where readings are missing | Observed rates after go-live; FQ-05 |
| TA-06 | Sizing scenario: up to 300 vessels, ~1,700 tasks each, ~1,000 executions per vessel per year | Reassessment §3.3 | Capacity design | NFR-PMS-008 targets |
| TA-07 | The web administrator is an in-app role held by named people, possibly on both company and delivery sides | Owner decision 4; P-11 | Authorisation design | UD-12 |
| TA-08 | Status set Normal, Upcoming (with stage), Overdue; extension shown as a marker; no Deferred, no Priority | OD-1; Q-07 a; Q-12 b; Q-15 | Model and UI | Company confirmation of the vocabulary (UX-G1) |
| TA-09 | Status counts only CLOSED executions; submitted work is marked "awaiting approval" | BR-PMS-002 ("hợp lệ"); Q-17 | Monitoring | UD-03 examples |
Interpretations of unclear answers
| ID | Answer | Readings | Evidence | Recommendation and why | Residual uncertainty |
|---|---|---|---|---|---|
| UI-01 | Q-27 b "đồng bộ liên tục" | S1 one central store; S2 a copy on each vessel kept in step | Q-27 a makes a stable connection the precondition; no request for an on-board server; Q-35 d accepts paper; Q-37 a names computers and phones, not a ship server | S1 (ADR-01). It satisfies "changes are visible at once" without replication, and it is an order of magnitude cheaper to build and support | If ships report long or frequent outages, revisit (A2 offline capture is kept possible by principles 1–4) |
| UI-02 | Q-32 b "quản lý theo chức danh" | ID-A shared rank logins; ID-B personal accounts with rights by rank; ID-C rank queues; ID-D rank only for P.I.C. | Owner decision 3 and NK-3 make the actor a core audit attribute; Q-17 a requires "ai làm"; the process documents track named people (DOC-13.1) | ID-B (ADR-05). Rights, approvals and work lists follow the rank a person holds on a vessel for a period, which is what "managed by rank" needs day to day. Shared logins would make permanent audit entries unattributable (R-003), contradicting the company's own NK-3 agreement | The company may still prefer a shared login per rank; if so, the conflict with NK-3 goes to the owner (UD-02 is not needed unless this happens) |
| UI-03 | Q-05 a, Q-06 a "tạm thời tất cả là tính theo chu kỳ" with 491 hour jobs | H1 due by readings; H2 convert hours to time; H3 estimated date, as the workbook does | The workbook stores 491 H intervals but schedules them by estimated dates (GROUP 1: 14 day constants of about 12 h/day; GROUP 2: ROUND(hours×0.06) days; radar: a monthly check). Only the main engine has readings, under about 10% of its execution dates. Q-04 asks crew to enter hours; Q-06 b wants warnings in days | Keep hours in the data; compute the earlier of the hour-limit date projected from readings and any time limit (EARLIEST_OF, ADR-09). Where a counter has no readings the result equals the workbook's estimated date (H3), so the first release reproduces current practice; where readings show faster running, the job falls due earlier, which is the safe direction. Warnings are in days, as Q-06 b asks | The rule is a business rule: production code waits for signed worked examples (G0; UD-03). If the company chooses pure H2, the hour limit is simply not used; no schema change |
| UI-04 | Q-02 a "tháng sử dụng" | M1 calendar month; M2 30 days; M3 months of in-service time | Workbook ×30 ('PIC LEGEND'!A19); the company says the workbook is the standard; no source tracks idle time | Policy parameter; default DAYS_30 (M2) to reproduce the workbook, which is never later than calendar months (TA-01). M3 would need usage tracking no source has, so it is not modelled | Signed worked examples decide (FQ-02); the parameter makes the change a policy version, not a release |
| UI-05 | Q-01 a (basis not chosen) | Last completion; previous due date; start date | Workbook rule: Last Done + cycle (A19); Q-15 d "lịch quy ước trong file" | Default LAST_COMPLETION (TA-01). Under this basis an extension affects only the current due point, which removes most of the open extension question (FQ-10 a) | Signed examples (FQ-01) |
| UI-06 | Q-04 b "giờ bắt đầu và giờ kết thúc" | Meter reading at start and end of a period; clock times; meter at start and end of the job | The workbook records the cumulative main-engine total at each execution date ('GROUP 1'!N6) | Store cumulative readings; accept a start/end form as an input format that is converted to cumulative values (entry_form), until FQ-04 is answered | Format only; no structural risk |
| UI-07 | Q-04 d, Q-17 d "không sửa được" | No overwrite (correction by new entry possible); no correction ever | Q-04 d itself mentions a senior authority correcting "theo quy trình"; BR-PMS-007, 017 require audited correction; AUD-02 (stuck-counter risk) | Never overwrite; build a correction path as an approved, linked new entry restricted to a senior role, switched off until the owner and company enable it (ADR-10) | Enabling and the authority are UD-04 |
| UI-08 | Q-21 a "quản lý kho … sàn thương mại điện tử" | Levels 1–4 of FQ-14 | No materials data anywhere; [PMS] §5 documents a full chain | Separate module behind a narrow interface to work orders; levels 1–3 modelled provisionally; purchasing not modelled (ADR-14) | Extent is UD-07; it does not block the core |
| UI-09 | Q-19 a, Q-20 a modules "designed in advance" | Built now and hidden; allowed for and built when asked | NFR-PMS-011 separability; risk R-010 | Module switches and extension points now; build each module when it is scheduled (ADR-13) | Timing is UD-17; no structural effect |
| UI-10 | Q-10 b hierarchy (delegated) | GROUP 0 linked to the same physical equipment (2a) or loaded as its own nodes (2b) | INFERRED: group = sheet, equipment = level-1 heading, component = level-2 heading; the job code agrees with the headings in 98.4% and 95% of jobs, with exceptions in GROUP 3 and GROUP 8 (reconciliation Q-10, an assessment; DATA-PMS-001 records the mapping as not established) | Proposed: tasks carry their group; equipment is a physical tree with a display group. Both 2a and 2b fit the model; recommend 2a with a mapping table (OD-2) | Mapping table is part of UD-10. A group change edits the task's key and is an important change (OD-11) |
Accepted inputs (owner-confirmed company answers)
| ID | Input (paraphrased; the Vietnamese text is authoritative) | Source | Clarity | Design consequence |
|---|---|---|---|---|
| IN-01 | Works online; a stable connection is a precondition; edge cases to be considered; "continuous synchronisation" | Q-27 a, b | E; U (meaning of synchronisation) | One central installation (ADR-01); interpretation UI-01 |
| IN-02 | Paper records are an accepted fallback | Q-35 d | E | No offline client; back-entry procedure with two times (ADR-17) |
| IN-03 | Service 24 hours a day; a mechanism so data is not lost and re-entered | Q-35 a, c | E (direction) | Point-in-time recovery R2 as minimum (ADR-15); HA not assumed (NFR-PMS-033) |
| IN-04 | Few vessels now; design for tens to hundreds; many vessels of different sizes, one company | Q-09 b, Q-31 | E | Vessel-scoped single-company model (ADR-02) |
| IN-05 | Company: BLUEWAVE TANKERS; the KTS BROWN sheets apply to BLUEWAVE PIONEER | Q-09 a, c | E | Company singleton; both workbook headers describe one vessel |
| IN-06 | The two Excel files are the company's current database and the standard for structure and content; Q-10 a answers "Có" to the proposed hierarchy Vessel > PMS Group > System > Equipment > Component | Q-10 a, Q-13 b, Q-07 b, Q-23 a | E (theme); U (what it settles) | Workbook practice is the default for content and calculation (UI-04, UI-05); never a silent rule (reconciliation X1). The System level is allowed in the model but unused by the workbook mapping (UI-10) |
| IN-07 | If the file has no equipment code, the delivery side sets the conventions for both kinds of code (job and equipment); codes follow the vessel and are "likely" unique vessel-wide; other vessel types have other code groups; history cannot change | Q-11 a–c | D; U; E | Stable surrogate keys. The recommended job key (vessel, group, job code) departs from "likely unique vessel-wide", because 317 job codes repeat across sheets (TA-03; FQ-08) |
| IN-08 | No Priority attribute unless the file has one (it has none); Critical placement is ours to infer | Q-12 a, b | D | Critical on equipment and task, inherited (OD-4); no Priority |
| IN-09 | Approval at several levels, for example ("chẳng hạn") the chief engineer on board, a department head ashore and a final approver; the creator is a person of high authority; number of levels unknown; design flexibly | Q-14 b, Q-17 b | E (chain); D (detail) | Configurable sequential approval chains (ADR-07). The named levels are examples; the deck chain through the Master is this design's proposal (UD-11) |
| IN-10 | Jobs are not deferred; an extension, if needed, is approved through the rank levels | Q-15 a–e | E | DueExtension replaces deferral (ADR-08); conflicts with C-11 records kept until revision 5 |
| IN-11 | Risk assessment: design flexibly, approval "likely by rank", no standard form yet | Q-16 | D | Configurable gate and chain (OD-5; UD-06) |
| IN-12 | A completion records at least time and performer; work order and execution are one record for now; a closed record cannot be changed | Q-17 a, c, d | D; E; E | WorkOrder holds execution (D13); closed rows immutable; correction only as a linked entry (ADR-10) |
| IN-13 | Nothing is deleted; old data may be "backed up" if there is too much | Q-18 | E; U | No delete paths; retrievable archive tier (D11) |
| IN-14 | Defects and unplanned work are in the design; modules can be shown or hidden per customer; design flexibly: a defect that does not affect the original job may stay open while the original job closes normally | Q-19 a, c | E; U | Module switches (ADR-13); Defect optional module; blocking is a per-defect setting, so both readings R1 and R2 are supported (blocks_origin_close) |
| IN-15 | Event-based maintenance is an optional extension module | Q-20 a | E | Optional module; dock jobs keep workbook intervals until enabled (OD-8) |
| IN-16 | Materials: "Có" to a question listing used materials, links to existing slips, stock, purchasing and cost; described as inventory management "like an e-commerce platform", updated and linked; "take the Excel DB as the standard" | Q-21 a, b | E (wanted; the "Có" arguably covers all five levels); U (extent); conflict (no materials data in the files) | Separate materials module, provisional (ADR-14; UD-07). Leaving purchasing and cost unmodelled is a delivery-side deferral pending FQ-14, not a company choice |
| IN-17 | Form M008 must be produced, for all eleven groups | Q-22 b | E | M008 is a report over stored data for every group |
| IN-18 | The new system is entirely new; Last Done is updated by the equipment cycle starting from the replacement date ("ngày thay") and the maintenance date, not typed | Q-23 a, b | U | Last Done is always derived from closed executions in the new system; a replacement is recorded as an execution, and the install date can serve as the first-due basis (in_service_from). Typed Last Done values in the workbook sit uneasily with "không nhập tay" and are handled per UD-09 |
| IN-19 | SMA is not used and cannot export data | Q-24 | E | No SMA integration; SMA-derived positions carry less weight (X10) |
| IN-20 | Important documents may need approval; storage-only or approval designed flexibly; files should not be too large | Q-25 | D | Optional documents module with per-type approval (OD-10) |
| IN-21 | Vessels share some tasks and have their own; important task changes need approval | Q-26 | E (direction) | Template link now, propagation later (T2 staged); TaskChangeRequest |
| IN-22 | Bilingual English and Vietnamese, flexibly by part | Q-28 | E; U (which parts) | ADR-16 |
| IN-23 | Sign-in, hosting, backup, audit policy and retention are the delivery side's to decide; data safety comes first | Q-29 | D | ADR-05, ADR-11, ADR-15 are delivery-side recommendations, subject to the owner's acceptance and the company's agreement on cost |
| IN-24 | External notifications are an optional module; a visible urgency warning before the due date is mandatory; the warning changes as the date nears ("kiểu" 14, 10, 6, 3 days) | Q-30, Q-01 b, Q-06 b | E; U (values) | In-app staged warnings computed at read time; e-mail optional |
| IN-25 | About tens of users; design to scale; accounts "Quản lý theo chức danh" (managed by rank; literally read, rank-managed accounts) | Q-32 | E; U (b) | Recommended reading ID-B: personal accounts whose rights follow rank assignments. This diverges from the literal reading of shared rank accounts; see UI-02 and UD-02 |
| IN-26 | Many file types; files not too large; storage must be planned | Q-33 | D | Allow-list and size limits as configuration; object storage (ADR-12) |
| IN-27 | No lag; smooth | Q-34 | U | Performance targets measured, not assumed (ENG-29) |
| IN-28 | Keep permanently; archive or compress old data; full export only on request; keep old data when a vessel leaves or service ends | Q-36 | E | Permanent retention; archive tier; export manifest; custody rule (UD-01) |
| IN-29 | Computers only; phones only for photographs and phone-type operations; easy for everyone | Q-37 | E; U (phone tasks) | Desktop-first responsive UI; phone pages for capture (section 2.4) |
| IN-30 | Real-data copies allowed in a test environment that does not affect production | Q-38 | E | Isolated verification environment; masking per testing policy §12 |
| IN-31 | Running hours entered by crew, "per the equipment's cycle (start and end hours)"; not editable after entry for now; a confirmation prompt before saving; a senior authority might correct later through a procedure | Q-04 b, d | E; U | Append-only readings; confirmation step; correction path built but disabled (ADR-10) |
| IN-32 | Which equipment has hour meters: "for now all are by the equipment's cycle"; which counter each hour job uses: "as above"; when an hour job is due: "for now by the equipment's cycle" | Q-05 a, b; Q-06 a | U | Interpretation UI-03; which machines have meters stays open (TA-04) |
| IN-33 | Units: day, week, month, quarter, year; a month is a "month of use" | Q-02 | E; U | Units D, W, M, Q, Y, H; month rule UI-04 |
| IN-34 | Status definitions are ours to set | Q-07 a | D | Status set OD-1 (TA-08) |
| IN-35 | NK-1 to NK-7 a): agreement with the owner's audit decisions 1–7 | NK-1 to NK-7 | E | ADR-11. The b) parts are blank (UD-08, UD-12) |
| IN-36 | Both Excel files were provided; differences reflect vessel characteristics | Q-08 | U; the explanation is not supported by the files (reconciliation Q-08) | Workbook to load is UD-09 |
| IN-37 | The critical list in the file is the active one; changes will be reported during trial | Q-13 | E | Critical is data; five unverified GROUP 0 jobs flagged (DF-1) |
| IN-38 | Hand over the necessary documents | Q-39 | U | Bilingual user and administrator guides (OD-15) |
What can start, what needs a prototype, what must wait
| Work | Can start after G2 (owner acceptance of ADRs, standards adopted, roles named, repository) | Needs a prototype first | Must wait |
|---|---|---|---|
| Platform foundation (M01, M02, M09, M11, M12) | Yes | Audit chain, anchor and restore-gap detection (prove AC-4 to AC-6) | First production log entry: masking rule (UD-08), personal-value storage (UD-21), anchor holder (UD-23), logging start (UD-27) |
| Plan structure (M03, M04 structure) | Yes, without loading data | — | Job key and GROUP 0 mapping before load (UD-10) |
| Import (M10) validation-only | Yes, on synthetic data | Parser against a copy of the real workbook under Q-38's conditions | Load: G4 (UD-09) |
| Scheduling engine (M05) | No | A pure library to produce worked-example tables for signature | Production rules: signed examples (UD-03) |
| Monitoring and warnings (M08) | After M05 rules | Monitoring query at the 300-vessel scenario | Stage values (FQ-06) |
| Approvals (M07) | Mechanism yes (configurable) | — | Chain contents (UD-11) before go-live |
| Work orders (M06) | Structure yes | Phone photo upload over a slow link (J2) | Risk-assessment gate (UD-06), extension rules (UD-05), corrections (UD-04) |
| Reports and M008 (M08) | After M06 | — | Layout details (DF-2) |
| Optional modules (M13–M16) | Switches yes | — | Scheduling decision (UD-17) |
| Materials (M17) | No | — | Extent (UD-07) |
Risks
| ID | Risk and trigger | Likelihood | Impact | Response | Owner | Due |
|---|---|---|---|---|---|---|
| R-002 | A calculation rule is coded on an assumption and due dates are wrong for safety-related work | Medium | High | Prevent: production rule code only after signed worked examples (G0); T1 tests; mutation testing | Company authority; delivery lead | Before scheduling increment |
| R-003 | Shared rank logins make permanent audit entries unattributable | Low (ADR-05 proposed) | High | Prevent: accept ADR-05 (personal accounts with rank assignments) before any production entry | Owner | G1 |
| R-005 | The 'stable connection' precondition does not hold on some vessels | Medium | Medium | Contain: paper fallback with back-entry; idempotent retries; FQ-24; A2 kept possible | Owner | G1 |
| R-006 | No correction path is enabled and a mistyped reading blocks a counter or hides due work | Medium | High | Contain: correction function built but disabled (ADR-10); decide UD-04 before go-live | Owner; company authority | Before go-live |
| R-007 | The wrong workbook is loaded and history is lost | Medium | High | Prevent: UD-09 before G4; reconciliation counts; validation-only rehearsal | Owner | G4 |
| R-008 | Permanent retention of logs and photographs makes storage grow without bound | Medium | Medium | Detect: size limits at upload; archive tier; capacity scenario TA-06 | Delivery lead | G1 |
| R-009 | One party holds database access, backups, log administration and the integrity anchor | Medium | High | Prevent: company-held anchor (FQ-23); H3 hosting; separate admin accounts | Owner | G1 |
| R-010 | 'Design flexibly, change later' leads to over-configurable features | High | Medium | Contain: each configuration point bounded in an ADR (ADR-06, 07, 09, 13) | Owner | G1 |
| R-011 | The five GROUP 0 jobs awaiting verification are loaded as verified safety jobs | Medium | Medium | Detect: verification_state flag at load; FQ-09 | Owner | G4 |
| R-012 | The web administrator is the only reader of the log that records their own actions | Medium | Medium | Contain: every log view and export is a security event; company can request the record; company-held anchor | Owner | G1 |
| R-013 | A missed vessel filter exposes another vessel's data | Low | High | Prevent: mandatory scope in repositories, composite keys, row-level security, negative tests per role and vessel | Delivery lead | G3 |
| R-014 | The excluded-from-audit derived projection is later judged to need audit, adding volume | Low | Low | Accept or decide UD-14; inputs are audited and results reproducible | Owner | G1 |
| R-015 | Materials scope ('like e-commerce') grows into a separate product inside the PMS schedule | High | High | Contain: separate provisional module M17 behind a narrow interface; extent decided first (UD-07) | Company authority; owner | Before M17 |
| R-016 | Photograph upload over a slow ship link fails or duplicates evidence | Medium | Medium | Prevent: size limits, idempotent resumable upload, prototype over a slow link (J2) | Delivery lead | Before work-order increment |
| R-017 | A policy-version recomputation changes many due dates at once without users noticing | Medium | Medium | Detect: recomputation report of changed due points before activation; owner approval of the policy version | Owner | Each policy change |
| R-018 | Restoring the database loses recent entries, including log entries | Low (R2) | High | Contain: point-in-time recovery; hourly log segments; RESTORE_GAP record; paper back-entry | Delivery lead; owner | G5 |