Oracle OPERA 5 · PMS Power Index

Composite score: 26.3 / 100 (published snapshot v2026.2, 2026-06-12)

Oracle OPERA 5 scores 26.3 out of 100 on the PMS Power Index. Evidence-backed diagnostic across ten API capabilities. Vendor-neutral. Open to dispute.

Scores by capability

Marketplace coverage

Score: 3 of 9 (Limited). Weight 10%.

First scorer rationale: Anchor_6 requires 50 to 150 certified integrations across 6+ categories. Category breadth is described (OXI, OWS, IFC8/FIAS, XML_POS covering CRS, RMS, channel, loyalty, hardware, POS), but no certified-integration count is publicly available and no self-service marketplace exists — all integrations are mediated through Oracle sales and partner-side OXI implementation. Without an evidenced count, the anchor_6 numeric threshold is not cleared. Note: Oracle's published validated-interfaces documentation covers "OPERA 5 and OPERA Cloud" combined with no OPERA 5-only or OXI-only certified count; current documentation redirects to the OPERA Cloud Marketplace. [Provenance note — 2026-08-09] "The assertion that all integrations are mediated through Oracle sales and partner-side OXI implementation rests on the single evidence row on this dimension, which is tier T3 sourced to a third-party analysis publication. That provenance is recorded here. The same third-party article is also the sole evidence row on this record's AI Readiness dimension. No Oracle-controlled source is currently evidenced on this dimension. The score is unchanged at 3: the anchor-6 threshold of 50 to 150 certified integrations across six or more categories is not evidenced, and Oracle's published validated-interfaces documentation covers OPERA 5 and OPERA Cloud combined without an OPERA 5-only count. The absence of a mapped Oracle-controlled source on this dimension is disclosed in accordance with methodology §8b, and the expanded evidence-search scope has not yet been applied to this vendor record." [Evidence capture — 2026-08-09] Oracle-controlled primary documentation has been captured on this dimension, which previously rested solely on a third-party source. Oracle documents the OXI message architecture, code mapping between OPERA and external system codes, and named custom interfaces including HOLIDEX and MARSHA with sample request messages. The score is unchanged at 3. The captured evidence establishes documented integration architecture and named interfaces, and does not alter the anchor-6 position. Anchor 6 requires 50 to 150 certified integrations across at least six categories. Category breadth is documented, but no certified integration count is published for OPERA 5 or for OXI specifically, as recorded in the note above regarding Oracle's validated-interfaces documentation covering OPERA 5 and OPERA Cloud combined. Without an evidenced count the anchor-6 numeric threshold is not cleared. The provenance position recorded on 2026-08-09 is superseded to the extent that Oracle-controlled evidence is now held on this dimension; the absence of a published count remains the operative reason for the score.

• OPERA 5 supports integrations via OXI (CRS, RMS, channel managers, loyalty, group systems), OWS (web booking and guest services), IFC8/FIAS (local hardware including door locks, PBX, IPTV, minibars) and XML_POS (food and beverage). The integration surface is broad by category but requires on-premise installation, Oracle-licensed interface modules, and partner-side OXI implementation. No self-service marketplace exists, all integrations are mediated through Oracle sales, and no certified-integration count is publicly available for OPERA 5 — anchor_6's numeric threshold (50–150 certified integrations) is therefore not cleared on the available evidence. https://www.altexsoft.com/blog/opera-pms-integration/
• Oracle documents the OXI message architecture: an external system posts a message to OXI, the message enters a queue, and the message is processed. OXI provided code mapping between OPERA codes and external system codes for room types, rate codes and package codes. OXI XML messages transmit a full object in XML format, as distinct from business event messages which transmit key-value pairs in JSON. Oracle documents OXI Interfaces including named custom interfaces such as HOLIDEX and MARSHA with sample request messages for reservation creation, availability requests and block creation. https://docs.oracle.com/en/industries/hospitality/integration-platform/ohipu/c_opera_xchange_interface_oxi.htm

