Liferay Development & Enterprise AI
EWS builds and modernizes Liferay platforms and integrates governed AI while Liferay stays in charge of content, identity, permissions and enterprise workflows.
The long-standing Liferay engineering practice and the newer Ask layer are one story: keep the portal authoritative, then let AI operate only on authorized evidence.
Liferay engineering
Platform work the site already describes
Liferay DXP and portal engineering
EWS builds and extends Liferay digital experience platforms: customer portals, unified experiences, and integrations with surrounding business systems. Homepage service work lists Liferay DXP 7.4+, Java/OSGi, and REST/GraphQL APIs.
Permissions, workflows and search
Enterprise portals live or die on identity, roles, content visibility and workflow. Those remain Liferay concerns. AI does not replace them.
Modernization, upgrades and migration
Strategic consulting on the site already includes architecture assessment, performance work, and migration strategy. Those are offered engineering services, not named customer cutover case studies on this page.
Headless APIs and OSGi modules
Existing Liferay service descriptions cover Java/OSGi module work and REST/GraphQL APIs. We do not invent client-extension implementations that are not already evidenced here.
Liferay + AI
Liferay remains authoritative. AI operates on authorized evidence.
That is the architectural principle demonstrated by EWS Liferay AI Intelligence. Liferay owns content, documents, structured content, users, roles and current VIEW. The EWS layer orchestrates retrieval, grounding, citations, guardrails and the model-provider boundary. It is a governed Ask layer beside the portal, not a replacement for it.
- Liferay environment remains the system of record
- Authorized content and data are permission-filtered first
- An AI integration layer orchestrates Ask
- Retrieval and reasoning run on authorized evidence only
- AI-powered experiences sit beside DXP, not above it
Permission-aware AI
Portal AI has to respect who the user is
A common anti-pattern is to dump a Liferay corpus into a vector database, then ask the model not to reveal restricted information. That treats the model as an authorization system. Prompts are not a security control.
Enterprise portal AI has to respect identity, roles, permissions and content visibility as Liferay already computes them. A search hit is only a candidate. Current VIEW is evaluated before evidence enters the model.
Authorized content may still be processed transiently by the EWS service and may cross a configured model boundary. Do not read this architecture as “no data leaves Liferay.” Read it as: unauthorized data must not enter the model.
AI use cases
Demonstrated, then discussed
The Ask layer is implemented and lab-validated. Client applications of that pattern are engagement topics, not additional product claims.
Demonstrated in Liferay AI Intelligence
Permission-aware Ask
Identity → authorization → permission filter → retrieval → grounding → model. Current Liferay VIEW is checked before evidence is usable.
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.
Lab-validated checkpoint
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.
Discussed with clients as applications
Knowledge assistance
A signed-in user asks questions against portal content they are already allowed to see. Demonstrated as the Ask layer; a client’s corpus and UX would be a separate engagement.
Content intelligence and search augmentation
Retrieval can sit beside Liferay Search rather than replacing it. Mode A already uses native Search as the candidate source.
Evidence-backed recommendations
Recommendations only make sense if they cite authorized sources and can abstain. That pattern is demonstrated; specific recommender products are not.
Governed assistants on the portal
An assistant that respects roles and VIEW is an application of the same architecture. It is not an autonomous employee living inside DXP.
Engineering evidence
EWS Liferay AI Intelligence
Permission-aware, evidence-backed, governed Ask on Liferay content. 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. Meridian personas used in demos are a reference estate for lab validation — not an EWS customer.
15+ Years of Liferay Expertise
Enterprise AI
Liferay + Enterprise AI
EWS Liferay AI Intelligence
Liferay remains authoritative for content, identity and permissions. AI operates on authorized evidence — a governed Ask layer beside the portal, not a replacement for it.
Enterprise Liferay experience
Public references, not endorsements
The site already states 15+ years of Liferay expertise. Public project cards already presented on the Work pages include Liferay-related work for ECHA, TED, Placecube, IHI and EUIPO. Those are existing public references.
They are not testimonials, not named production case studies on this page, and not a claim that those organizations endorse EWS or have deployed Liferay AI Intelligence. Logos and cards on the existing site are not reused here as social proof.
Founder biographies on the About section also name Liferay architecture work involving ECHA, EUIPO and IHI. That is the same public record, not a new customer claim.
Technology
Stack by layer
Discuss Liferay modernization or AI architecture
Bring the DXP version, the permission model, and whether Ask should sit on native Search or a hybrid index. We can talk through portal engineering, upgrades, and governed AI integration.
Contact EWS