Liferay + Enterprise AI
EWS Liferay AI Intelligence
Open Enterprise AI Integration for Liferay
A governed Ask layer between Liferay enterprise content and configurable AI retrieval. Liferay remains the authority for content, identity, roles, and current VIEW permission. The EWS layer orchestrates retrieval, grounding, citations, guardrails, and the model-provider boundary. This is a separate track from EWS CareAgent and from EWS Digital Trust Suite.
The Challenge
The engineering problem
A common anti-pattern is to retrieve a broad Liferay corpus, send it to a model, and ask the model not to reveal restricted information. That treats the model as an authorization system. Prompts are not a security control.
Solution
What EWS built
Ask follows identity → authorization → permission filter → retrieval → grounding → LLM. Candidates may come from native Liferay Search (Mode A) or an EWS hybrid index (Mode B). In both modes, current Liferay VIEW is checked before evidence is usable. The AI does not decide what the user may see.
Product experience
Working software
Selected application views. These are product screens, not conceptual placeholders.
Technical evidence
Supporting diagrams
Architecture
How the system is composed
A search hit is not authorization. Current Liferay VIEW is evaluated before evidence enters the model. Do not read this as “no data leaves Liferay” — authorized content is still processed transiently by the EWS service and may cross a configured model boundary.
Verified Ask flow
Identity
Signed-in Liferay user context
Authorization
Liferay roles and permissions
Permission filtering
Unauthorized sources excluded
Mode A · LIFERAY_NATIVE
Native Liferay Search candidates
Mode B · EWS_HYBRID
Lexical + vector + RRF index
Current VIEW check
Stage-2 source authorization
Grounding + citations
Authorized evidence only
Configured model
Provider boundary, fail closed
Capabilities
What was implemented
Liferay remains authoritative
Content, documents, structured content, users, roles, and current VIEW stay in Liferay.
Ask orchestration
EWS owns retrieval abstraction, evidence construction, citations, guardrails, and provider wiring.
Two retrieval modes
Mode A uses native Liferay Search. Mode B uses an EWS hybrid index. There is no silent fallback between modes.
Citations and abstention
Answers are grounded in authorized evidence. The design abstains when evidence is missing.
Engineering decisions
Choices that matter
Search candidate ≠ authorization
A hit from Search or from an EWS index is only a candidate. Current VIEW is checked again before the model sees it.
Pluggable retrieval, one Ask layer
Native Search and hybrid RAG are deployment choices behind the same grounded Ask contract.
Adjacent to CareAgent, not a CareAgent phase
The track reuses CareAgent architecture patterns as an external Liferay AI layer. It is not CareAgent Phase 8 and not Digital Trust Suite estate intelligence.
Technology
Stack by layer
Evidence
What we can stand behind
Lab-validated modes
Mode A was validated on Liferay DXP 2026.q1.11-lts. Mode B was validated on Liferay Portal GA132. That is a lab checkpoint, not production certification.
Frozen Ask milestone
Product Ask, documentation, and the marketing video are frozen at the documented checkpoint. Later work (LAI-4) is not started.
Reference estate, not a customer
Meridian personas used in demos are a synthetic/reference estate. They are not EWS customers.
Related capabilities
Related EWS Capabilities
Discuss a similar project
Start from the workflow, the constraints, and the systems that have to stay authoritative.
Discuss a Similar Project