• Security model is minimal and arguably under-specified, especially for registration and access control.
• Error handling is inconsistently defined:
o some operations specify mandatory failure conditions,
o others leave too much to implementation-specific behavior.
• Language/locale handling needs tighter normative definition:
o expected locale format,
o fallback behavior,
o required behavior if translation is unavailable.
• Persistence/recovery behavior is only lightly defined despite Persistent attribute.
• Receiver selection/actionee resolution should be specified more rigorously, especially in hierarchy fallback scenarios.

From William (Bill) Beavin's AB comments on ALMAS 1.5 RTF

Clear spelling/typing errors
• ALert in title and headers likely intentional branding, but should be confirmed.
• alter requiring confirmation → should be alert.
• specifys → specifies
• handing is required → likely handling is required
• nonull → non-null
• AlertTemaplate → AlertTemplate
• templateto → template to
• constraind → constrained
• specifc → specific
• Dtaa Model → Data Model
• TempalteIDSet → TemplateIDSet
• mulit-language → multi-language
• report and technical or editing issues → likely report any technical or editing issues
• it is not generated should begin with It
• 7.1to 7.3 → missing space: 7.1 to 7.3
Grammar/style problems
• Identified whether should be Identifies whether in AlertReport.
• Class provided by registering... is awkward; several class descriptions need rewriting.
• This is the ALMAS a general-purpose... is ungrammatical.
• The receiver may decide to take an explicit action in mitigation to... should likely be in mitigation of.
• through being handled / through being cancelled is awkward but understandable.
• Several sentences are run-on or missing articles.
Formatting and presentation issues
• Section numbering spacing is inconsistent, e.g. 6.1.1ALMASNotificationListener, 6.3.1ALMASConfiguration.
• Some tables appear malformed or partially corrupted.
• Bullet formatting is inconsistent in multiple sections.
• Some enum/value presentations use braces, some use prose, some use tables.
• “This page intentionally left blank.” pages are present and fine, but surrounding pagination text is somewhat inconsistent.
• Trademark symbol formatting is noisy in the title and front matter.
Reference and cross-reference issues
• Footnote [1] is cited in Section 4.2, but the footnote text formatting is weak and should be validated in final layout.
• Section references are mostly present, but some wording like “later in this document” should be replaced by precise section references where possible.
• GraphQL is cited to Facebook rather than the current stewardship context; not necessarily wrong, but worth verifying.
• OTEL 1.38.0 is listed as a normative reference, but the document does not define clear conformance obligations tied to it.

From William (Bill) Beavin's AB comments on ALMAS 1.5 RTF

• GraphQL section contains several wording/mapping errors and appears less polished than the others.
• DDS section has malformed bullet formatting and some terminology drift (TempalteIDSet, DDS_XTYPES explanation formatting).
• CORBA/COM/DDS rationale sections say “entire PIM interface” support, but the actual detail level is uneven.

From William (Bill) Beavin's AB comments on ALMAS 1.5 RTF

• Section 2 says implementations must conform to one or more middleware PSMs in Chapters 8–11 and XML PSMs in 7.1–7.3. Later text says template/XML use is “effectively optional.”
• Level 2 Producer says it “Invokes: ALMASConfiguration interface and any of the ALMASProducer and ALMASManager interface methods,” but later says producer configuration may alternatively be centralized. This should be reconciled normatively.

From William (Bill) Beavin's AB comments on ALMAS 1.5 RTF

• State enum lists TimedOut, while earlier text lists Timed_Out.
• Constraint says Information/Warning alerts cannot be Handled, but lifecycle/removal text should more explicitly align with that rule everywhere.
• Section 6.3 says “Any alert is removed when cancelled,” but 6.1.2 says deletion notifications are not generated and deletion only occurs from a non-current state; terminology around Cancelled versus actual deletion should be tightened.

From William (Bill) Beavin's AB comments on ALMAS 1.5 RTF
• RemoveAlertsWithDynamicMessageData heading shows (String, String) but parameters list three inputs: CancellerID, DataType, DataValue.
• RaiseAlertWithDynamicData parameter typing appears corrupted:
o operation title includes DynamicMessageDataTypeSet, AlertDataExtraAttributesTypeSet
o parameter list ends with DynamicMessages: AlertDataExtraAttributesTypeSet
• UpdateDynamicMessageData(int, String, DynamicMessageData) uses parameter name ObjectValue, but summary says OldData identifies what changes.
• GetAllTemplateIDs mentions Filter non-null behavior, but type/null semantics are not specified consistently.
• GetTemplate(int) is described differently in DDS mapping table than in PIM table.
• RaiseAlertFromData says a temporary AlertTemaplate is created — typo, but also conceptually should clarify whether full template validation applies.

From Willian (Bill) Beavin's AB comments on ALMAS 1.5 RTF

• Product name appears inconsistently as:
o ALert MAnagement Service
o ALert Management Service
o Alert Management Service
o ALMAS
• “Categorisation” and “Categorization” are both used.
• “Acknowledgement” and “Acknowledgment” style is mixed in places.
• Timed_Out appears once, but enum later uses TimedOut.
• RaiseAlertFromOverrides text refers to overriding Message, but the model uses StaticMessage/MessageText.