Data Interface
Your database has 40 tables. How many can a human, agent, or machine actually talk to?
The Job
When a venture needs to read, write, or query structured data — whether through a human operator, a conversational agent, or an autonomous machine — help it access any table through a consistent interface without bespoke integration work.
| Trigger Event | Current Failure | Desired Progress |
|---|---|---|
| New table created | Table exists in schema but nothing can reach it | Table is accessible via Admin UI + Chat + A2A within one cycle |
| Human needs data | Opens pgAdmin or asks a developer to run a query | Opens Admin UI, filters, edits, done |
| Agent needs context | Hard-coded API call or no access at all | Asks a question in natural language, gets structured answer |
| Machine-to-machine sync | Custom integration per table, per consumer | Standard protocol — any consumer reads any table it's authorised for |
The Pattern
Every table gets three interfaces. Not eventually. As a condition of being considered "live."
| Interface | Who Uses It | What It Does |
|---|---|---|
| Admin UI | Human operators | CRUD — create, read, update, delete through a browser |
| Chat | Conversational agents (human or AI) | Natural-language query that returns structured results |
| A2A | Autonomous agents and external systems | Machine-to-machine protocol for programmatic access |
Most tables today have one of these. Some have none. The pattern says: all three, or it's not done.
Why Three
Admin UI without Chat means humans can see data but agents can't reason over it. Chat without Admin means agents can query but humans can't correct errors. A2A without either means machines talk to each other with no human oversight. The three interfaces aren't features — they're a trust architecture.
Test Results as Truth
A table hasCrudInterface when the CRUD test passes. hasAgentInterface when the intent-to-query test passes. Not when someone says it's done. Not when the code looks right. The test is the proof.
This borrows from factory commissioning: the team that builds it is never the team that verifies it. A passing test is an independent witness. A green README badge is hearsay.
Maturity States
| State | Meaning | Proof |
|---|---|---|
| 0 — Schema only | Table exists in database | Migration ran |
| 1 — Admin UI | Human can CRUD | CRUD test passes |
| 2 — Chat | Agent can query via natural language | Intent test passes |
| 3 — A2A | Machine can read/write via protocol | Protocol test passes |
| 4 — Full coverage | All three interfaces verified | All three tests green |
A table at state 0 is infrastructure debt. A table at state 4 is a platform primitive.
Bootstrap → Mature
Not everything starts as a protocol. The path is intentional:
| Phase | Interface Style | When It Fits |
|---|---|---|
| Bootstrap | CLI tool for quick operator access | Early tables, small team, speed over ceremony |
| Mature | A2A protocol for autonomous interaction | Proven tables, multiple consumers, operating independently |
Bootstrap is not inferior — it's appropriate. The graduation signal is when multiple consumers need the same table and the CLI becomes a bottleneck.
Feature / Function / Outcome
| # | Feature | Function | Outcome | Status |
|---|---|---|---|---|
| 1 | Admin UI generator | Produce CRUD interface from table schema | Any operator can manage data without developer help | Gap |
| 2 | Chat query layer | Natural-language intent mapped to structured query | Agents reason over data conversationally | Gap |
| 3 | A2A protocol | Standard machine-to-machine read/write interface | Autonomous agents compose data across tables | Gap |
| 4 | Maturity tracker | Dashboard showing each table's interface coverage | Team sees which tables are accessible and which are dark | Gap |
| 5 | Test-as-proof harness | Automated verification that each interface works | No false claims of coverage — the test is the truth | Gap |
| 6 | Auth + scope layer | Per-interface authorisation for who can access what | Chat can't write, A2A can't delete, unless authorised | Gap |
Business Dev
This is infrastructure — it doesn't sell directly. It sells by making every venture's capabilities possible.
| Layer | Decision | Current Hypothesis | Validation Signal |
|---|---|---|---|
| ICP | Who benefits first? | Stackmates ventures with active data tables | 5 tables reach state 4 in first cycle |
| Offer | What does this enable? | "Any consumer can talk to your data" — foundational for all ventures | One venture ships a feature that depends on this layer |
| Channel | How does adoption happen? | Internal-first — every new table gets three interfaces by default | New tables ship with interfaces, not after |
| Conversion | What proves it works? | Consumer successfully queries a table it's never been explicitly coded against | Zero bespoke integration for a new consumer-data pair |
| Retention | Why does it stick? | Once consumers expect three interfaces, reverting to bespoke feels broken | No venture requests a custom data connector |
| Expansion | How does it compound? | Cross-venture data sharing via standard protocol | Dreamineering agent queries Stackmates data without custom code |
Commissioning
| Component | Schema | API | UI | Tests | Status |
|---|---|---|---|---|---|
| Admin UI generator | Pending | Pending | Pending | Pending | 0% |
| Chat query layer | Pending | Pending | Pending | Pending | 0% |
| A2A protocol | Pending | Pending | Pending | Pending | 0% |
| Maturity tracker | Pending | Pending | Pending | Pending | 0% |
| Test harness | Pending | Pending | Pending | Pending | 0% |
| Auth + scope | Pending | Pending | Pending | Pending | 0% |
Metrics
| Metric | Target | Why It Matters |
|---|---|---|
| Tables at state 4 (full coverage) | 20 tables | Scale signal — the pattern works beyond a handful |
| Interface coverage | Over 70% of active tables | Most data is accessible, not locked behind UI-only |
| Bootstrap → mature graduation rate | Tracked per table | Proves the progression model isn't just theory |
| Time to three-interface for new table | Under 1 sprint | The pattern is fast enough to be default, not a project |
Risks + Kill Signal
| Risk | Mitigation |
|---|---|
| Over-engineering for tables nobody queries | Start with the 10 most-accessed tables, not all tables |
| Chat interface returns wrong data confidently | Test harness catches regressions; auth layer limits blast radius |
| A2A protocol becomes attack surface | Scope-limited tokens per consumer; read-only default |
| Three interfaces per table is too much overhead | Generator tooling — if it takes more than an hour per table, the tooling is wrong |
Kill signal: If tables get all three interfaces but nobody uses them, the pattern adds overhead without value. Track invocation counts. Zero-use interfaces after 60 days means the interface isn't solving a real access problem.
Context
- Agent Platform — Agents that consume data interfaces
- Intelligence Functions — Pure logic that processes queried data
- ETL Data Tool — Upstream: data must be clean before interfaces matter
- Sales CRM & RFP — First consumer: CRM tables are the proving ground
- Flow Engineering — Maps that produce code artifacts
- Standards — Where proven interface patterns graduate to
- Phygital Mycelium — The capability catalogue