Meridian

Inspiration

Meridian means 'Chi' which is energy in ancient Chinese. The idea is to empower everyone to build that mental dashboard or webpage and give it life and not poke holes in the company's security. Enterprise teams have no shortage of ideas for improving how work gets done. What they often lack is a fast path from an operational need to a secure, usable application. Business users can describe their workflow, but building the solution usually requires a long chain of requirements gathering, engineering, security review, access-control design, and deployment approval. Traditional no-code tools accelerate the interface, but governance is often added afterward. We built Meridian around a different question:

What if enterprise governance were an input to application generation instead of a checklist applied at the end?

What it does

Meridian turns a plain-language business request into a working, governed enterprise application. A user can ask Meridian to create an application for a workflow such as vendor onboarding or expense review. Meridian then:

• Resolves the appropriate Enterprise Blueprint from the user's identity and intent
• Applies approved data contracts, capabilities, policies, and design standards
• Generates an interactive application with a dashboard, forms, records, and workflows
• Enforces role-based access to sensitive data and restricted actions
• Supports conversational changes to the generated application
• Rejects requests that would weaken mandatory controls
• Routes policy exceptions and production publishing through human approval
• Records governance decisions, versions, approvals, and deployment history

The prototype includes two distinct application verticals: Vendor Onboarding and Risk Review for Operations, and Expense Review for Finance. Each is generated from different data contracts, policies, fields, and design-system configuration.

One of our favorite demonstrations is asking Meridian to add an annual contract value field and require Finance approval above $100,000. The field and policy are added to the live application, existing records are reevaluated, and the application version is updated. If the user then asks Meridian to remove a mandatory Legal review, Meridian refuses and creates a policy-exception request instead.

How we built it

Meridian is a React 19 and TypeScript single-page application built with Vite, Tailwind CSS, Zustand, React Router, and Framer Motion. We separated the platform into several independently testable engines:

1. A Blueprint resolver selects enterprise configuration using employee identity, department, permissions, and request intent.
2. A generation engine composes an application specification from approved data contracts.
3. A policy engine produces deterministic allowed, blocked, or approval-required decisions.
4. A capability-aware data gateway controls access to enterprise data.
5. A provenance engine explains which Blueprints, policies, skills, and data contracts produced the application.

The generated interface renders from a structured AppSpec. It is not simply a static mockup. For example, when an administrator adds a field to a data contract, that field appears in the next generated application without changing the renderer. For this hackathon prototype, natural-language interpretation uses a deliberately scoped, deterministic parser. This allows the complete demo to run locally without credentials, network access, or unpredictable runtime behavior. The interpreter produces structured intents behind a clean boundary, making it straightforward to replace with an OpenAI model using structured outputs in a production version. Importantly, the policy engine remains deterministic and auditable regardless of which model interprets the user's request.

All state is persisted locally so the workflow can continue across page refreshes and persona changes. The policy, Blueprint-resolution, interpretation, and generation engines are covered by automated Vitest tests.

Challenges we faced

The hardest challenge was making generation meaningful rather than presenting a scripted animation. We wanted every generated field, permission, policy, and approval requirement to have a traceable source. We also had to separate interpretation from authorization. A conversational system can propose a change, but it should never be the final authority on whether that change is safe. Meridian solves this by passing structured requests through deterministic policy enforcement.

Another challenge was representing multiple people acting on the same application without building a full identity service or backend. We created several realistic personas and maintained shared application state while changing their permissions and available actions.

Finally, we had to balance an ambitious platform vision with a reliable hackathon demonstration. We focused on two complete workflows with real governance behavior instead of producing many shallow templates.

Accomplishments that we are proud of

• Governance is built into generated applications from the beginning
• Policies are structured, deterministic, inspectable, and testable
• Mandatory controls cannot be removed through conversational prompting
• Data-contract changes mechanically affect future generated applications
• Sensitive fields and approval actions change correctly between personas
• Publishing includes a real human approval gate and governed inventory
• The full experience runs locally with no backend, database, or API credentials
• The architecture provides clean boundaries for future OpenAI and enterprise integrations

What we learned

We learned that the most important part of an enterprise application generator is not generating more interface code. It is preserving organizational intent.

Blueprints, data contracts, capabilities, policies, and provenance need to be first-class system concepts. When these controls are represented as structured data, the generated experience becomes easier to explain, test, audit, and evolve.

We also learned that AI interpretation and policy enforcement should remain separate. Models are excellent at understanding and translating intent, while deterministic systems are better suited to enforcing non-negotiable controls.

What's next for Meridian

Our next step is to replace the scoped request interpreter with an OpenAI-powered interpreter that produces the same validated structured intents. From there, we plan to:

• Connect Meridian to real enterprise data through scoped APIs
• Add OIDC or SAML identity and authorization
• Make Blueprints, skills, and design systems fully configurable
• Add durable multi-user storage and real-time collaboration
• Connect publishing to real infrastructure and CI/CD workflows
• Expand beyond the initial Operations and Finance workflows

Our long-term vision is simple: any employee should be able to describe an operational need and receive a secure, governed, enterprise-ready application without needing to understand the underlying technology.

Built With

• codex
• framer
• lucide
• openai
• react
• tailwind
• typescript
• vite
• zustand