Notification and Communication Examination Findings
Findings
These records distinguish implementation defects, unapproved extensions and limits of the available evidence. Evidence remains in the structured source list; recommendations describe proposed product decisions.
| id | severity | statement | affects | evidence | kind |
|---|---|---|---|---|---|
FND-PFM-NOT-001 | medium | The approved HQ decision excludes a reserved workspace, while implementation creates a demonstration support workspace for system alerts. The handoff treats that choice as an assumption. The product should resolve whether this workspace is permitted and whether ordinary HQ lists and nightly processing should include it. | CAP-PFM-NOT-013, CON-PFM-NOT-002 | See finding_evidence | inconsistency |
FND-PFM-NOT-002 | low | Several records reference a plan filename absent from the pinned tree. The humanized plan is available and supplies this corpus's milestone authority. The product should correct the stale plan references. | MOD-PFM-NOT | See finding_evidence | inconsistency |
FND-PFM-NOT-003 | medium | The approved combined bell is incomplete: its popover does not contain a Notifications section. The associated intended rule lacks passing implementation proof, pending the attention milestone dependency. | CAP-PFM-NOT-009, BR-CAP-PFM-NOT-009-09, JNY-PFM-NOT-001 | See finding_evidence | defect |
FND-PFM-NOT-004 | medium | The milestone remains in progress. Its recorded fourth acceptance run passes eighteen of nineteen journeys, with the delivery-explanation defect, partial bell integration and unconfigured Slack token still limiting verification. The product should complete those proofs before treating the release as verified. | CAP-PFM-NOT-009, CAP-PFM-NOT-010, CAP-PFM-NOT-011, CAP-PFM-NOT-013, JNY-PFM-NOT-004 | See finding_evidence | debt |
FND-PFM-NOT-005 | medium | Preference, wording, identity, digest and text-accounting persistence exists outside the approved core release. Current routes and orchestration do not expose or consult it. The product should approve a future milestone plan before activating those primitives. | CAP-PFM-NOT-015, BR-CAP-PFM-NOT-015-13, FEAT-PFM-NOT-06 | See finding_evidence | inconsistency |
FND-PFM-NOT-006 | low | The request-outcome enumeration includes definition-disabled, but current processing never writes it because workspace enablement settings are not applied. | CON-PFM-NOT-002, CAP-PFM-NOT-015 | See finding_evidence | debt |
FND-PFM-NOT-007 | low | The History delivery table omits the future milestone from unused-channel explanations. The recorded defect leaves the intended explanation rule without passing proof. | CAP-PFM-NOT-011, BR-CAP-PFM-NOT-011-08, JNY-PFM-NOT-003 | See finding_evidence | defect |
FND-PFM-NOT-008 | low | Ending an undispatched assignment prevents its assignment announcement but still sends the ending announcement. Whether recipients should hear about an assignment they never received remains an open product decision. | CAP-PFM-NOT-014, BR-CAP-PFM-NOT-014-09, JNY-PFM-NOT-002 | See finding_evidence | inconsistency |
FND-PFM-NOT-009 | high | The handoff reports that the notification submission role still needs adoption in the shared capability-role catalog. This examination does not inspect that external catalog. The product should obtain owning-infrastructure proof before relying on other services to publish. | CAP-PFM-NOT-002 | See finding_evidence | debt |
FND-PFM-NOT-010 | low | The shared producer library excludes system audiences, so Platform uses a separate HQ publication path with repeated envelope validation. The recorded debt identifies the duplication that future library adoption should resolve. | CAP-PFM-NOT-013 | See finding_evidence | debt |
FND-PFM-NOT-011 | medium | The registered scope includes notification Settings, HQ History, shared notification components and libraries. The legacy alerts route redirects to attention and is outside notification rule ownership. The module inventory preserves that boundary. | MOD-PFM-NOT | See finding_evidence | inconsistency |
FND-PFM-NOT-012 | medium | The examined communications records confirm the original architecture and acceptance, but provide no matching Andrew decision for later caller-rendered, Marketing-lane and version-owned extensions. Their observed implementation remains proposed. | CAP-PFM-NOT-017, CAP-PFM-NOT-018, CAP-PFM-NOT-020 | See finding_evidence | undocumented |
FND-PFM-NOT-013 | low | The communications architecture repeats a section number for two different subjects, making numeric citations ambiguous. The product should use descriptive heading references until the record is corrected. | MOD-PFM-NOT | See finding_evidence | inconsistency |
FND-PFM-NOT-014 | medium | The communications acceptance excludes console delivery work. Permitted notification screens contain no communication-history or suppression interface, but this limited scope cannot establish repository-wide screen absence. | CAP-PFM-NOT-019, CAP-PFM-NOT-020 | See finding_evidence | undocumented |
FND-PFM-NOT-015 | medium | Lane capacity has no implemented workspace-fairness guarantee. The product should decide how simultaneous senders share a lane before assuming campaigns receive fair service. | CAP-PFM-NOT-018 | See finding_evidence | debt |
FND-PFM-NOT-016 | medium | Owned-template requests lack independently trusted submitting-service identity at acceptance. A service permitted to invoke the primitive can name a Marketing version. The product should establish authenticated service ownership before enforcing producer-specific contracts. | CAP-PFM-NOT-017 | See finding_evidence | debt |
FND-PFM-NOT-017 | low | The approved audience list names five personal selection forms, while code also accepts a system audience for HQ. The product should explicitly confirm that additional audience form. | CAP-PFM-NOT-003, CAP-PFM-NOT-013 | See finding_evidence | undocumented |
FND-PFM-NOT-018 | medium | The plan's scope describes an HQ bell experience, while its later decision directs HQ alerts to Slack only. The product should resolve the remaining inbox question and reconcile the scope wording. | CAP-PFM-NOT-013 | See finding_evidence | inconsistency |
FND-PFM-NOT-019 | low | Only Rhythm Administrator currently grants the HQ notification keys. Support staff lack those powers until Andrew decides the HQ access policy. | CAP-PFM-NOT-012 | See finding_evidence | undocumented |
FND-PFM-NOT-020 | medium | Platform does not own resource display names. The console supplies them for responsibility scope, but future external channels lack that lookup. The product should decide how resource labels enter those messages. | CAP-PFM-NOT-004, CAP-PFM-NOT-014 | See finding_evidence | debt |
FND-PFM-NOT-021 | low | The plan's assumption describes an earlier console milestone number, whereas the cited decision uses the current notification milestone. The product should reconcile that historical reference. | CAP-PFM-NOT-009 | See finding_evidence | inconsistency |
FND-PFM-NOT-022 | medium | Responsibility producer internals lie outside the registered code scope. Documentation and acceptance journeys support the integration contract, but delegation confirmation, transaction rollback and refusal compensation remain without bound owning-module proof. | CAP-PFM-NOT-014 | See finding_evidence | debt |
FND-PFM-NOT-023 | low | Nonproduction responsibility routes support a test delay header guarded by environment. The product should decide whether that route-level seam remains appropriate before broader adoption. | CAP-PFM-NOT-014 | See finding_evidence | undocumented |
FND-PFM-NOT-024 | low | Communication event partitions exist, but the examined as-built record reports retention and partition maintenance as unimplemented. The product should establish a retention policy and maintenance proof. | CAP-PFM-NOT-019 | See finding_evidence | debt |
FND-PFM-NOT-025 | medium | The requested planning brief is missing from the supplied specification checkout. This review relies on the authoring contract, draft and pinned evidence and cannot verify requirements unique to the absent brief. | MOD-PFM-NOT | See finding_evidence | undocumented |
FND-PFM-NOT-026 | medium | Some acceptance scenarios combine checks beyond their bound assertions. Existing bindings identify inspected evidence rather than complete execution proof. The product should strengthen composite and unbound scenarios before using them as design-entry proof. | MOD-PFM-NOT | See finding_evidence | debt |
FND-PFM-NOT-027 | medium | Definition retirement commits before workspace cancellation attempts. A cancellation error is logged without undoing retirement, so some unsettled requests can remain. The product should define recovery for partial retirement sweeps. | CAP-PFM-NOT-001 | See finding_evidence | defect |
FND-PFM-NOT-028 | high | Unexpected adapter exceptions are logged using their raw message. Content or credentials embedded in that message can violate the approved logging restriction despite passing normal-path log checks. The product should require redaction on the exception path. | CAP-PFM-NOT-008 | See finding_evidence | defect |
FND-PFM-NOT-029 | medium | Collapsed-item withdrawal cannot refresh wording when declared links have been redacted or the recipient is no longer eligible. Ownership and counts change while previous content remains. The product should decide how to present that stale-content boundary. | CAP-PFM-NOT-005 | See finding_evidence | debt |
FND-PFM-NOT-030 | medium | Communication recovery can resubmit after the ambiguity interval. A first submission that reached the provider but was not recorded can therefore duplicate delivery. The product should define its acceptable ambiguity policy before promising exactly-once sending. | CAP-PFM-NOT-018 | See finding_evidence | undocumented |
FND-PFM-NOT-031 | high | Sender provisioning adopts existing provider identities, and purge deletes adopted identities too. The examined sources do not establish exclusive cross-workspace ownership. The product should resolve reference ownership before deleting shared identities. | CAP-PFM-NOT-020 | See finding_evidence | debt |
FND-PFM-NOT-032 | medium | Allowed notification paths prove their own screens and behavior only. They do not establish repository-wide absence of communication interfaces or aliases, nor the internals of responsibility and provisioning producers. Those areas need their owning examination. | CAP-PFM-NOT-014, CAP-PFM-NOT-019, CAP-PFM-NOT-020 | See finding_evidence | undocumented |
FND-PFM-NOT-033 | medium | Caller-rendered purposes, Marketing-version content and changed-message behavior have code evidence without corresponding Andrew approval in the examined records. The product should record authority for these extensions before design relies on them. | CAP-PFM-NOT-016, CAP-PFM-NOT-017, CAP-PFM-NOT-019 | See finding_evidence | undocumented |
FND-PFM-NOT-034 | medium | Deployment defines a text-message queue but no text-message consumer. Queue and persistence checks therefore establish preparation rather than deployed text delivery. The product should plan and verify that consumer in the text milestone. | CAP-PFM-NOT-007 | See finding_evidence | debt |
FND-PFM-NOT-035 | medium | The changed-message operation accepts a service filter from its invocation and does not independently authenticate that service name. Filtering excludes different labels without establishing caller-exclusive ownership. The product should supply trusted caller identity before relying on that restriction. | CAP-PFM-NOT-019 | See finding_evidence | debt |
FND-PFM-NOT-053 | low | Communication-event history has no established partition-retention maintenance in the examined implementation. | TC-DAT-003, CAP-PFM-NOT-019 | Structured control evidence | control-gap |
FND-PFM-NOT-054 | medium | Notification-definition retirement logs failed workspace cancellation after commit without an established repair for the remaining requests. | TC-PI-004, TC-AVL-004, CAP-PFM-NOT-001 | Structured control evidence | control-gap |
FND-PFM-NOT-055 | medium | Communication recovery can resend a submission whose provider acceptance was not recorded, so repeated delivery can produce another message. | TC-PI-002, CAP-PFM-NOT-018 | Structured control evidence | control-gap |
FND-PFM-NOT-056 | medium | The changed-message service filter comes from the invocation without independent binding to the caller’s machine identity. | TC-AZ-002, TC-TEN-004, TC-IAM-006, CAP-PFM-NOT-019 | Structured control evidence | control-gap |
FND-PFM-NOT-057 | high | HQ dead-letter and retry responses expose retained channel content without the live customer-entry check required for History; the exception remains undecided. | TC-AZ-005, TC-TEN-002, TC-DAT-002, CAP-PFM-NOT-012, BR-CAP-PFM-NOT-012-07 | Structured control evidence | control-gap |
FND-PFM-NOT-058 | low | Association-template draft editing and archiving record neither the changing actor nor an audit entry. | TC-PI-005, CAP-PFM-NOT-016 | Structured control evidence | control-gap |
FND-PFM-NOT-059 | medium | Final delivery writes can precede failed notice-summary refresh, and redelivery or nightly reconciliation does not repair that final-state mismatch. | TC-PI-004, TC-AVL-004, SVC-PFM-NOT-notifications, WF-PFM-NOT-005 | Structured control evidence | control-gap |
FND-PFM-NOT-060 | high | Recorded provider feedback can survive a failed suppression write; duplicate detection then prevents replay from applying the missing recipient protection. | TC-PI-002, TC-PI-004, TC-PRV-004, WF-PFM-NOT-013, CAP-PFM-NOT-020 | Structured control evidence | control-gap |
FND-PFM-NOT-061 | medium | Template publication locks to allocate a number but does not recheck the earlier content, state and version snapshot against concurrent changes. | TC-PI-003, TC-PI-005, CAP-PFM-NOT-016 | Structured control evidence | control-gap |
| FND-PFM-NOT-036 | high | HQ dead-letter and retry responses include retained channel content without checking the active customer access grant required for History. Route permissions restrict entry, but the examined records do not resolve whether this operational content is exempt from customer access policy. The product should require a grant or redact operator responses before customer channels are adopted. | CAP-PFM-NOT-012, BR-CAP-PFM-NOT-012-07, OQ-PFM-NOT-007 | See finding_evidence | undocumented | | FND-PFM-NOT-037 | medium | Retiring a definition marks its open requests cancelled and settled but does not withdraw their notices or end their unsent deliveries. The notices keep counting as unread and still apply, and a queued Slack or text delivery of such a request is still sent, because the delivery consumer checks the notice and the expiry, not the request's outcome. The withdrawal routine the persistence comment names is never called. The product should decide whether retirement withdraws notices (OQ-PFM-NOT-008); the design records the gap in the registration workflow and the request lifecycle. | CAP-PFM-NOT-001, BR-CAP-PFM-NOT-001-11, WF-PFM-NOT-001, STATE-PFM-NOT-002, ADR-PFM-NOT-009 | See finding_evidence | defect | | FND-PFM-NOT-038 | low | The module asks no model a question, so the design has no inference directory and every contract, workflow and screen carries an empty inference list; the charter does not yet say so in the sentence the conventions require. The planning owner should add that sentence to the charter. | MOD-PFM-NOT | See finding_evidence | undocumented | | FND-PFM-NOT-039 | low | Rhythm HQ's read of a workspace's e-mail sender is a GET in the workspace lifecycle module that refreshes verification from the provider and writes the result, so a read changes state, and verification only refreshes when someone looks. The design should move the refresh into a communications operation (or a schedule) and keep the HQ read side-effect free. | CAP-PFM-NOT-020, BR-CAP-PFM-NOT-020-14, WF-PFM-NOT-015, STATE-PFM-NOT-014, SVC-PFM-NOT-communications | See finding_evidence | inconsistency | | FND-PFM-NOT-040 | low | The notice status cancelled and the delivery status deferred are declared in the closed vocabularies and excluded by queries, but no current path writes either. Deferral belongs to quiet hours and digests; cancelled notices are covered by superseded. The design should either assign them a path in the preference milestone or remove them. | STATE-PFM-NOT-003, STATE-PFM-NOT-005, CAP-PFM-NOT-007 | See finding_evidence | debt | | FND-PFM-NOT-041 | medium | The two pipelines resolve an uncertain provider hand-off in opposite ways. A notification delivery left sending is failed as ambiguous at nightly reconciliation and never resent; a communication message left submitting is closed as unknown after fifteen minutes and may be submitted again. No record chooses either policy for both. The product should choose one policy per kind of message (recommendation: keep never-resend for staff and HQ alerts, and require the provider's send report or an operator decision before resubmitting association e-mail). | ADR-PFM-NOT-010, WF-PFM-NOT-005, WF-PFM-NOT-011, CAP-PFM-NOT-008, CAP-PFM-NOT-018, FND-PFM-NOT-030 | See finding_evidence | inconsistency | | FND-PFM-NOT-042 | medium | A notification request item that fails processing on all eight receives reaches the dead-letter queue with no request record, because the queue entry was deleted on publication and the record is written only by the processing transaction. History and the request list therefore never show it, and nightly reconciliation only finds expired work among undispatched entries. Only the dead-letter alarm notices. The design should record a failed request (or expose the requests dead-letter queue to Rhythm HQ) so administrators see that a producer's announcement was lost. | CAP-PFM-NOT-008, CAP-PFM-NOT-011, WF-PFM-NOT-002, WF-PFM-NOT-003, SVC-PFM-NOT-notifications | See finding_evidence | undocumented | | FND-PFM-NOT-043 | low | Association template draft edits and archiving record no actor and no audit entry; only publication records who published. Notification wording overrides, by contrast, audit publication and deactivation in the security audit stream. The product should decide whether association template changes are audited the same way. | DOM-PFM-NOT-004, CAP-PFM-NOT-016, STATE-PFM-NOT-009 | See finding_evidence | undocumented |
| FND-PFM-NOT-044 | medium | Delivery results commit before their notice summary refresh. A failed refresh can leave a notice showing earlier progress; redelivery acknowledges a final delivery without repairing the summary, and nightly reconciliation does not scan final deliveries for this mismatch. | DOM-PFM-NOT-003, SVC-PFM-NOT-notifications, STATE-PFM-NOT-003, WF-PFM-NOT-005 | See finding_evidence | defect |
| FND-PFM-NOT-045 | high | Feedback saves the event and message summary before adding bounce or complaint suppressions. If suppression fails, the next receive recognizes the event as a duplicate and returns before trying suppression again. The address can remain deliverable despite the recorded permanent bounce or complaint. | DOM-PFM-NOT-005, STATE-PFM-NOT-012, WF-PFM-NOT-013, CAP-PFM-NOT-020 | See finding_evidence | defect |
| FND-PFM-NOT-046 | medium | Dormant persistence accepts identity activation without checking a phone challenge, and accepts digest delivery without checking collected count or window expiry. The draft confused proposed caller behavior with enforced guards. Future activation needs an approved orchestration path and proof of those checks. | STATE-PFM-NOT-006, STATE-PFM-NOT-008, CAP-PFM-NOT-015 | See finding_evidence | undocumented |
| FND-PFM-NOT-047 | low | The chain sheet reads the request through the workspace management route, including when opened from HQ, and expands already loaded delivery events locally. HQ list permission and its access grant do not by themselves establish authority for that separate management route. The draft incorrectly mapped expansion and retry to delivery and instance reads. | SCR-PFM-NOT-003, SCR-PFM-NOT-004, SCR-PFM-NOT-005 | See finding_evidence | inconsistency |
| FND-PFM-NOT-048 | medium | The design brief requested for this examination is absent from the supplied checkout. The authoring contract, existing design, planning layer and pinned implementation provide the available basis; requirements unique to the missing brief remain unknown. | MOD-PFM-NOT | See finding_evidence | undocumented |
| FND-PFM-NOT-049 | medium | Responsibility and provisioning producer internals, CRM compensation, external library internals and any enabling entity registration are not established by direct reads within this module scope. Their cited records describe contracts, but do not prove producer ordering, deployment grants or custom-field registration. The design marks producer anchors unknown and retains the existing adoption and ownership findings. | WF-PFM-NOT-006, WF-PFM-NOT-009, WF-PFM-NOT-014, DOM-PFM-NOT-003, DOM-PFM-NOT-004, DOM-PFM-NOT-005 | See finding_evidence | undocumented |
| FND-PFM-NOT-050 | medium | Owned-template partial saves retain omitted fields from the stored draft, not a fresh published-version read. Creation, draft replacement and publication use separate transactions, so later failure can leave unpublished or edited draft content. The design now describes those boundaries; the desired recovery policy remains open. | WF-PFM-NOT-014, STATE-PFM-NOT-009, CAP-PFM-NOT-016 | See finding_evidence | implementation gap | | FND-PFM-NOT-051 | medium | Template publication inspects active state and an optional expected version before its write transaction. It then locks the row to allocate a publication number but freezes the earlier snapshot without rechecking state or version. Concurrent archive or editing can invalidate the earlier check. Draft replacement does guard its expected version in the update; the publication race remains unresolved. | DOM-PFM-NOT-004, STATE-PFM-NOT-009, CAP-PFM-NOT-016 | See finding_evidence | implementation gap |
| FND-PFM-NOT-052 | medium | The final-receive loop still observes its invocation time budget. Messages it does not reach remain draft when the request is returned for dead-letter handling. The planning description expects untouched messages to be attempted on the final receive. The design records the implemented limit without changing that planning rule. | WF-PFM-NOT-011, CAP-PFM-NOT-018 | See finding_evidence | implementation gap |
| FND-PFM-NOT-062 | medium | The test specification for application notification declarations has incomplete detailed proof. Missing category cases and lifecycle rows require independent fixtures and assertions; existing composite cases supply only their named test assertions. | ATS-PFM-NOT-001, STATE-PFM-NOT-001 | See frontmatter evidence | coverage-gap | | FND-PFM-NOT-063 | medium | The test specification for transactional publication has incomplete detailed proof. Missing category cases and lifecycle rows require independent fixtures and assertions; existing composite cases supply only their named test assertions. | ATS-PFM-NOT-002 | See frontmatter evidence | coverage-gap | | FND-PFM-NOT-064 | medium | The test specification for recipient selection has incomplete detailed proof. Missing category cases and lifecycle rows require independent fixtures and assertions; existing composite cases supply only their named test assertions. | ATS-PFM-NOT-003 | See frontmatter evidence | coverage-gap | | FND-PFM-NOT-065 | medium | The test specification for recipient-specific rendering has incomplete detailed proof. Missing category cases and lifecycle rows require independent fixtures and assertions; existing composite cases supply only their named test assertions. | ATS-PFM-NOT-004 | See frontmatter evidence | coverage-gap | | FND-PFM-NOT-066 | medium | The test specification for repeated-event collapse has incomplete detailed proof. Missing category cases and lifecycle rows require independent fixtures and assertions; existing composite cases supply only their named test assertions. | ATS-PFM-NOT-005 | See frontmatter evidence | coverage-gap | | FND-PFM-NOT-067 | medium | The test specification for withdrawal and expiry has incomplete detailed proof. Missing category cases and lifecycle rows require independent fixtures and assertions; existing composite cases supply only their named test assertions. | ATS-PFM-NOT-006, STATE-PFM-NOT-002 | See frontmatter evidence | coverage-gap | | FND-PFM-NOT-068 | medium | The test specification for notification routing and delivery has incomplete detailed proof. Missing category cases and lifecycle rows require independent fixtures and assertions; existing composite cases supply only their named test assertions. | ATS-PFM-NOT-007, STATE-PFM-NOT-003, STATE-PFM-NOT-005 | See frontmatter evidence | coverage-gap | | FND-PFM-NOT-069 | medium | The test specification for notification recovery and retention has incomplete detailed proof. Missing category cases and lifecycle rows require independent fixtures and assertions; existing composite cases supply only their named test assertions. | ATS-PFM-NOT-008 | See frontmatter evidence | coverage-gap | | FND-PFM-NOT-070 | medium | The test specification for the personal inbox has incomplete detailed proof. Missing category cases and lifecycle rows require independent fixtures and assertions; existing composite cases supply only their named test assertions. | ATS-PFM-NOT-009, STATE-PFM-NOT-004, BR-CAP-PFM-NOT-009-09 | See frontmatter evidence | coverage-gap | | FND-PFM-NOT-071 | medium | The test specification for selection and delivery explanations has incomplete detailed proof. Missing category cases and lifecycle rows require independent fixtures and assertions; existing composite cases supply only their named test assertions. | ATS-PFM-NOT-010 | See frontmatter evidence | coverage-gap | | FND-PFM-NOT-072 | medium | The test specification for workspace activity review has incomplete detailed proof. Missing category cases and lifecycle rows require independent fixtures and assertions; existing composite cases supply only their named test assertions. | ATS-PFM-NOT-011, BR-CAP-PFM-NOT-011-08 | See frontmatter evidence | coverage-gap | | FND-PFM-NOT-073 | medium | The test specification for HQ investigation and retry has incomplete detailed proof. Missing category cases and lifecycle rows require independent fixtures and assertions; existing composite cases supply only their named test assertions. | ATS-PFM-NOT-012 | See frontmatter evidence | coverage-gap | | FND-PFM-NOT-074 | medium | The test specification for operational alerts has incomplete detailed proof. Missing category cases and lifecycle rows require independent fixtures and assertions; existing composite cases supply only their named test assertions. | ATS-PFM-NOT-013 | See frontmatter evidence | coverage-gap | | FND-PFM-NOT-075 | medium | The test specification for responsibility announcements has incomplete detailed proof. Missing category cases and lifecycle rows require independent fixtures and assertions; existing composite cases supply only their named test assertions. | ATS-PFM-NOT-014, BR-CAP-PFM-NOT-014-09 | See frontmatter evidence | coverage-gap | | FND-PFM-NOT-076 | medium | The test specification for stored delivery configuration has incomplete detailed proof. Missing category cases and lifecycle rows require independent fixtures and assertions; existing composite cases supply only their named test assertions. | ATS-PFM-NOT-015, STATE-PFM-NOT-006, STATE-PFM-NOT-007, STATE-PFM-NOT-008, BR-CAP-PFM-NOT-015-13 | See frontmatter evidence | coverage-gap | | FND-PFM-NOT-077 | medium | The test specification for association content publication has incomplete detailed proof. Missing category cases and lifecycle rows require independent fixtures and assertions; existing composite cases supply only their named test assertions. | ATS-PFM-NOT-016, STATE-PFM-NOT-009 | See frontmatter evidence | coverage-gap | | FND-PFM-NOT-078 | medium | The test specification for communication submission has incomplete detailed proof. Missing category cases and lifecycle rows require independent fixtures and assertions; existing composite cases supply only their named test assertions. | ATS-PFM-NOT-017, STATE-PFM-NOT-010 | See frontmatter evidence | coverage-gap | | FND-PFM-NOT-079 | medium | The test specification for communication sending has incomplete detailed proof. Missing category cases and lifecycle rows require independent fixtures and assertions; existing composite cases supply only their named test assertions. | ATS-PFM-NOT-018, STATE-PFM-NOT-011, STATE-PFM-NOT-015 | See frontmatter evidence | coverage-gap | | FND-PFM-NOT-080 | medium | The test specification for communication outcomes has incomplete detailed proof. Missing category cases and lifecycle rows require independent fixtures and assertions; existing composite cases supply only their named test assertions. | ATS-PFM-NOT-019, STATE-PFM-NOT-012 | See frontmatter evidence | coverage-gap | | FND-PFM-NOT-081 | medium | The test specification for recipient and sender safeguards has incomplete detailed proof. Missing category cases and lifecycle rows require independent fixtures and assertions; existing composite cases supply only their named test assertions. | ATS-PFM-NOT-020, STATE-PFM-NOT-013, STATE-PFM-NOT-014 | See frontmatter evidence | coverage-gap | | FND-PFM-NOT-082 | medium | Many retained capability scenarios combine assertions from several executable files. Suite bindings identify contributing assertions rather than complete execution of every composite precondition and step; an assertion-by-assertion qualification run remains required. | ATS-PFM-NOT-001, ATS-PFM-NOT-002, ATS-PFM-NOT-003, ATS-PFM-NOT-004, ATS-PFM-NOT-005, ATS-PFM-NOT-006, ATS-PFM-NOT-007, ATS-PFM-NOT-008, ATS-PFM-NOT-009, ATS-PFM-NOT-010, ATS-PFM-NOT-011, ATS-PFM-NOT-012, ATS-PFM-NOT-013, ATS-PFM-NOT-014, ATS-PFM-NOT-015, ATS-PFM-NOT-016, ATS-PFM-NOT-017, ATS-PFM-NOT-018, ATS-PFM-NOT-019, ATS-PFM-NOT-020 | See frontmatter evidence | coverage-gap | | FND-PFM-NOT-083 | medium | Several feature-level chains have specification coverage but no executable file that performs the complete chain. Component capability tests do not supply an executable feature binding by themselves. | FAS-PFM-NOT-01, FAS-PFM-NOT-02, FAS-PFM-NOT-03, FAS-PFM-NOT-04, FAS-PFM-NOT-05, FAS-PFM-NOT-06, FAS-PFM-NOT-07 | See frontmatter evidence | coverage-gap | | FND-PFM-NOT-084 | medium | The added related-capability chains have no inspected executable suite performing their complete sequence. They remain proposed until a cumulative workflow suite supplies the missing assertions. | ATS-PFM-NOT-001-14, ATS-PFM-NOT-002-09, ATS-PFM-NOT-003-09, ATS-PFM-NOT-004-05, ATS-PFM-NOT-005-10, ATS-PFM-NOT-006-10, ATS-PFM-NOT-007-10, ATS-PFM-NOT-008-11, ATS-PFM-NOT-009-10, ATS-PFM-NOT-010-07, ATS-PFM-NOT-011-07, ATS-PFM-NOT-012-06, ATS-PFM-NOT-013-10, ATS-PFM-NOT-014-07, ATS-PFM-NOT-015-12, ATS-PFM-NOT-016-15, ATS-PFM-NOT-017-15, ATS-PFM-NOT-018-14, ATS-PFM-NOT-019-09, ATS-PFM-NOT-020-15 | See frontmatter evidence | coverage-gap | | FND-PFM-NOT-085 | medium | Combined domain guarantees still need complete assertion coverage for failure-path logging, publication races, historical purge guards, rollback objects, opt-out exceptions and sender selection. The invariant matrix identifies each guarantee and its scenario or remaining gap. | INV-DOM-PFM-NOT-003-11, INV-DOM-PFM-NOT-004-06, INV-DOM-PFM-NOT-004-09, INV-DOM-PFM-NOT-005-01, INV-DOM-PFM-NOT-005-06, INV-DOM-PFM-NOT-005-11, INV-DOM-PFM-NOT-005-12 | See frontmatter evidence | coverage-gap |
Open Questions
| id | question | reason | options | recommendation | affects |
|---|---|---|---|---|---|
OQ-PFM-NOT-001 | Should assignment ending be announced when the assignment notice never arrived? | The current sequence can present an ending without a preceding announcement. | Withhold the ending when assignment delivery never occurred; or preserve unconditional ending notices. | The product should withhold that ending until the assignee has received an assignment announcement. | CAP-PFM-NOT-014, JNY-PFM-NOT-002 |
OQ-PFM-NOT-002 | Which HQ roles should read and retry notifications? | Current keys belong only to Rhythm Administrator, leaving support access undecided. | Allow support History with grants and administrator retry; or retain administrator-only access. | The product should grant support history reads with active customer access and keep retry restricted to administrators. | CAP-PFM-NOT-012 |
OQ-PFM-NOT-003 | Should HQ also have a console inbox for operational alerts? | The approved scope and later Slack-only decision describe different experiences. | Retain Slack-only delivery; or add a console inbox for HQ recipients. | The product should retain Slack-only routing unless Andrew approves an additional inbox. | CAP-PFM-NOT-013, FEAT-PFM-NOT-05 |
OQ-PFM-NOT-004 | How should external channels name a responsibility resource? | Platform lacks resource display names that the console can resolve. | Include producer-supplied display labels; resolve labels from owning modules during rendering; or omit external resource names. | The product should include the resource display label in producer data before external notification channels begin. | CAP-PFM-NOT-004, CAP-PFM-NOT-014 |
OQ-PFM-NOT-005 | How should concurrent workspaces share a sending lane? | A large campaign can consume capacity ahead of other active senders. | Allocate equal active-workspace shares; weight shares by plan or volume; or retain arrival-order processing. | The product should allocate equal shares among active workspaces and lend unused capacity to other senders. | CAP-PFM-NOT-018 |
OQ-PFM-NOT-006 | Should ending delegated cover notify the delegate? | A delegate can otherwise miss the removal of responsibilities they were covering. | Send an ending announcement; or retain the current silent ending. | The product should announce delegation ending as part of the planned producer adoption. | CAP-PFM-NOT-014 |
OQ-PFM-NOT-007 | Should operator delivery responses expose customer content without an access grant? | Dead-letter and retry operations return channel content outside the History grant boundary. | Require an active workspace grant for content; redact operator responses to status and identity only; or approve global HQ content access. | The product should redact global operator lists and require an active grant for customer content. | CAP-PFM-NOT-012 |
OQ-PFM-NOT-008 | Should retiring a definition withdraw its open notices as a cancel does? | Retirement today settles open requests but leaves their notices unread and applicable and lets their queued deliveries send, so people keep acting on a kind of notice the application no longer declares. | Withdraw as a cancel (unsent deliveries cancelled, notices no longer apply); leave delivered notices but cancel unsent deliveries; or keep today's behaviour and only settle the requests. | The product should treat retirement as a withdrawal of each open request, run it through the same withdrawal path, and retry or report workspaces where the sweep failed. | CAP-PFM-NOT-001, CAP-PFM-NOT-006, WF-PFM-NOT-001, FND-PFM-NOT-037 |
OQ-PFM-NOT-009 | Which consistency and recovery gaps must close before implementation preparation? | Summary refresh, feedback protection, template publication and final-receive work have separate failure boundaries that the draft understated. | Require repairs before preparation; prepare explicit corrective work with acceptance coverage; or approve the current limits. | The product should prepare corrective work with failure and race scenarios, while treating unprotected feedback and publication races as required fixes. | FND-PFM-NOT-044, FND-PFM-NOT-045, FND-PFM-NOT-050, FND-PFM-NOT-051, FND-PFM-NOT-052 |