Enterprise Architecture

Department isolation with controlled cross-access — built on deterministic storage and coordinate addressing.

1. Department-Based Storage Model

In a traditional monolithic database, departments share a single schema and storage engine. APIBASE replaces this model with independent bases:

/data/users/finance/finance.php
/data/users/hr/hr.php
/data/users/inventory/inventory.php
/data/users/production/production.php
/data/users/maintenance/maintenance.php

2. Hive Gateway & Cross-Base Routing

Each department runs its own BASE while the Hive controls cross-base communication and permissions.

3. Execution Pipeline

HTTP Request
      ↓
Bearer Token Validation
      ↓
Context Resolution
      ↓
ACL Evaluation
      ↓
Base Selection
      ↓
Deterministic Execution
      ↓
Structured JSON Response

4. Context Model

• User — personal base
• Hive — authorized cross-base access
• System — internal metadata control

The context determines which base the engine is allowed to access. No implicit fallback is assumed.

5. Access Control Layer

APIBASE separates authentication from authorization. Permissions are explicit and centrally managed.

Token → apitokens
         ↓
       hiveacls
         ↓
       hivebases

5.1 Service Users & Hive ACL

In APIBASE, a department base is implemented as a regular user account. For example, inventory is a real user that can log in, manage tables, and operate like any standard BASE owner.

Token scopes

• scope=full — personal API (read/write) on the token owner’s BASE via /api/*
• scope=hive — gateway token (read-only today) to access shared department BASEs via /hive/get/<basekey>/*

Hive authorization chain

curl https://apibase.work/hive/get/inventaire/T2/L1?format=assoc \
  -H "Authorization: Bearer YOUR_HIVE_TOKEN"

curl https://apibase.work/hive/get/inventaire/T2/L1/C2?format=raw \
  -H "Authorization: Bearer YOUR_HIVE_TOKEN"

apitokens (scope=hive)  →  hiveacls  →  hivebases (basekey → username)

This model creates a clean separation:

• Ownership: the service user (inventory) controls its BASE directly.
• Collaboration: department members access the BASE through HIVE with scoped tokens and ACL.

6. Data Address Protocol

Traditional databases retrieve data through query languages. APIBASE addresses data directly through coordinates.

BASE / TABLE / LINE / COLUMN

Example request:

GET /hive/get/inventory/T4/L2/C2

Deterministic lookup:

$data[4][2][2]

7. Operational Resilience

• If one department fails, others remain operational
• No shared schema corruption risk
• No global locking side effects
• No cascading transactional failure

8. Versionable BASE Files

APIBASE stores data as deterministic text files. This allows native integration with version control systems.

• Cell-level Git diffs
• Branching for data changes
• Rollback without SQL dumps

- $data[4][12][2] = 'Alice'
+ $data[4][12][2] = 'Alicia'

9. Distributed BASE Network

Through HIVE, multiple BASEs can form a distributed data network. Each BASE remains independent while accessible through a unified coordinate protocol.

          Client
            │
        Hive Gateway
       ┌─────┴─────┐
       │           │
Inventory Base   Finance Base
 Server A         Server B

• Independent data ownership
• Controlled cross-access
• Unified protocol

10. Comparison with Traditional Architecture

11. Strategic Value

• Improved operational resilience
• Simplified governance
• Reduced blast radius
• Predictable execution model
• Git-compatible data infrastructure
• Distributed BASE network capability