What you can control via the API

Score: 3 of 9 (Limited). Weight 14%.

First scorer rationale: Anchor_6 requires both core reservation lifecycle AND folio posting to be writable. OWS (SOAP/.NET) covers availability, room management, guest profiles, reservations and membership — the reservation side is evidenced — but folio posting is not named anywhere in the public OWS surface. The compound anchor_6 requirement is therefore not cleared, matching anchor_3 (basic reservation create/retrieve; folios, rate plans and housekeeping not writable).

• OPERA 5 exposes operational functions via OPERA Web Services (OWS), a SOAP/HTTP service layer running on Microsoft .NET Framework under Windows IIS. The documented OWS surface covers availability, room management, guest profiles, reservations and membership. Folio posting is not named in the public OWS surface, and no REST API exists on OPERA 5. Programmatic control over reservation-related operations is evidenced, but the anchor_6 compound requirement (core reservation lifecycle AND folio posting writable) is not cleared on the available evidence. https://docs.oracle.com/cd/E90572_01/index.html

Real-time updates and webhooks

Score: 3 of 9 (Limited). Weight 13%.

First scorer rationale: OXI provides asynchronous XML queue-based messaging with configurable sleep intervals — functional for batch sync but not real-time. No webhook, WebSocket, or streaming API exists. Oracle documents OXI as the legacy floor with REST as the improvement path.

• OPERA 5 uses OXI (OPERA Xchange Interface) for event-driven data exchange — an asynchronous XML messaging middleware layer based on HTNG and Open Travel standards. OXI operates via queue-based message routing with configurable sleep intervals between polling cycles; it is not a real-time push or streaming system. There is no WebSocket, webhook, or streaming API equivalent. Integrators must poll or wait for queue processing. Oracle explicitly documents migration from OXI to REST as an improvement path, indicating OXI is the legacy floor. https://docs.oracle.com/en/industries/hospitality/integration-platform/ohipu/c_opera_xchange_interface_oxi.htm

Readiness for AI agents

Score: 0 of 9 (Absent). Weight 12%.

