Our Secret Sauce
What makes legacy UniBasic projects uniquely challenging—and how we're teaching AI to understand them.
The UniBasic Challenge
Rules That Live Everywhere
Unlike modern applications, UniBasic systems don't keep their business logic in one place. Understanding this distribution is key to understanding why traditional AI approaches fall short.
- Rules in Files
Configuration files, parameter tables, and external scripts define behavior. These rules are often scattered across dozens of files with cryptic naming conventions. They control everything from validation logic to workflow routing—but they're easy to miss.
- Rules in Database
Business rules live in database tables—not as stored procedures, but as data. Row-level configurations that determine system behavior. A single record can change how entire workflows operate. These "data-driven rules" are invisible to standard code analysis.
- Rules in Code
The "obvious" place for logic—but in UniBasic, even this is complex. Dynamic subroutine calls, indirect variable references, and runtime-evaluated expressions make static analysis nearly impossible. Code that looks simple often has hidden dependencies.
How UniBasic Was Built—And Why It Matters
UniBasic (and its cousins—Pick, Reality, D3, UniVerse, UniData, jBASE) emerged in the 1960s with a radical philosophy: "Make it flexible, make it fast, make it work."
The result was a system where data and behavior are inseparable. Database tables aren't just storage—they're configuration engines. Files aren't just code—they're executable business rules. The entire system is designed for runtime flexibility over compile-time safety.
This was brilliant for rapid development in the 1970s-90s. Businesses could change rules on the fly without recompiling. But for AI trained on modern codebases? It's a nightmare.
The AI Challenge
Standard AI models are trained on GitHub. They understand React components, Python classes, REST APIs, and SQL queries. They expect code to be in .js files, business logic in services, and data in databases.
UniBasic breaks all those assumptions. A single "item" in a database can execute like a function. A subroutine name might be stored as data. Validation rules might live in a file you'd never think to open.
So we're teaching AI differently. We're not just feeding it syntax—we're teaching it the philosophy. The patterns. The "why" behind the weird. We're showing it that in UniBasic, context is everything.
Our Approach: Teaching AI to Think Like a UniBasic Developer
Multi-Source Context Gathering
Before analyzing any code, we map the entire ecosystem: files, database schemas, parameter tables, INCLUDE files, subroutine catalogs. We build a knowledge graph of where rules could be hiding.
Pattern Recognition Training
We've trained our models on decades of UniBasic patterns. Dynamic CALL statements. Indirect file opens. BASIC variables that are actually function pointers. The AI learns to recognize these idioms—not as syntax errors, but as intentional design patterns.
Human-Verified Learning
Every time our AI encounters something ambiguous—"Is this variable a config key or a data field?"—we flag it for human review. Those corrections feed back into the model. The AI learns from actual UniBasic experts, not just from GitHub.
Contextual Documentation Generation
Instead of just describing what code does, we document why it exists in this specific form. "This GOSUB isn't spaghetti code—it's a callback pattern for the parameter-driven workflow engine defined in SYSTEM.CONTROL file, items 47-53."
See It In Action
Watch how our AI detects cross-source business rules that traditional tools completely miss
⚠️ Cross-Source Business Rule Detected
Validation logic distributed across 3 different sources:VALIDATE.SUB code,BUSINESS.RULES database, andFIELD.DEFS file
✓ AI Analysis Complete
Business Rule Detected: Transaction amount validation implements a three-layer validation architecture:
- ▸Layer 1 (Code):
VALIDATE.SUBperforms the runtime check - ▸Layer 2 (Database):
AMOUNT.MAXrecord stores the configurable threshold ($50,000) - ▸Layer 3 (Config): Field definition enforces the rule at the data layer with custom error messaging
💡 Critical Insight: The $50K limit is configuration data, not hard-coded. Changing it requires a database update, not a code deployment. Traditional static analysis tools would document this as "validates amount" and completely miss the dynamic nature of this rule.
This is what makes UniView different. We don't just read code—we understand the entire system.
Files, databases, and code work together as an interconnected system, and our AI learns to see those connections the way an experienced developer would—by understanding context, not just syntax.
More Deep Dives Into Our Technology
We're preparing detailed technical articles on our model training process, the architecture of our Human-in-Loop Engine, and real-world case studies showing how we've tackled the most complex UniBasic systems.