Inspiration
Most digital platforms still rely on search, filters, and long lists. That works when users know exactly what to look for, but it becomes inefficient when the real goal is to find the best fit across multiple constraints and preferences.
We built OSAL around a simpler idea: users should describe what they need, and the system should identify the most compatible options, explain the reasoning, and clearly separate eligible, filtered, provisional, and ranked results.
What it does
OSAL is AI matching infrastructure for products that need to connect people, projects, suppliers, or other entities.
Users can provide their requirements through:
- Natural-language requests
- Structured criteria
- A hybrid of both
OSAL interprets the request, identifies hard requirements and preferences, evaluates compatible records, filters ineligible options, ranks the remaining matches, and explains why each result fits.
The public demo includes fictional scenarios for:
- Finding professional talent
- Matching people with projects
- Personal compatibility
- Evaluating suppliers
OSAL also includes a visual Adapter Builder where developers and product teams can define fields, add sample data, configure rules, and test a new matching use case without rebuilding the matching engine.
How we built it
OSAL was built with Next.js, TypeScript, React, Tailwind CSS, the OpenAI API, GPT-5.6, and Codex.
GPT-5.6 is used for understanding natural-language intent, extracting criteria, detecting ambiguity, and producing clear explanations.
A deterministic matching layer handles typed operators, hard constraints, preference scoring, adapter compatibility, validation, and predictable ranking behavior.
The application supports built-in and custom adapters, natural, structured, and hybrid input modes, and request-to-adapter compatibility checks.
Codex supported the development process across implementation, debugging, testing, refactoring, release hardening, and deployment preparation.
The public deployment runs in Docker behind Caddy. All demonstration records are fictional and synthetic, and custom adapter data and matching results are not persisted.
Challenges we ran into
One major challenge was balancing the flexibility of natural language with the predictability required from a matching system.
Terms that appear similar to a person may have different meanings in data. Numeric requirements, Boolean preferences, regions, dates, and controlled values also need different evaluation rules.
We addressed this by canonicalizing extracted criteria, validating them against adapter schemas, and evaluating them through typed deterministic operators.
Another challenge was preventing a request from being evaluated against the wrong adapter. OSAL now detects incompatible or ambiguous requests before candidate evaluation and asks for clarification instead of producing misleading matches.
We also had to make structured and hybrid inputs behave consistently with natural-language matching while preserving clear diagnostics, warnings, and unresolved constraints.
Accomplishments that we're proud of
- Built a reusable matching engine instead of a single-domain recommendation demo
- Combined GPT-5.6 reasoning with deterministic constraint enforcement
- Added explainable eligible, filtered, provisional, and ranked outcomes
- Implemented natural, structured, and hybrid input modes
- Created a visual Adapter Builder for custom matching scenarios
- Added adapter compatibility protection against misleading results
- Built extensive automated coverage for matching, adapters, public-demo behavior, and edge cases
- Deployed a working public demo using synthetic data only
What we learned
We learned that AI matching should not rely on semantic similarity alone.
Reliable matching requires a clear separation between interpretation and enforcement. AI is effective at understanding human requests, but hard constraints, typed comparisons, scoring, and compatibility decisions benefit from deterministic validation.
We also learned that explaining uncertainty is as important as presenting a result. When information is missing or cannot be safely mapped to the available schema, asking for clarification is better than returning a confident but incorrect match.
What's next for OSAL
The next stage for OSAL is to become an embeddable matching layer for external products and platforms.
Future work includes:
- Secure persistent adapters and data sources
- Authentication and organization workspaces
- API and SDK access
- Database and third-party system integrations
- Human feedback and matching-quality evaluation
- Configurable ranking and policy controls
- Versioned adapter testing and monitoring
- Production-scale privacy, permissions, and audit capabilities
Our long-term goal is to make explainable matching a reusable infrastructure capability: Match, don't search.
Log in or sign up for Devpost to join the conversation.