First scorer rationale: No AI, ML, agent-callable surface, embeddings, or LLM-friendly data layer exists anywhere in OPERA 5. Oracle's AI investments are exclusive to OPERA Cloud. OPERA 5 is in sustaining support with no feature development. [Anchor-condition disclosure — 2026-08-09] "A review of this dimension against the anchor text establishes that the published score of 0 is supported on one of three anchor-0 conditions, and that the anchor immediately above is not reachable for this product. The position is disclosed here in full. Anchor 0 requires three conditions: no structured API; no public schema; and not callable by an agent without bespoke integration work. The third condition is established. Integration requires on-premise installation of OWS or OXI, Oracle PartnerNetwork membership and procurement of interface licences, with no sandbox, no discovery endpoint, no tool schema and no function-calling surface. Time to first authenticated call is measured in weeks. The first condition is not established. OPERA Web Services is a SOAP service layer exposing documented, typed operations. The defensible finding is that no REST or JSON API exists, which is not what the anchor states. The second condition is contradicted by evidence on this record. Oracle publishes the OPERA Web Services specification library openly on Oracle Help Center, with WSDL SOAPAction and XSD schema references per operation, evidenced at the row captured 2026-08-09. The developer_experience and documentation_quality rows on this record separately record that Oracle publishes WSDL files and SOAP XML samples. The sole row supporting this dimension asserts absence of a 'structured schema for AI consumption', a narrower claim than the anchor condition, and the rationale above did not carry that qualifier. Anchor 3 is not reachable for this product. Its text opens 'REST API exists and is documented', a precondition that the T1 evidence on this record expressly negates on two separate dimensions. A product exposing only SOAP services cannot satisfy anchor 3 as drafted, irrespective of the quality of that surface or of its AI readiness. The product therefore falls between anchors 0 and 3 as those anchors are currently drafted. This is a rubric-drafting matter rather than an evidential gap: no further evidence gathering resolves it. In accordance with the Evidence Reconstruction Principle the published score is not revised mid-cycle. The score is unchanged at 0 and the defect is disclosed here. Determination is referred to the next scheduled review, where the anchor text must be considered for every non-REST vendor rather than for this record alone. Recorded alongside the matter already logged on this vendor's Production Reliability dimension concerning the applicability of vendor-published status page and uptime criteria to on-premise products." [Evidence capture — 2026-08-09] Oracle-controlled primary documentation has been captured on this dimension, which previously rested solely on a third-party source. Oracle documents that REST APIs, the getBusinessEvents operation and streaming services are OPERA Cloud capabilities, and positions OXI as an integration approach from which a partner may migrate to REST, stating that greater functionality is available with the REST APIs. Oracle separately documents its Hospitality Adapter as exposing all inbound and outbound service structure using REST only with no SOAP support, and as integrating OPERA Cloud Property Management. This evidence establishes the structural boundary from Oracle's own documentation rather than by third-party inference: the modern REST, streaming and business-event surface is documented for OPERA Cloud, and OPERA 5's documented integration path is OXI, with migration to REST presented as the improvement. The score is unchanged at 0. The captured evidence bears on the third anchor-0 condition, that the product is not callable by an agent without bespoke integration work, which is established. It does not alter the disclosure recorded on 2026-08-09 in respect of the other two anchor-0 conditions: the first, no structured API, is not established, because OPERA Web Services is a SOAP service layer exposing documented typed operations; and the second, no public schema, is contradicted by evidence on this record, Oracle publishing the OPERA Web Services specification library openly with WSDL and XSD references. The position that anchor 3 is not reachable for this product, its text requiring that a REST API exists, is also unaffected. Both remain disclosed and referred to the next scheduled review, at which the anchor text must be considered for every non-REST vendor. The absence of AI-specific capability is by its nature not a matter on which a vendor publishes documentation. That element of the assessment continues to rest on the third-party row, which is retained at tier T3 and is now corroborating rather than sole.

• OPERA 5 is an on-premise SOAP/XML system with no documented AI, machine learning, agent-callable surface, embeddings endpoint, or LLM-friendly data access layer. No MCP server, structured schema for AI consumption, or function-calling capability has been identified in Oracle's published OPERA 5 documentation. Oracle's AI investments including Nor1 and OHIP are exclusive to OPERA Cloud. OPERA 5 is in sustaining support and is not receiving feature development. https://www.altexsoft.com/blog/opera-pms-integration/
• Oracle publishes the OPERA Web Services specification library openly on Oracle Help Center without authentication. The service specifications document typed operations with WSDL SOAPAction references and XSD schema references per operation across Reservation, Availability, Information and other services. The runtime WSDL endpoint is served from each customer's own IIS installation, so no single Oracle-hosted runtime WSDL URL exists, but the operation-level schema documentation, message structures and XSD references are published publicly by Oracle. https://docs.oracle.com/cd/E90572_01/index.html
• Oracle documents the Oracle Hospitality Adapter as integrating OPERA Cloud Property Management with other Oracle and non-Oracle applications, stating that all inbound and outbound service structure is exposed using REST only, with no SOAP support, and that both inbound and outbound services leverage the REST APIs exposed by the Oracle Hospitality Integration Platform. The adapter is documented for OPERA Cloud and requires registration in the OHIP Customer Portal. https://docs.oracle.com/en/cloud/paas/integration-cloud/hospitality-adapter/oracle-hospitality-adapter-capabilities.html
• Oracle documents the migration position between OXI and REST, stating that an integration can be moved from OXI to REST with greater functionality available with the REST APIs. Oracle documents that for messages sent to an external application the REST APIs use the same Business Event functionality as OXI, with two approaches available, polling for business events using the getBusinessEvents operation or using streaming services. The REST APIs, the getBusinessEvents operation and streaming services are documented as OPERA Cloud capabilities. OXI XML messages transmit a full object in XML format, as distinct from business event messages which transmit key-value pairs in JSON. https://docs.oracle.com/en/industries/hospitality/integration-platform/ohipu/c_opera_xchange_interface_oxi.htm

