feat: Typed Data Access & Disambiguation Policy — ontology enforcement across Stackbilt repos

[stackbilt-admin]

Motivation

Three related concepts are floating independently across the ecosystem:

1. CodeBeast DATA_AUTHORITY sensitivity class (codebeast#9) — auditing raw D1 usage across repos
2. AEGIS disambiguation firewall (aegis#344) — halting on undefined data concepts instead of guessing
3. Ontology enforcement — ensuring all repos use canonical business term definitions

These need a unified policy layer, owned by Charter as the governance tool.

Proposal

Define a typed-data-access policy in Charter that:

1. Canonical Term Registry

• Define business terms (tenant, user, subscription, credit, tier) with types and ownership
• Each term maps to a source-of-truth service (e.g., tenant → stackbilt-auth, credit → QuotaService)
• Terms are versioned and enforced at commit-time via Charter governance hooks

2. DATA_AUTHORITY Sensitivity Class

• Tag data access patterns by sensitivity: public, internal, auth_scoped, billing_sensitive
• CodeBeast enforces: raw D1 queries touching auth_scoped data must go through the owning service's RPC
• Violations flagged as issues with remediation guidance

3. Disambiguation Protocol

• When AEGIS encounters an undefined data concept, it MUST halt and ask rather than guess
• Undefined = not in the canonical term registry
• Applies to: task execution, self-improvement proposals, autonomous goal work

Implementation

1. Add typed-data-access.adf policy module to Charter
2. Define term registry schema (YAML/JSON in .ai/ per repo)
3. Add Charter governance check: new code referencing unregistered terms → warning
4. Wire CodeBeast sensitivity scan to use the registry
5. Wire AEGIS disambiguation firewall to check terms against registry

Related

• codebeast#9 — DATA_AUTHORITY sensitivity class
• aegis#344 — disambiguation firewall
• aegis#334 — adversarial reasoning (complementary quality layer)

[stackbilt-admin]

Phase 1 Shipped

Data Registry (source of truth)

• stackbilt_llc/policies/data-registry.yaml — 22 business concepts mapped to owning services, D1 tables, 6 sensitivity tiers (public → secrets), aliases, and RPC methods
• Committed to the LLC governance vault as the canonical reference

AEGIS Integration (v1.67.1)

• data-registry.ts — compiled TypeScript const from the YAML
• disambiguation.ts — rewired to derive KNOWN_CONCEPTS from the registry instead of hardcoded inline maps
• Deployed and live — disambiguation firewall now checks 22 concepts (was 8)

What remains for this issue

• Charter audit --data command — reads registry, validates per-repo compliance
• typed-data-access.adf policy module for Charter governance
• CodeBeast sensitivity seed from registry (codebeast#9)
• Per-repo .ai/ontology.yaml generation from registry
• img-forge api_keys table delegation to stackbilt-auth (flagged as data ownership violation)

[stackbilt-admin]

Status update

Still open as a design proposal, no implementation work scheduled yet. The three referenced concepts (CodeBeast DATA_AUTHORITY, AEGIS disambiguation firewall, ontology enforcement) have continued to evolve independently in their respective repos.

The 0.10.0 release added @stackbilt/surface which now extracts D1 schema tables from schema.sql files — that's one small primitive in the direction of "know what typed data a service exposes before writing policy over it." Not a solution, just a building block.

When we do pick this up, the path is probably:

1. Design a minimal typed-data-access.json schema in .charter/
2. Add a charter data-check command that uses @stackbilt/surface to enumerate tables and validates them against the policy
3. Only then integrate with CodeBeast and AEGIS

Keeping open as a long-horizon ecosystem proposal.