Oracle Unifier AI Data Assistant: Architecture, Stack & Delivery

Introduction

In this article I break down how I designed and delivered Oracle Unifier AI Data Assistant — from the original business pain point through architecture, technology choices, implementation phases, and lessons learned. This is the same project featured in my portfolio's Built Solutions section, documented here in full technical depth for engineers, architects, and hiring managers who want to understand how the work was actually done.

I led this initiative as part of my broader program delivery work across enterprise AI, data platforms, and analytics transformation. The approach reflects how I operate: start with the business outcome, choose the minimum viable architecture, instrument everything, and iterate with real users.

Business problem

Construction project stakeholders struggled to query Oracle Unifier without deep SQL skills.

React + OpenAI assistant translating natural language to Oracle SQL for project analytics.

Architecture decisions

Key design choices that shaped reliability, performance, and maintainability of the solution.

• Generated SQL shown for human review before execution in prod
• Prompt includes Unifier-specific table and column descriptions
• Read-only DB role enforced at connection level

Technology stack in depth

This project was built with React, OpenAI, Oracle SQL. Each technology was selected for a specific role in the architecture — not because it was trendy, but because it solved a measured bottleneck.

• React: production component with documented integration patterns and operational runbooks
• OpenAI: production component with documented integration patterns and operational runbooks
• Oracle SQL: production component with documented integration patterns and operational runbooks

Implementation timeline

Delivery followed phased milestones with explicit deliverables at each gate. This kept stakeholders aligned and made progress auditable for program reviews.

• Domain modeling (2 weeks): Mapped Unifier project, task, and budget entities for prompt context.
• → Schema guide
• → Sample questions
• → Glossary
• React application (3 weeks): Chat UI with SQL preview and copy-to-clipboard for DBAs.
• → Web UI
• → API layer
• → Auth integration
• Governed rollout (2 weeks): Read-only SQL policy and stakeholder training sessions.
• → Security review
• → Training deck
• → Usage analytics

Domain-specific grounding

Construction project stakeholders needed answers from Oracle Unifier without learning complex schema relationships. Generic LLM prompts hallucinated table joins; domain-specific prompts with Unifier entity glossary and sample questions reduced errors dramatically.

• Schema guide: project, task, budget, and commitment entities mapped
• Prompt includes table/column descriptions in Unifier terminology
• Generated SQL shown for human review before execution in production
• Read-only DB role enforced at connection level

React application and governance

The chat UI lets users ask natural language questions, preview generated Oracle SQL, and copy to clipboard for DBA review. Auth integrates with corporate SSO. A governed rollout included security review and stakeholder training.

• API layer: OpenAI completion with schema context injection
• Usage analytics: question categories, acceptance rate, error types
• Training deck for project managers and site engineers

Business outcomes

Democratized construction analytics for non-technical users.

Success was measured against adoption, latency/throughput targets, and stakeholder feedback — not just deployment dates. Program reviews tracked these KPIs alongside technical milestones.

Lessons learned

Domain-specific prompts and schema grounding reduce hallucinated SQL.

If I were starting again, I would invest even earlier in observability and golden test sets. The cost of retrofitting guardrails after pilot launch always exceeds building them in from day one.