Data model and multi-property design

Score: 3 of 9 (Limited). Weight 10%.

First scorer rationale: OXI exchanges reservations, profiles, rates and inventory but multi-property is implemented as separate OXI instances configured per property, with no unified tenant model, no shared guest profile across properties, and no cross-property API endpoint. The evidence itself describes anchor_3 — multi-property exists as separate instances, reporting requires export — not anchor_6, which requires a shared guest profile and a true multi-property hierarchy. [Evidence capture — 2026-08-09] Oracle-controlled primary documentation has been captured on this dimension, which previously rested solely on a third-party source. Oracle publishes the OPERA Exchange Interface documentation library openly, including Reservation and Profile XML Specifications and documentation on retrieving profile information from remote systems, and documents the OPERA 5 business-event architecture in detail, including per-module and per-data-element configuration, the business event outqueue table, message status tracking and resynchronisation. The score is unchanged at 3. The captured evidence establishes that the OXI data exchange is well documented by Oracle, and does not alter the anchor-6 position. Anchor 6 requires a shared guest profile across properties, a multi-property hierarchy in the data model, and a standard reporting API. The documentation confirms that external systems are configured and activated individually per interface, that profile data is exchanged by message rather than held in a shared cross-property profile entity, and that profile lookup from remote systems operates as an outbound call to a configured external database rather than as a native cross-property profile. Multi-property therefore remains implemented as separate configured instances, matching anchor 3, and no standard reporting API is evidenced.

• OPERA 5 exchanges reservations, rates, guest profiles, inventory, groups, events, membership, activities, and statistical data via OXI XML schemas aligned to HTNG and Open Travel standards. Chain-level and multi-property data management is implemented as separate OXI configurations per property: no unified tenant model, no shared cross-property guest profile, and no cross-property API endpoint exists. Multi-property is therefore present as separate instances rather than as a true hierarchy with portable reporting — matching anchor_3 of the data model depth rubric, not anchor_6. https://e360hospitality.com/opera-pms-technical/simplifying-opera-pms-api-integration/
• Oracle documents the OPERA 5 business-event architecture underlying OXI. Business events are configured per module and per data element, for example a NEW PROFILE event on the Profile module with named data elements activated individually. Activated data elements form part of the business event record created when a user performs the corresponding activity. OXI reads from the business event outqueue table and constructs the outbound message. External systems are configured individually and activated per interface. Message status is tracked in the OXI message status table, and resynchronisation of reservations, profiles, rate codes, blocks and restrictions is documented as a separate operation. https://docs.oracle.com/cd/E98457_01/opera_5_6_core_help/opera_setup_for_the_oxi_interface.htm
• Oracle publishes the OPERA Exchange Interface documentation library openly, comprising Reservation and Profile XML Specifications, communication-mechanism documentation for HTTP and HTTPS retrieval of business event XML, general configuration and user guides for all OPERA Exchange interfaces, and documentation on retrieving profile information from remote systems. Interface XML files are downloadable per specification. The library is published without authentication. https://docs.oracle.com/cd/E91116_01/index.html

Developer tooling and sandbox

Score: 3 of 9 (Limited). Weight 10%.

First scorer rationale: No self-service portal, no sandbox, no REST API, no open-source specs. Integration requires Oracle PartnerNetwork membership, licence procurement, and on-premise environment setup. Time-to-first-call measured in weeks.

• OPERA 5 integration requires on-premise OWS or OXI installation, Oracle PartnerNetwork membership, and procurement of interface licences through Oracle sales. There is no self-service developer portal, no public sandbox, no REST API, and no open-source specifications. Developer documentation is available on Oracle Help Center but is structured around WSDL files and SOAP patterns requiring J2SE or .NET tooling. Time-to-first-call is measured in weeks, not hours, due to environment setup and Oracle engagement requirements. https://docs.oracle.com/cd/E53547_01/docs/E89601-01.pdf

Uptime and operational discipline

Score: 0 of 9 (Absent). Weight 9%.

First scorer rationale: Anchor_0 — no public status page and no published SLA — is the exact state confirmed by Oracle's own product-support documentation for OPERA 5. There is no Oracle-managed uptime commitment for on-premise deployments, the 99.9% OCI SLA does not apply, uptime depends entirely on the hotel's own hardware, network and IT operations, and version 5.5 sits on Sustaining Support with 5.6 on Premier Support as Oracle's final on-premise release. Both anchor_6 criteria (automated status page with 90-day history + published 99.5%+ SLA) are therefore confirmed absent. [Provenance correction — 2026-08-09] The statement above that the anchor-0 position is confirmed by Oracle's own product-support documentation is withdrawn. The only evidence row on this dimension at the time that statement was written was tier T3, sourced to a third-party partner publication, and no Oracle-controlled source was cited. The provenance claim was incorrect. The evidential position is now stated accurately. Oracle's Lifetime Support Policy, published by Oracle, establishes the Premier, Extended and Sustaining Support framework and is evidenced at the row captured 2026-08-09. The product-specific transition of OPERA Property 5.5 from Premier to Sustaining Support, and the availability of 5.6 under Premier Support, is evidenced from a third-party partner publication at tier T3. An Oracle-published document naming OPERA Property 5.5 and 5.6 with their support-tier dates was located and is evidenced at the row captured 2026-08-09 from the Oracle Lifetime Support Policy for Oracle Applications, which records OPERA 5.5 Premier Support ending October 2021 with Sustaining Support indefinite, and OPERA 5.6 Premier Support ending December 2027. The score is unchanged at 0. Both anchor-0 conditions are met in substance: no vendor-published status page exists for OPERA 5, and no vendor uptime commitment applies, because the product is deployed on customer-controlled infrastructure. The contractual 99.9% Oracle Cloud Infrastructure service level does not extend to on-premise deployments. Recorded for the next scheduled methodology review: whether Production Reliability, whose anchor criteria concern vendor-published status pages and vendor uptime commitments, is applicable as drafted to on-premise products where the deployment model places availability under customer control. This is a rubric-applicability question and is not determined here. [Tier note — 2026-08-09] "The preceding block records the product-specific support-tier dates as evidenced at tier T3. Following the location of Oracle's published Lifetime Support Policy (Applications), those dates are evidenced at tier T1 from Oracle's own document: Hospitality OPERA 5.5, generally available October 2015, Premier Support ended October 2021, no Extended Support, Sustaining Support indefinite; Hospitality OPERA 5.6, generally available April 2019, Premier Support ends December 2027, no Extended Support, Sustaining Support indefinite. The third-party publication is retained as corroborating evidence at tier T3. The score is unchanged at 0." [Expanded-scope search — 2026-08-09] The anchor-0 position is now confirmed from an Oracle-published source. Oracle's Technical Support Policies, effective 7 August 2026, apply across Oracle software product lines including on-premise products, provide reasonable-efforts response language at Severity 1 only, state no response-time target at Severities 2 to 4, and contain no availability or uptime commitment. The absence of a published service level for on-premise deployments therefore no longer rests on third-party or inferred evidence. The score is unchanged.

• OPERA 5 runs on-premise on customer-managed infrastructure: Oracle's 99.9% OCI SLA does not apply, and uptime and reliability depend entirely on the hotel's own hardware, network and IT operations. Version 5.5 transitioned from Premier to Sustaining Support in November 2021; version 5.6 remains on Premier Support but is Oracle's final on-premise release, and Oracle is actively migrating all OPERA 5 customers to OPERA Cloud via the OPERA Cloud Migration Portal. No public status page and no Oracle-managed uptime commitment exists for on-premise deployments — the exact anchor_0 state ("no public status page; no published SLA"). Both anchor_6 criteria are confirmed absent by the vendor's own product-support documentation. https://mastelhospitality.com/news/opera-5-5-support-policy-update/
• Oracle's published Lifetime Support Policy for Oracle Applications (Effective Date 7 August 2026) names the OPERA 5 releases individually under "Oracle MICROS/Oracle Hospitality Hotel Releases". Hospitality OPERA 5.5: general availability October 2015, Premier Support ends October 2021, Extended Support not available, Sustaining Support indefinite. Hospitality OPERA 5.6: general availability April 2019, Premier Support ends December 2027, Extended Support not available, Sustaining Support indefinite. A footnote records that Premier Support for OPERA 5.6 was extended from April 2027 through December 2027 and that during this period error correction applies only to 5.6.28 and later releases. The document states support tiers only. It publishes no uptime commitment, no service level and no status page for either release. https://www.oracle.com/us/support/library/lifetime-support-applications-069216.pdf
• Oracle publishes its Lifetime Support Policy, under which Premier Support is available for five years from general availability of a release, may be extended for three years with Extended Support where offered, and is followed by Sustaining Support for as long as the customer licenses the product. Under Sustaining Support a release receives no new fixes, updates or certifications created after the Premier and Extended periods end. The policy is published by Oracle and applies across Oracle product lines. https://www.oracle.com/us/assets/lifetime-support-technology-069183.pdf
• Oracle's Technical Support Policies, effective 7 August 2026, apply across Oracle software product lines including on-premise products. Severity 1 issues carry a commitment of reasonable efforts to respond within one hour; Severities 2 to 4 carry no response-time target. The document contains no availability or uptime commitment. No Oracle-published service level applies to on-premise deployments. https://www.oracle.com/contracts/docs/057419.pdf

Security, authentication, and compliance

Score: 3 of 9 (Limited). Weight 8%.

First scorer rationale: PA-DSS 3.2 / PCI DSS guidance is a real certification but is not among the anchor_6 criteria, which require OAuth 2.0 with scoped permissions, plus SOC 2 Type II or ISO 27001, plus a GDPR DPA — for the deployed product. Oracle's ISO 27001, SOC 2 and HIPAA certifications apply to OCI and do not extend to on-premise OPERA 5, and no OAuth scope model or vendor-published DPA covering the on-premise product is publicly evidenced. None of the anchor_6 criteria are therefore evidenced for OPERA 5 specifically. [Expanded-scope search — 2026-08-09] The anchor-6 position on the Data Processing Agreement criterion is now confirmed from an Oracle-published source. Oracle's Data Processing Agreement is scoped in its own Section 1 to Oracle Cloud Services, and no Oracle-published Data Processing Agreement, licence document or hosting-terms document scoped to on-premise products was located at Oracle's public contracts repository. The scope limitation is stated by Oracle rather than inferred. Two further surfaces were attempted and could not be verified: the Oracle Master Agreement was identified as Oracle's on-premise licence vehicle, but its clause text was not retrievable as a fixed public document in this search; and Oracle's dedicated on-premises security attestations page was blocked on direct access. Both are recorded as attempted and unverified rather than as searched and empty. The score is unchanged.

• OPERA 5 holds PA-DSS 3.2 validation for payment application security and the security guide mandates PCI DSS-compliant configuration, unique user IDs, automated audit trails, and firewall requirements. However, OPERA 5 runs on customer-managed on-premise infrastructure: Oracle's ISO 27001, SOC 2 and HIPAA certifications applicable to OCI do not extend to on-premise deployments, and no OAuth 2.0 scope model or publicly evidenced GDPR Data Processing Agreement covers the on-premise product. None of the anchor_6 criteria (OAuth 2.0 with scoped permissions + SOC 2 Type II or ISO 27001 + GDPR DPA) are evidenced for OPERA 5 specifically; PA-DSS/PCI is real but is not one of those criteria. https://docs.oracle.com/cd/E98457_01/docs/F62229.pdf
• Oracle's Data Processing Agreement is scoped in its own Section 1 to Oracle Cloud Services. No Oracle-published Data Processing Agreement, licence document or hosting-terms document scoped to on-premise products was located at Oracle's public contracts repository. The scope limitation is stated by Oracle rather than inferred. https://www.oracle.com/contracts/cloud/data-processing-agreement-archive/

Partner programme and references

Score: 3 of 9 (Limited). Weight 7%.

First scorer rationale: No self-serve partner programme, published partner tiers, developer forum or community is publicly evidenced for OPERA 5 specifically. OHIP's programme applies to OPERA Cloud, not to OPERA 5. The product is on sustaining/Premier support only, receives no new feature development, and new integrations are being built against OHIP rather than OXI — a contracting, installed-base-substitution ecosystem rather than an active partner programme. This matches anchor_3 (partner programme exists but is invite-only or undocumented; no developer forum or community). Note: Oracle Hospitality's partner-integration page describes integration-classification tiers and fees, not a partner programme with published tiers; no OPERA 5-specific forum or directory is evidenced. OPERA 5 uses a separate, formal Partner Integration Program distinct from OPERA Cloud's OHIP self-service marketplace — confirmed via Oracle's own page, not the OHIP evidence used for oracle-opera-cloud.

• Oracle Hospitality Partner Integration Program for OPERA 5: approval-based, validation fees USD 7,000-15,000, PCI compliance required, active sales channel required. A formal integration-classification programme distinct from OPERA Cloud's self-service OHIP marketplace. https://www.oracle.com/hospitality/pms-pos-integration-partners/

Documentation and changelog discipline

Score: 3 of 9 (Limited). Weight 7%.

First scorer rationale: Anchor_6 requires versioned documentation, updates within 6 months, and a changelog. The evidence states explicitly that OPERA 5 has no changelog discipline, no versioned release notes cadence equivalent to OHIP's, and is not actively updated beyond security and compliance maintenance. All three anchor_6 criteria are therefore absent. This matches anchor_3: documentation exists but is incomplete, unversioned, or last updated over 12 months ago. [Rationale correction — 2026-08-09] "The comparative reference to OHIP's release-notes cadence is withdrawn. Whether documentation cadence matches that of a separate product is not a criterion at any anchor of Documentation Quality, whose anchors concern completeness, versioning, recency and the presence of a changelog. This applies the standard applied across the vendor set on 2026-08-09, under which cross-product and cross-vendor comparators are withdrawn where the rubric does not make them relevant. The score is unchanged at 3. The operative position is stated against the anchor criteria: Oracle publishes OPERA 5 documentation covering OWS and OXI including WSDL files and SOAP XML samples, so documentation exists. Versioning, a changelog, and updates within the anchor-6 recency window are not evidenced. Anchor 6 requires all three and none is evidenced, which places the dimension at anchor 3: documentation exists but is incomplete, unversioned, or last updated over twelve months ago."

• Oracle publishes OPERA 5 documentation on the Oracle Help Center covering OWS, OXI, IFC8 and PA-DSS implementation guides. The documentation is comprehensive for its scope but follows legacy patterns — WSDL files, SOAP XML samples, Windows IIS configuration instructions. There is no changelog discipline, no versioned release notes cadence equivalent to OHIP's quarterly updates, and no TypeScript or REST reference implementations. Documentation is stable but not actively updated beyond security and compliance maintenance. All three anchor_6 criteria (versioned + updated within 6 months + changelog present) are absent — this matches anchor_3. https://docs.oracle.com/cd/E98457_01/opera_5_6_core_help/20460.htm

Scores are published only where documented evidence exists. Corrections and disputes are recorded in the public changelog. The scoring rubric is published in full in the methodology.

Rank 17 of 17 scored vendors on the PMS Power Index ladder.