Purpose of the Manual #

A practical, operational guide that teaches a developer (or AI assistant) how to build applications in xF using:

• the Meta‑Model: The authoritative declarative application definition graph (zxf_app, zxf_entity, zxf_attribute, zxf_controltype, zxf_router).
• the Unified API: Collapsing an otherwise O(N) surface into universal endpoints (/api/xfm_list, /api/xf_get/{entity}/{id}/_/_, /api/xf_set, and /api/qry_datatable/{entity}/_/{size}/{page}).
• the Inherent PK Strategy: Every persistent entity record is automatically identified by xf_id. Designers never create redundant customer_id or booking_id keys.
• the Foreign Key Suffix Convention: Foreign key references to other entities strictly end with an underscore (driver_, vehicle_, client_, route_).
• the Execution Protocol: Embeds full state machine continuation in the wire payload.
• the zero‑build frontend: Renders directly from control types with no client bundlers.
• the Logic Gateway & Function Routes: Sandboxed Roslyn JIT C# scripts executing via private void f_name(ref Dictionary<string, object> Dx).
• the Route Register (IntRST): Intent-routed state transfer for external integration and domain orchestration.
• SQL‑in‑metadata: Parameterized SQL execution within attribute definitions (xt) populating client metadata.
• stateless workflows: Zero session persistence via payload continuation.
• transport isomorphism: Unifying persistent entities and transient aggregates under identical serialization.
• Model Context Protocol (MCP) & BYOAI: Standardized agent discovery and incremental metadata synthesis.

This manual is the semantic grounding layer for AI-assisted development and MCP tool calling.

1. Core Concepts #

1.1 Transport Isomorphism

Persistent entities and transient aggregates share the exact same wire format, routing semantics, and validation mechanics.

This is the foundation of the Unified API, allowing any frontend, workflow orchestrator, or LLM agent to interact with persistent storage and transient workflows through identical semantics.

1.2 Dual Payload Model

Every HTTP GET returns a partitioned payload structure:

• z‑segment - Transactional record state, primary key (xf_id), attributes, and protocol markers.
• y‑segment - Authoritative metadata definitions, UI layout configurations (xf_gx), control types (q), and populated lookup lists (p10, p1).

HTTP POST requests send only z back to /api/xf_set, preserving bandwidth and maintaining complete statelessness.

1.3 Unified API Endpoints

Instead of generating custom REST routes per business entity, xF operates across four generic endpoints:

• GET /api/xfm_list - Returns application bundle definitions, entities, attributes, and routing functions.
• GET /api/xf_get/{entity}/{id}/_/_ - Hydrates an instance into a dual z/y payload. Negative or zero IDs load initialized blank templates.
• POST /api/xf_set - Persists the mutated z‑segment, advances the version timestamp, and executes lifecycle rules.
• GET /api/qry_datatable/{entity}/_/{pageSize}/{page} - High-speed tabular list engine with automatic pagination and search filtering.

1.4 Execution Protocol

The z‑segment contains the full execution state machine:

1.5 Primary Keys and Foreign Key Underscore Convention

Two universal rules govern all data definitions in xF:

1. Universal Inherent Primary Key: Every entity record is automatically identified by an integer primary key named xf_id. Developers do not create keys like customer_id or driver_id. Business identifiers (e.g. customer_name, bookingno) are regular attributes marked with isstrid: true.
2. Trailing Underscore FK Convention: Any attribute that stores a reference to another entity must end with an underscore (e.g. client_, driver_, vehicle_, route_). When hydrated, the runtime automatically supplements these with display helpers like client__tostr and vehicle__tostr.

1.6 Stateless Workflows

State lives completely in the payload, not inside server memory or sticky web sessions. Because workflow continuation is encoded in the payload itself, backend workers scale horizontally without distributed session clustering.

1.7 SQL‑in‑Metadata

Attributes store parameterized SQL in xt that is evaluated at runtime, binding current z‑segment fields as named query parameters and populating result sets into the y‑segment.

1.8 Zero‑Build Frontend

UI is rendered dynamically from metadata using semantic control types (numeric xfctrltype mapping to q). There is no bundling, transpilation, or client-side build step required.

1.9 IntRST (Intent‑Routed State Transfer)

Routing is metadata-driven: clients send a semantic intent token (xf_f), and the server resolves that token through a declarative Route Register or Roslyn JIT script.

2. Developer Manual Overview #

This manual progresses systematically from foundational theory through physical metadata construction, workflow execution, logic integration, security, ops, and AI-native generative tooling.

Chapter 1 - Introduction to xF

1.1 What is xF - The eXtensible Framework

xF is a metadata‑interpreted runtime for enterprise systems. In a conventional stack, every business concept must be represented repeatedly: as a database schema, an ORM model, a service object, a controller, a DTO, an API route, and a UI component. xF collapses all of these layers into a single declarative model. You define an entity or aggregate once - its attributes, validation rules, SQL bindings, workflow steps, and UI controls - and the runtime executes that definition directly. The result is a system where the “source code” is metadata, and the runtime is responsible for turning that metadata into behavior.

1.2 The Problem xF Solves

Modern enterprise systems suffer from vertical coupling: a single business field change often requires coordinated updates across database schemas, ORMs, service layers, controllers, API routers, and UI components. This creates fragility, slows delivery, and makes systems difficult to evolve. xF removes this vertical coupling by replacing the entire stack with a small set of metadata tables, a unified execution protocol, and a zero‑build frontend. Instead of synchronizing multiple layers manually, the runtime interprets the metadata and ensures that every layer - data, logic, routing, and UI - remains consistent automatically.

1.3 The Three Pillars of xF

Although xF eliminates much of the traditional stack, its architecture is conceptually simple. It rests on three pillars that work together to produce a complete application:

1. Meta‑Model: A set of authoritative tables that describe everything the application needs: zxf_app, zxf_entity, zxf_attribute, zxf_controltype, and zxf_router. This is the declarative “source code” of the system.
2. Execution Surfaces: The runtime executes metadata through three deterministic surfaces: Auto‑CRUD for persistence, the Logic Gateway / Router (Roslyn C# JIT or compiled assemblies) for imperative business rules, and the Router for external REST integrations. Every interaction flows through one of these surfaces.
3. Zero‑Build Frontend (Optional): xF ships with a metadata‑interpreted, no‑build client that renders UI directly from control‑type metadata. Numeric control‑type keys map to component templates, allowing the UI to update instantly when metadata changes—no bundler, no compilation, no rebuild. However, this frontend is optional. xF is fundamentally API‑first. Any “head” can consume the dual‑payload API: React, Svelte, Angular, Flutter, or a fully bespoke enterprise UI. The Zero‑Build client is simply the reference implementation that demonstrates how metadata can drive UI without a build pipeline.

1.4 Transport Isomorphism

A defining feature of xF is that entities and aggregates share the same transport shape . Whether you are editing a persistent record or stepping through a multi‑stage workflow, the payload structure is identical. This “transport isomorphism” allows the same validation logic, the same UI components, and the same routing semantics to apply uniformly across the system. It also collapses what would normally be dozens of API endpoints into a small set of generic, intent‑driven interactions.

1.5 Architectural Context

API‑First: In xF, the metadata model and the execution payload are the primary contracts. The UI is simply an interpreter of those contracts. This makes the system naturally headless and naturally compatible with external clients, automation, and AI‑driven generation.

REST vs IntRST: Traditional REST exposes fixed resource routes such as POST /orders or PUT /customer/42. xF instead uses intent‑routed state transfer: the client sends a semantic intent token inside the payload, and the runtime resolves that intent through metadata. This allows workflows to evolve without changing routes or controllers.

1.6 Why AI Works Exceptionally Well with xF

Large Language Models excel at producing structured, declarative artifacts - JSON, SQL, routing rules, validation schemas - but struggle with large, multi‑file imperative codebases. xF is designed around this strength: AI generates metadata, not code. The runtime provides a deterministic, safe boundary that validates and executes the metadata. This makes xF uniquely suited for AI‑assisted development, where the machine produces the declarative model and the runtime guarantees correctness.

1.7 Stateless Execution & Wire Protocol Specifications

xF workflows do not rely on server-side memory or session serialization. The execution protocol is fully realized in the wire payload.

Machine-Readable Customer Entity Definition

{
  "objectname": "customer",
  "header": "Customer",
  "basetable": "T_CUSTOMER",
  "isaggregate": false,
  "attributes": [
    {
      "property_name": "customer_name",
      "header": "Customer Name",
      "xfctrltype": 1100,
      "valuetype": 60,
      "isstrid": true,
      "isunique": true,
      "ismandatory": true
    },
    {
      "property_name": "status",
      "header": "Status",
      "xfctrltype": 1318,
      "valuetype": 10,
      "defaultvalue": "0"
    }
  ]
}

Machine-Readable Execution Protocol Wire Payload

{
  "xf_entity": "customer",
  "xf_id": 42,
  "xf_guid": "b1f2-9931-44aa-998811223344",
  "xf_version": "2026-10-01T14:19:32.709",
  "xf_f": "save",
  "xf_xu": "customer.details",
  "xf_xt": 0,
  "xf_e": 0,
  "customer_name": "Acme Holdings Ltd",
  "status": 0
}

Machine-Readable Trip Entity (Demonstrating FK Underscore Convention)

{
  "xf_entity": "rb_trip",
  "xf_id": 104,
  "driver_": 12,
  "driver__tostr": "John Borg",
  "vehicle_": 8,
  "vehicle__tostr": "MQP 412 (Van)",
  "booking_": 5,
  "leg": 0,
  "tripdate": "2026-10-02",
  "rate_amount": 55.00
}

Chapter 2 - The Meta‑Model

2.1 Purpose of the Meta‑Model

The Meta‑Model is the single source of truth for an xF system. It defines structure, behaviour, presentation, transport, storage, and security. Because the Meta-Model tables are themselves ordinary xF entities (zxf_entity, zxf_attribute, zxf_router), the codebase remains O(1) in size as the business domain expands. Developers edit and manage metadata using the exact same screens and API calls used for business data.

2.2 The Four Main Layers of the Meta‑Model

Although xF contains more than a dozen metadata tables, only four of them form the structural core of the Meta‑Model. These are the layers that define the application’s schema, behaviour, and UI. The remaining tables (users, roles, rights, filters, domains, settings) act as governance layers that extend security and operational policy.

2.3 Auto‑DDL: Metadata → Physical Schema

Auto‑DDL synchronizes physical database tables directly from zxf_entity and zxf_attribute. When an entity is registered, Auto-DDL automatically injects system columns into the table:

• xf_id INT IDENTITY(1,1) PRIMARY KEY - The authoritative physical record identifier.
• xf_guid UNIQUEIDENTIFIER DEFAULT NEWID() - Distributed correlation identity.
• xf_version DATETIME DEFAULT GETDATE() - High-precision optimistic concurrency clock.
• xf_xo BIT DEFAULT 0 - System logical-delete / active status gate.

2.4 Virtual Active Record

At runtime, xF constructs an in-memory dictionary for each active entity, binding z‑segment state and y‑segment metadata on the fly without static compile-time ORM mapping classes.

2.5 How Metadata Drives the Entire Stack

• Storage: Auto-DDL builds and alters physical tables directly from schema declarations.
• Transport: Metadata specifies exact JSON field projections, validation constraints, and lookup arrays.
• UI: Determines control-type components, visual grouping, and dynamic layout templates.
• Validation: Enforces required fields, data formats, and role-based permissions without imperative check routines.
• Logic: Coordinates intent routing, sandboxed Logic Gateway execution, and external webhooks.

2.6 Entity Definition: Deep Dive

Entities represent business records persisted into physical tables managed via Auto-DDL. They declare identity keys, validation invariants, default page templates, and rights profiles.

2.7 Attribute Definition: Deep Dive

Attributes declare individual data points on entities, binding physical storage types to semantic UI controls and parameterized lookup SQL. Foreign key properties strictly end with an underscore (_).

{
  "property_name": "driver_",
  "header": "Driver",
  "entity_": 1014,
  "xfctrltype": 1303,
  "valuetype": 7,
  "my_fkentityid": 1002,
  "isstrid": true,
  "ismandatory": true,
  "gui_section": "s0"
}

2.8 Control Types: Deep Dive

Control types represent the UI grammar of xF. They map directly to micro-templates that know how to hydrate data from the dual-payload wire format.

2.9 Aggregates in the Meta-Model

Aggregates are transient workflow containers that have no physical table. They use the same transport format and validation mechanics as persistent entities.

2.10 Security in the Meta-Model

Security is integrated into the metadata graph. Fine-Grained Access Control (FGAC) prunes unauthorized fields from the y-segment before transmission.

2.11 Metadata Governance

Because metadata is executable, all registry changes are audited, versioned, and reversible to prevent workflow disruptions.

2.12 Canonical Attribute Properties in zxf_attribute

Chapter 3 - Creating Your First Entity

3.1 Complete Entity Lifecycle

Building an entity requires zero imperative backend code or manual database migration scripts. Follow these step-by-step procedures:

Step 1 - Register the Entity in zxf_entity

POST the entity configuration payload to /api/xf_set:

{
  "xf_entity": "zxf_entity",
  "xf_id": -1,
  "objectname": "rb_client",
  "header": "Client",
  "app_": 2,
  "basetable": "T_RB_CLIENT",
  "isaggregate": false,
  "isdeletable": true
}

Step 2 & 3 - Define Attributes in zxf_attribute

Add the natural identifier (name) and domain attributes. Notice we do not define client_id; the runtime assigns xf_id inherently.

[
  {
    "xf_entity": "zxf_attribute",
    "xf_id": -1,
    "entity_": 1010,
    "property_name": "name",
    "header": "Client Name",
    "xfctrltype": 1100,
    "valuetype": 60,
    "isstrid": true,
    "ismandatory": true,
    "isunique": true
  },
  {
    "xf_entity": "zxf_attribute",
    "xf_id": -1,
    "entity_": 1010,
    "property_name": "phone",
    "header": "Phone",
    "xfctrltype": 1100,
    "valuetype": 60,
    "isstrid": false
  },
  {
    "xf_entity": "zxf_attribute",
    "xf_id": -1,
    "entity_": 1010,
    "property_name": "email",
    "header": "Email",
    "xfctrltype": 1100,
    "valuetype": 60,
    "isstrid": false
  }
]

Step 4 - Define Relationships (Foreign Key Underscore Convention)

When modeling a dependent entity such as rb_trip, foreign keys to rb_driver and rb_vehicle end with an underscore (driver_, vehicle_):

[
  {
    "xf_entity": "zxf_attribute",
    "xf_id": -1,
    "entity_": 1014,
    "property_name": "driver_",
    "header": "Driver",
    "xfctrltype": 1303,
    "valuetype": 7,
    "my_fkentityid": 1002,
    "isstrid": true
  },
  {
    "xf_entity": "zxf_attribute",
    "xf_id": -1,
    "entity_": 1014,
    "property_name": "vehicle_",
    "header": "Vehicle",
    "xfctrltype": 1303,
    "valuetype": 7,
    "my_fkentityid": 1001,
    "isstrid": true
  }
]

Step 5 - Auto-DDL Physical Table Generation

Auto-DDL translates these declarations into physical database tables:

CREATE TABLE T_RB_CLIENT (
    xf_id INT IDENTITY(1,1) PRIMARY KEY,
    xf_guid UNIQUEIDENTIFIER DEFAULT NEWID(),
    xf_version DATETIME DEFAULT GETDATE(),
    xf_xo BIT DEFAULT 0,
    name VARCHAR(255) NOT NULL UNIQUE,
    phone VARCHAR(60),
    email VARCHAR(60)
);

CREATE TABLE T_RB_TRIP (
    xf_id INT IDENTITY(1,1) PRIMARY KEY,
    xf_guid UNIQUEIDENTIFIER DEFAULT NEWID(),
    xf_version DATETIME DEFAULT GETDATE(),
    xf_xo BIT DEFAULT 0,
    driver_ INT,
    vehicle_ INT,
    booking_ INT,
    leg INT,
    starttime INT,
    rate_amount FLOAT
);

Step 6 - Dual Payload Wire Exchange (GET)

Fetching an instance via GET /api/xf_get/rb_booking/5/_/_ returns the hydrated dual payload:

{
  "z": {
    "xf_entity": "rb_booking",
    "xf_id": 5,
    "xf_guid": "d6d366ea-f83c-49cd-932d-e768d66c0006",
    "xf_version": "2026-09-16T17:25:47.423",
    "bookingno": 1004,
    "pax": 15,
    "tripdate": "2026-09-16",
    "pickup_location": "Plaza Hotel",
    "dropoff_location": "Paradise Bay",
    "client_": 1,
    "client__tostr": "NSTS",
    "route_": 3,
    "route__tostr": "MIA - Cirkewwa",
    "amount": 45,
    "currency": "EUR",
    "status": 0,
    "invoice_": -1,
    "xf_e": 0
  },
  "y": {
    "xf_gx": [
      { "id": "s0", "col": "col-xs-12 col-sm-6", "card": "card" },
      { "id": "s1", "col": "col-xs-12 col-sm-6", "card": "card" }
    ],
    "client_": {
      "id": 10039,
      "h": "Client",
      "q": 1320,
      "u": 7,
      "p1": [{ "Name": "NSTS" }],
      "p2": "rb_client"
    },
    "status": {
      "id": 10049,
      "h": "Status",
      "q": 1318,
      "p10": [
        { "k": "Active", "v": 0 },
        { "k": "Cancelled", "v": 10 }
      ]
    }
  }
}

Step 7 - Persisting Mutations (POST)

Clients send only the mutated z‑segment to POST /api/xf_set:

{
  "xf_entity": "rb_booking",
  "xf_id": 5,
  "xf_version": "2026-09-16T17:25:47.423",
  "xf_e": 0,
  "bookingno": 1004,
  "pickuptime_return": 1540,
  "amount": 45,
  "status": 0
}

Step 8 - Execution Protocol Concurrency Validation

The runtime persists the entity, advances the continuation token, and sets the commit guard:

{
  "xf_entity": "rb_booking",
  "xf_id": 5,
  "xf_guid": "d6d366ea-f83c-49cd-932d-e768d66c0006",
  "xf_version": "2026-10-01T14:23:16.087",
  "xf_f": "save",
  "xf_xu": "",
  "xf_e": 1,
  "xf_ex": "Instance Saved Successfully",
  "bookingno": 1004,
  "pickuptime_return": 1540,
  "amount": 45,
  "status": 0
}

Chapter 4 - Building Aggregates

4.1 What Aggregates Are in xF

An Aggregate in xF is a transient, in‑memory workflow container or orchestration planner. It is registered in zxf_entity with isaggregate: true. Aggregates behave like entities in every way that matters to the runtime - same JSON transport shape, same execution protocol, same validation rules - but they do not have a physical CRUD database table. Instead of representing stored domain records, an aggregate represents workflow state: the information a user enters or the system accumulates while moving through a multi‑step process (such as rb_newtrip / "Manage Bookings").

This design allows aggregates to act as wizards, planners, envelopes, onboarding flows, multi‑stage forms, or orchestration containers. They are created, mutated, and discarded entirely in memory, with no persistence unless the workflow explicitly commits data into a persistent entity.

4.2 Why Aggregates Exist

In conventional systems, multi‑step workflows require controllers, session state, temporary tables, or workflow engines. These approaches introduce complexity, state management overhead, and brittle coupling between UI and backend logic. xF eliminates all of this by treating workflows as first‑class metadata objects. An aggregate carries the same execution protocol, the same intent tokens, and the same continuation addresses, but its lifecycle is ephemeral.

4.3 Entities vs Aggregates

4.4 How Aggregates Drive Workflows

Aggregates rely on the Execution Protocol to move through workflow steps. Each POST carries an intent token (xf_f) and a continuation address (xf_xu) that tell the runtime what should happen next. The Logic Gateway / Function Route can mutate these fields to advance the workflow, branch into different paths, or trigger external REST calls via the Router.

4.5 SQL and Aggregates

Although aggregates do not have tables, they heavily utilize SQL‑in‑metadata (xt) to hydrate lookup lists, populate datagrids, or fetch contextual information needed for an allocation planner. This allows aggregates to combine transient workflow state with persistent domain data without storing anything themselves.

4.6 Hydrating Aggregates via Parameterized SQL (xt)

Aggregates use the xt slot in zxf_attribute to evaluate SQL on GET, binding parameters from the active context (e.g. @tripdate) and returning the resulting data table directly to the frontend:

SELECT
    b.xf_id,
    r.identifier AS route_identifier,
    b.bookingno,
    CONVERT(char(10), b.tripdate, 105) AS tripdate,
    b.pickup_location,
    b.dropoff_location,
    c.name AS client_name,
    t_on.xf_id AS onward_trip_id,
    v_on.identifier AS onward_vehicle,
    d_on.name AS onward_driver
FROM T_RB_BOOKING b
LEFT JOIN T_RB_CLIENT c ON c.xf_id = b.client_
LEFT JOIN T_RB_ROUTE r ON r.xf_id = b.route_
LEFT JOIN T_RB_TRIP t_on ON t_on.booking_ = b.xf_id AND t_on.leg = 0 AND t_on.xf_xo = 0
LEFT JOIN T_RB_VEHICLE v_on ON v_on.xf_id = t_on.vehicle_
LEFT JOIN T_RB_DRIVER d_on ON d_on.xf_id = t_on.driver_
WHERE b.xf_xo = 0
  AND b.status = 0
  AND b.tripdate = @tripdate
ORDER BY b.xf_id DESC;

4.7 Aggregate Execution Protocol Example

{
  "xf_entity": "rb_newtrip",
  "xf_guid": "3bbb449b-ab23-488c-b34f-f8d923c156ea",
  "xf_version": "2026-09-14T19:49:35.28",
  "xf_f": "allocate_driver",
  "xf_xu": "rb_newtrip",
  "xf_xt": null,
  "xf_e": 0,
  "tripdate": "2026-10-01",
  "booking_": 5,
  "driver_": 12,
  "vehicle_": 8,
  "leg": 0
}

4.8 Why Aggregates Are a Major Architectural Advantage

• stateless - every step is encoded in the payload
• auditable - every POST is logged in the State Log
• AI-friendly - workflows are declarative, not imperative
• easy to evolve - changing a step is a metadata update
• safe - Logic Gateway enforces deterministic transitions

Chapter 5 - Control Types & UI Rendering

5.1 What Control Types Are

Control types in xF are identified by numeric integer keys in metadata (xfctrltype), which render as q in the wire metadata. They are semantic UI contracts defined entirely in metadata. Each control type tells the runtime three things: how a field should be rendered, how it should be hydrated, and what SQL shape it expects when lookup data is required.

5.2 Why Control Types Matter

• Template resolution: which HTML component to render.
• SQL contract: which columns must be returned for lookup data.
• Hydration rules: how p10 arrays populate dropdowns, grids, and charts.
• Validation behavior: how the frontend enforces required fields or numeric constraints.
• Event semantics: how user interactions propagate back into the z‑segment.

5.3 How Control Types Drive Rendering

When the frontend receives a y‑segment, it inspects each attribute’s control type and loads the corresponding component template. For example, a field with xfctrltype: 1303 is rendered using /components/q1303/q1303.html.

5.4 Canonical Control Types

5.5 Control-Type UI Template Contracts

Component templates load directly from /components/qXXXX/qXXXX.html, binding directly to xz (data) and xy (metadata):

<input type="text" v-model="xz[ATTR]" class="form-control" />

<select v-model="xz[ATTR]" class="form-select">
  <option v-for="row in xy[ATTR].p10" :value="row.v">
    {{ row.k }}
  </option>
</select>

<table class="table table-striped">
  <thead>
    <tr>
      <th v-for="col in xy[ATTR].columns">{{ col }}</th>
    </tr>
  </thead>
  <tbody>
    <tr v-for="row in xz[ATTR]">
      <td v-for="col in xy[ATTR].columns">{{ row[col] }}</td>
    </tr>
  </tbody>
</table>

5.6 Lazy Vendor Loading

Heavy component dependencies (such as SheetJS and FileSaver for 1504) are lazy-loaded only when the component appears on screen:

XF.loadScript('/vendor/sheetjs/xlsx.full.min.js');
XF.loadScript('/vendor/filesaver/FileSaver.min.js');

window.F.q1504 = {
  saveToExcel() {
    // uses SheetJS
  }
};

5.7 Control Types and Custom Page Overrides

The zero-build frontend checks for custom page overrides specified in zxf_entity.componentpage (e.g. rb_newtrip), falling back to generic layout synthesis if unspecified.

5.8 Control Types and Transport Isomorphism

Because entities and aggregates share identical serialization, control types bind to transactional records and ephemeral workflow containers with identical templates, binding syntax, and event semantics.

5.9 Control Types and Execution Protocol Interaction

UI components update fields directly in the z-segment. Form submissions post only the z-segment with xf_e: 0. After server commitment, the returned payload carries xf_e: 1, preventing duplicate execution.

Chapter 6 – Writing Logic in xF

6.1 The Three Logic Surfaces

xF executes business logic through three deterministic surfaces. Importantly, every POST passes through compiled or JIT logic before any persistence occurs. Auto‑CRUD is not a standalone backend; it is the persistence layer applied after user-defined logic completes successfully.

1. Compiled Logic + Auto‑CRUD (Default POST Path): When a POST arrives with a blank intent token (xf_f), the payload is still routed through the application's compiled DLL. Production systems typically use a dispatcher (e.g., a switch on entity name) to invoke the correct function for the entity being saved. This function may perform rigorous validation, throw exceptions, update related entities, increment counters, round values, or enforce domain rules. Only after the function returns without error does Auto‑CRUD apply the database mutation and record the transition in the State Log.
2. SQL‑in‑Metadata (GET Hydration Only): Parameterized xt scripts executed during GET. These scripts retrieve lookup lists, grids, charts, and other UI-bound datasets. They are strictly SELECT statements and never mutate state.
3. Function Routes (zxf_router): Declarative routing entries that bind an intent token to either:
   • Internal logic — Roslyn C# JIT scripts (rawcode) or compiled DLL assemblies.
   • External REST endpoints — when is_external = true, the runtime forwards the payload to the URI specified in uri, applying authentication headers stored in authsettings.
   In JIT mode, the frontend must set xf_f so the runtime knows which function to execute. This mechanism implements the Intent‑Routed State Transfer (IntRST) pattern: the client declares intent, and the server resolves the physical destination at request time from governed metadata.

6.2 Why Logic Is Structured This Way

xF separates semantic intent from physical routing. Business rules express what should happen by assigning an intent token; the runtime decides how and where it happens. This preserves client‑side topology opacity, enables late‑bound workflow evolution, and keeps routing decisions governed by metadata rather than compiled code.

6.3 Auto‑CRUD Logic

When a POST arrives at /api/xf_set without an intent token, the Auto‑CRUD engine executes. It validates rights, checks xf_version, applies mutations to the entity’s physical table, and records the transition in the State Log. No custom code is required for standard persistence.

6.4 Writing Logic Gateway Functions (Roslyn C# JIT)

Internal business rules are registered in T_ZXF_ROUTER with is_external = false. When is_dynamic = true, the runtime compiles the C# script stored in rawcode using Roslyn JIT at startup. All functions receive the active state dictionary:

Logic functions may mutate the intent token (e.g., Dx["xf_f"] = "flag_for_review"), allowing dynamic workflow redirection. The function does not know the physical destination; the runtime resolves it from T_ZXF_ROUTER after the function returns.

6.5 External REST Routing (IntRST)

When a route entry specifies is_external = true, xF forwards the payload to the external REST endpoint defined in uri. Authentication headers, API keys, or bearer tokens are stored directly in authsettings and applied automatically during dispatch.

This mechanism is the concrete realization of the Intent‑Routed State Transfer (IntRST) pattern: the client posts to a single unified endpoint, declares an intent token, and the server resolves the next physical hop from metadata. External integrations therefore require no client changes, no controller wiring, and no redeployment — only a new row in T_ZXF_ROUTER.

6.6 Choosing the Correct Logic Surface

• Auto‑CRUD — simple persistence, no custom rules.
• SQL‑in‑Metadata — read‑only UI hydration.
• Internal Function Route — business rules, validation, multi‑entity logic.
• External Function Route — REST integrations, third‑party APIs, compliance checks.

The developer’s responsibility is limited to expressing semantic intent and writing stateless logic. Routing, orchestration, and physical destination binding remain metadata‑governed.

6.7 Real-World Example: Auto-Incrementing Invoice on Save

The following script inspects Dx["xf_id"]. If negative (a new record), it calculates the next invoice number using a database query. If existing, it checks the semantic intent token (xf_f) to associate or remove booking items:

private void f_rb_invoice(ref Dictionary Dx)
{
    try
    {
        // Safe conversion / comparison: negative xf_id indicates a new unsaved record
        if (Convert.ToInt32(Dx["xf_id"]) < 0)
        {
            using (SqlCommand cmd1 = new SqlCommand())
            {
                cmd1.CommandText = "SELECT ISNULL(MAX(invoiceno) + 1, 1000) AS bn FROM T_RB_INVOICE";
                DataTable dT1 = xf.core.CommandCenter.Instantiate().GetDataTable(cmd1);

                if (dT1.Rows.Count > 0)
                {
                    Dx["invoiceno"] = dT1.Rows[0]["bn"];
                }
            }
        }
        else
        {
            // Existing invoice: dispatch on semantic intent token
            string xfF = Dx.ContainsKey("xf_f") ? Dx["xf_f"]?.ToString() : null;

            if (xfF == "save_booking")
            {
                int bookingId = -1;
                int.TryParse(Dx.ContainsKey("bookings") ? Dx["bookings"]?.ToString() : null, out bookingId);

                if (bookingId > 0)
                {
                    using (SqlCommand cmd1 = new SqlCommand())
                    {
                        cmd1.CommandText = "UPDATE T_RB_BOOKING SET invoice_=@invoice_ WHERE xf_id=@xf_id";
                        cmd1.Parameters.AddWithValue("@xf_id", bookingId);
                        cmd1.Parameters.AddWithValue("@invoice_", Dx["xf_id"]);
                        xf.core.CommandCenter.Instantiate().ExecuteNonQuery(cmd1);
                    }
                }
            }
            else if (xfF == "del_booking")
            {
                int bookingId = -1;
                int.TryParse(Dx.ContainsKey("bookings") ? Dx["bookings"]?.ToString() : null, out bookingId);

                if (bookingId > 0)
                {
                    using (SqlCommand cmd1 = new SqlCommand())
                    {
                        cmd1.CommandText = "UPDATE T_RB_BOOKING SET invoice_=-1 WHERE xf_id=@xf_id";
                        cmd1.Parameters.AddWithValue("@xf_id", bookingId);
                        xf.core.CommandCenter.Instantiate().ExecuteNonQuery(cmd1);
                    }
                }
            }
        }
    }
    catch (Exception ex)
    {
        Dx["xf_e"] = -1;
        Dx["xf_ex"] = ex.Message;
    }
}

6.8 External REST Logic via Router

The Route Register handles external integrations declaratively. When is_external: true, clients send a semantic intent token (xf_f), and the runtime handles endpoint address resolution, token authentication, and JSON field mapping.

6.9 Temporal Recursion (xf_xt)

The field xf_xt declares a millisecond delay before the next automated POST. When the server returns a payload containing xf_xt, the generic client schedules a re-dispatch after that interval, without maintaining any workflow state or timers of its own.

For example, setting xf_xt: 5000 instructs the client to re-POST the same payload in 5,000 milliseconds. This enables background workflows to poll asynchronous jobs or refresh dashboards without blocking server worker threads or requiring any client-side logic.

Practical Example: Live Operational Dashboard

A production deployment for a tour operator uses this mechanism to power a live dashboard mounted on a wall display in their office. The dashboard shows all events for the week, including remaining seat availability. When an event is nearly full, its icon blinks, prompting staff to allocate additional resources (for example, switching to larger boats).

The dashboard is implemented as an HTML weekly calendar-like controltype bound to aggregate's attribute. No special infrastructure is required. The aggregate’s metadata sets xf_xt = 30000, causing the client to automatically refresh every 30 seconds. If faster updates are needed, the administrator simply edits the metadata and sets xf_xt = 15000. The change takes effect immediately, without redeploying any code or modifying the client.

Temporal recursion therefore provides a lightweight, declarative mechanism for periodic refreshes and asynchronous orchestration. The client remains a generic interpreter; the timing behavior is entirely governed by metadata.

6.10 Commit Guard (xf_e)

The commit guard enforces that only uncommitted payloads (xf_e: 0) can be submitted. The server transitions xf_e to 1 on commit, preventing duplicate form submissions and replay attacks.

6.11 Logic Safety Rules

• No direct raw SQL injection; always bind parameters via SqlCommand.Parameters
• No mutation of y‑segment
• No reflection or unsafe code
• Errors must set Dx["xf_e"] = -1 and populate Dx["xf_ex"]
• No long‑running blocking operations

Chapter 7 - SQL‑in‑Metadata

7.1 Purpose and Execution Model

Instead of scattering queries across controllers or repositories, declarative SQL queries are configured directly inside zxf_attribute.xt. When a record is fetched, xF binds matching parameters from the current context and delivers the results inside xy.

-- @xf_id is automatically bound from z.xf_id
SELECT xf_id, bookingno, pickup_location, amount
FROM T_RB_BOOKING
WHERE client_ = @xf_id
  AND xf_xo = 0
ORDER BY xf_id DESC;

7.2 Why SQL‑in‑Metadata Exists

Treating SQL as a declarative part of metadata eliminates DTOs, custom hydration endpoints, and glue code, keeping data access predictable and transparent.

7.3 Parameter Binding Rules

• Named tokens matching @key bind directly to z[key] (e.g. @tripdate binds from z.tripdate).
• System tokens like @xf_id, @xf_userid, and @xf_domain bind inherently by the runtime engine.
• Null values bind safely as SQL NULL.

7.4 SQL Column Contracts

Control types enforce strict alias requirements (e.g., k and v for 1318), ensuring the frontend interpreter stays decoupled from table schemas.

7.5 SQL for Dropdowns (1303)

SELECT xf_id AS v, name AS k
FROM T_RB_DRIVER
WHERE xf_xo = 0
ORDER BY name;

7.6 SQL for Datagrids (1500)

SELECT
    b.xf_id,
    b.bookingno,
    c.name AS client_name,
    b.amount
FROM T_RB_BOOKING b
LEFT JOIN T_RB_CLIENT c ON c.xf_id = b.client_
WHERE b.tripdate = @tripdate AND b.xf_xo = 0;

7.7 SQL Safety Rules

• No dynamic SQL concatenation
• No unbound query parameters
• Must be read-only unless executing inside a controlled function route
• Pre-validated at metadata registration time

Chapter 8 - Execution Protocol & Workflow Design

8.1 The Execution Protocol State Machine

The Execution Protocol turns every HTTP cycle into a finite state machine transition:

8.2 Protocol Fields Specification

8.3 Intent (xf_f) and Continuation Address (xf_xu)

xf_f instructs the backend which operation to run (e.g. save_booking, del_booking, commit), while xf_xu tells the zero-build frontend which view template to load next.

8.4 Temporal Recursion (xf_xt)

When an asynchronous process is pending, the server returns an xf_xt interval. The client waits that duration before automatically re-issuing a POST, eliminating the need for server-side polling worker daemons.

8.5 Commit Guard (xf_e) and Concurrency (xf_version)

To protect against replay attacks and double submits, incoming POST payloads must have xf_e: 0. The server marks xf_e: 1 once processing is committed. Mismatches in xf_version trigger optimistic concurrency rejections.

8.6 Conditional Branching via Function Routes

Business logic modifies xf_f and xf_xu dynamically at runtime to steer users through different branches:

if (Convert.ToDecimal(Dx["rate_amount"]) > 1000)
{
    Dx["xf_f"] = "flag_for_review";
    Dx["xf_xu"] = "booking.review";
}
else
{
    Dx["xf_f"] = "confirm_allocation";
    Dx["xf_xu"] = "rb_newtrip";
}

Chapter 9 - Security (RBAC, FGAC, Rights Registry, Audit)

9.1 Declarative Zero-Trust Security

In xF, security is not an auxiliary filter bolted onto individual web controllers. It is evaluated directly on the metadata graph:

• Entity Authorization: Controlled via zxf_entity.allowanonget and allowanonpost.
• Field Pruning: Unauthorized attributes are stripped from both the z‑segment and y‑segment before payload serialization.
• SQL Safeguards: Metadata attributes validate permissions using deny_get and deny_set SQL expressions.

9.2 The Four Layers of Security

1. RBAC: Controls top-level read, write, and delete operations on entities.
2. FGAC: Controls field-level visibility and mutability per user role.
3. Rights Registry: Maps principals to entities, attributes, and intent tokens.
4. Audit Layer: Records state snapshots, metadata updates, and external API requests.

9.3 Field Pruning in the Dual Payload

During GET, attributes for which the user lacks read permissions are stripped from both the y‑segment and z‑segment. During POST, unauthorized field updates are rejected at the boundary.

9.4 Audit Trail and State Logs

Audit logging is native to xF. Every commit creates an entry in the State Log capturing the user, timestamp, full payload, and intent token.

Chapter 10 - Debugging & Diagnostics

10.1 Debugging Surfaces in xF

Because xF is metadata-interpreted rather than compiled, conventional IDE line debuggers are replaced by structured diagnostic inspection surfaces:

1. Metadata Diagnostics: Inspect zxf_entity, zxf_attribute, and column contract compliance.
2. SQL Execution Diagnostics: Copy parameterized SQL directly to check binding resolution and column alias matching.
3. Execution Protocol Tracing: Inspect payload state transitions (xf_f, xf_xu, xf_e, xf_ex).
4. Logic Gateway Interception: Verify z-segment mutations before and after Roslyn C# script execution.
5. The State Log: Query historical snapshots of all prior transitions.

10.2 Diagnosing Common Subsystems

• Empty Dropdowns / Grids: Verify that SQL column aliases match control contracts (e.g., k, v for 1318).
• Stuck Workflows: Check whether xf_f or xf_xu was set correctly by the function route.
• Rejected Submissions: Inspect xf_e (must be 0 on incoming POST) or verify user permissions.
• Schema Drift: Inspect Auto-DDL logs to confirm table synchronization.

{
  "timestamp": "2026-10-01T14:23:16.087",
  "xf_entity": "rb_booking",
  "xf_id": 5,
  "xf_guid": "d6d366ea-f83c-49cd-932d-e768d66c0006",
  "xf_f": "save",
  "xf_xu": "",
  "client_": 1,
  "route_": 3,
  "amount": 45
}

Chapter 11 - Deployment & Operations

11.1 Operational Simplicity

xF provides unprecedented operational simplicity: zero frontend bundling, no controllers to deploy, no database migration scripts, and stateless horizontal scaling.

11.2 Deployment Components

• Runtime (Backend): Stateless microservice container interpreting the metadata graph.
• Metadata Registry (Database): Declarative database tables governing domain models and routing.
• Zero-Build Frontend: Static HTML shell, core scripts (xfvue.js, xpv.js), and component templates.
• Function Routes: Dynamic Roslyn scripts stored in zxf_router.rawcode.

11.3 Deployment Lifecycle

• Runtime: Deployed as stateless microservice containers behind standard load balancers.
• Metadata Registry: Exported, versioned, and loaded into database tables.
• Auto-DDL: Automatically synchronizes physical tables to match the imported metadata.
• Frontend: Served as static HTML shells and component templates directly from CDN or web servers.

11.4 Scaling & Multi-Tenancy

Because the runtime does not maintain server-side sessions, instances can scale horizontally. Multi-tenancy is handled at the metadata graph layer, allowing tenants to run on shared compute while maintaining isolated configurations scoped via zxf_app.

Chapter 12 - AI‑Assisted Development & MCP Integration

12.1 The AI-xF Synergy: Professional Vibe-Coding

Large Language Models are exceptionally proficient at producing declarative JSON, SQL, and structured schemas, but prone to hallucinations when writing large-scale imperative codebases. xF provides the deterministic execution substrate that AI cannot break.

By pairing xF with the Model Context Protocol (MCP) and a Bring-Your-Own-AI (BYOAI) philosophy, xF establishes a new category: Enterprise Vibe-Coding. Teams gain the velocity of AI creation with enterprise guardrails, zero vendor lock-in, and zero unmaintainable code sprawl.

12.2 What MCP Brings to xF

The Model Context Protocol (MCP) is an open standard that enables AI hosts - such as Claude Desktop, ChatGPT, VS Code, Cursor, and custom agents - to safely discover a product's structure and invoke its capabilities.

• Meta-Model Discovery Tools: Lets any LLM query existing entities, attributes, and control types directly.
• Control-Type Contracts (numeric xfctrltype): Informs the agent which SQL column aliases are required for UI components.
• Verification Endpoints: Synthesizes proposed metadata and verifies schema compatibility before any database table or UI component updates.
• Built-in GPT-4.1 Mini Endpoint: xF includes a native 1M-token context LLM endpoint pre-loaded with this technical manual, ready for zero-setup execution.

12.3 The Visual Mockup-to-Metadata Workflow (Figma / UI Intake)

12.4 AI Workflow Example

{
  "objectname": "rb_vehicle",
  "header": "Vehicle",
  "basetable": "T_RB_VEHICLE",
  "app_": 2,
  "isaggregate": false,
  "attributes": [
    { "property_name": "identifier", "header": "Number Plate", "xfctrltype": 1100, "valuetype": 60, "isstrid": true, "ismandatory": true },
    { "property_name": "type_", "header": "Vehicle Type", "xfctrltype": 1303, "valuetype": 7, "my_fkentityid": 1017 },
    { "property_name": "capacity", "header": "Pax Capacity", "xfctrltype": 1105, "valuetype": 10 },
    { "property_name": "status", "header": "Status", "xfctrltype": 1318, "valuetype": 10 }
  ]
}

12.5 Incremental Commit Protocol (Preventing Bulk Hallucinations)

A crucial rule of xF's AI integration is strict atomic verification. While generative models can draft dozens of attributes simultaneously, xF enforces that changes are applied sequentially:

1. Entity Declaration: Insert into zxf_entity first, validating table naming and key strategies.
2. Attribute-by-Attribute Insertion: Add each field with its designated data type and control type (xfctrltype). Auto-DDL incrementally validates column definitions.
3. Lookup SQL Binding: Test SQL queries against the database schema to ensure column alias compliance.
4. Zero-Build Preview: Verify the live rendered component in the zero-build frontend interpreter before proceeding to subsequent workflow steps.

Appendix A - Metadata Schema Bundle

Canonical schemas governing the authoritative metadata tables.

A.1 Entity Schema (zxf_entity)

{
  "objectname": "string",
  "header": "string",
  "app_": "number",
  "isaggregate": "boolean",
  "basetable": "string",
  "isdeletable": "boolean",
  "componentpage": "string|null",
  "qry_orderbycolumns": "string|null"
}

A.2 Attribute Schema (zxf_attribute)

{
  "property_name": "string",
  "header": "string",
  "entity_": "number",
  "xfctrltype": "number",
  "valuetype": "number",
  "my_fkentityid": "number|null",
  "isstrid": "boolean",
  "isunique": "boolean",
  "ismandatory": "boolean",
  "isnullable": "boolean",
  "defaultvalue": "string|null",
  "gui_section": "string|null",
  "xt": "string|null"
}

A.3 Control Type Schema (zxf_controltype)

{
  "control": "number",
  "columns": ["string"],
  "bind": "string",
  "component": "string",
  "script": "string|null",
  "vendor": ["string"]
}

A.4 Router Schema (zxf_router)

{
  "entity_": "number",
  "functionname": "string",
  "is_dynamic": "boolean",
  "is_external": "boolean",
  "uri": "string|null",
  "rawcode": "string|null"
}

A.5 Rights Schema (zxf_rights)

{
  "role": "string",
  "entity": "string",
  "attribute": "string|null",
  "intent": "string|null",
  "rights": ["read", "write", "execute"]
}

A.6 Execution Protocol Schema

{
  "xf_entity": "string",
  "xf_id": "number",
  "xf_guid": "string",
  "xf_version": "string",
  "xf_f": "string",
  "xf_xu": "string",
  "xf_xt": "number|null",
  "xf_e": "number",
  "xf_ex": "string|null"
}

A.7 SQL-in-Metadata Schema

{
  "property_name": "string",
  "xt": "string",
  "columns": ["string"]
}

Appendix B - Control‑Type Contracts

B.2 Control-Type Contract Schema

{
  "control": "number",
  "columns": ["string"],
  "bind": "string",
  "component": "string",
  "script": "string|null",
  "vendor": ["string"],
  "options": "object|null"
}

B.4 Text Input (1100)

{
  "control": 1100,
  "columns": [],
  "bind": "ATTRIBUTE",
  "component": "q1100.html",
  "script": null,
  "vendor": []
}

B.5 Hidden / Numeric Key (1101)

{
  "control": 1101,
  "columns": [],
  "bind": "ATTRIBUTE",
  "component": "q1101.html",
  "script": null,
  "vendor": []
}

B.6 Integer (1105) & Decimal (1106)

{
  "control": 1106,
  "columns": [],
  "bind": "ATTRIBUTE",
  "component": "q1106.html",
  "script": null,
  "vendor": []
}

B.9 FK Dropdown Contract (1303)

{
  "control": 1303,
  "columns": ["v", "k"],
  "bind": "driver_",
  "component": "q1303.html",
  "script": "q1303.js",
  "vendor": []
}

B.10 Dropdown Key-Value Contract (1318)

{
  "control": 1318,
  "columns": ["k", "v"],
  "bind": "status",
  "component": "q1318.html",
  "script": "q1318.js",
  "vendor": []
}

B.11 Datatable from Parameterized Query (101)

{
  "control": 101,
  "columns": ["xf_id", "bookingno", "client_name"],
  "bind": "bookings",
  "component": "q101.html",
  "script": "q101.js",
  "vendor": ["sheetjs"]
}

Appendix C - Execution Protocol Deep Specification

C.3 Wire Payload Schema

{
  "xf_entity": "string",
  "xf_id": "number",
  "xf_guid": "string",
  "xf_version": "string",
  "xf_f": "string",
  "xf_xu": "string",
  "xf_xt": "number|null",
  "xf_e": "number",
  "xf_ex": "string|null"
}

C.4 Complete Field Specification

• xf_entity: Target aggregate or entity key in zxf_entity.
• xf_id: Physical primary key integer (negative e.g. -1 for new unsaved records).
• xf_guid: Global identity GUID maintained across multi-stage wizard hops.
• xf_version: ISO timestamp concurrency clock (checked on POST; incremented on successful write).
• xf_f: Intent token dispatched to Auto-CRUD, Function Route, or IntRST Router.
• xf_xu: Continuation route address consumed by the frontend to render the next step.
• xf_xt: Polling delay in milliseconds for asynchronous recursive execution.
• xf_e: Execution lock gate (0 allows submission; 1 marks committed record; -1 marks error).
• xf_ex: Diagnostic feedback string (e.g. "Instance Saved Successfully" or exception text).

Appendix D - Router / IntRST Specification

Intent-Routed State Transfer defines external REST integrations directly within metadata.

D.3 Router Entry Schema (zxf_router)

{
  "entity_": 1015,
  "functionname": "f_rb_invoice",
  "is_dynamic": true,
  "is_external": false,
  "uri": "",
  "rawcode": "private void f_rb_invoice(ref Dictionary Dx) { ... }"
}

Appendix E - SQL‑in‑Metadata Patterns

-- Auto-increment calculation inside function route:
SELECT ISNULL(MAX(invoiceno) + 1, 1000) AS bn FROM T_RB_INVOICE;

-- Parameterized child query binding @tripdate:
SELECT
    b.xf_id,
    b.bookingno,
    c.name AS client_name,
    r.fromloc AS route_from,
    r.toloc AS route_to
FROM T_RB_BOOKING b
LEFT JOIN T_RB_CLIENT c ON c.xf_id = b.client_
LEFT JOIN T_RB_ROUTE r ON r.xf_id = b.route_
WHERE b.tripdate = @tripdate AND b.xf_xo = 0;

Appendix F - Rights Registry Specification

[
  {
    "role": "ops",
    "entity": "rb_booking",
    "attribute": null,
    "intent": null,
    "rights": ["read", "write"]
  },
  {
    "role": "reviewer",
    "entity": "rb_booking",
    "attribute": "status",
    "intent": null,
    "rights": ["read"]
  },
  {
    "role": "reviewer",
    "entity": "rb_newtrip",
    "intent": "approve",
    "rights": ["execute"]
  }
]

Appendix G - Auto‑DDL Specification

Auto-DDL translates metadata declarations into deterministic physical schema commands:

CREATE TABLE T_CUSTOMER (
    xf_id INT IDENTITY(1,1) PRIMARY KEY,
    xf_guid UNIQUEIDENTIFIER DEFAULT NEWID(),
    xf_version DATETIME DEFAULT GETDATE(),
    xf_xo BIT DEFAULT 0,
    customer_name VARCHAR(255) NOT NULL UNIQUE,
    status INT DEFAULT 0
);

CREATE TABLE T_RB_TRIP (
    xf_id INT IDENTITY(1,1) PRIMARY KEY,
    xf_guid UNIQUEIDENTIFIER DEFAULT NEWID(),
    xf_version DATETIME DEFAULT GETDATE(),
    xf_xo BIT DEFAULT 0,
    driver_ INT,
    vehicle_ INT,
    booking_ INT,
    leg INT,
    rate_amount FLOAT
);

Appendix H - Zero‑Build Frontend Specification

The zero-build frontend interpreter loads components on demand, binding xz (data) and xy (metadata) using xpv.js without client build tooling.

{
  "frontend": {
    "shell": "root/index.html",
    "scripts": ["xpv.js", "petite-vue.iife.js"],
    "components": {
      "1100": { "component": "q1100.html", "script": null },
      "1303": { "component": "q1303.html", "script": "q1303.js" },
      "101": { "component": "q101.html", "script": "q101.js", "vendor": ["sheetjs"] }
    },
    "custom_pages": {
      "rb_newtrip": "rb_newtrip.html"
    }
  }
}

Appendix I - Logic Gateway Specification

[
  {
    "entity_": 1015,
    "functionname": "f_rb_invoice",
    "is_dynamic": true,
    "type": "roslyn_jit"
  },
  {
    "entity_": 1018,
    "functionname": "f_rb_newtrip",
    "is_dynamic": true,
    "type": "roslyn_jit"
  }
]

Appendix J - Metadata Governance & Versioning

Because metadata is executable code, all changes are versioned, audited, and strictly reversible:

{
  "entity": "rb_booking",
  "version": 12,
  "changes": [
    {
      "type": "attribute",
      "target": "driver_",
      "old": { "xfctrltype": 1100 },
      "new": { "xfctrltype": 1303, "valuetype": 7, "my_fkentityid": 1002 },
      "timestamp": "2026-10-01T14:21:00",
      "user": "admin"
    }
  ]
}

Appendix K - State Log Specification

{
  "state_log_id": 9981,
  "xf_entity": "rb_booking",
  "xf_id": 5,
  "xf_guid": "d6d366ea-f83c-49cd-932d-e768d66c0006",
  "xf_version": "2026-10-01T14:23:16.087",
  "xf_f": "save",
  "z_segment": {
    "bookingno": 1004,
    "amount": 45,
    "pickuptime_return": 1540
  },
  "timestamp": "2026-10-01T14:23:16",
  "user": "pp3"
}

Appendix L - Multi‑Tenancy Specification

Multi-tenancy emerges directly at the metadata graph layer. Tenants have independent metadata graphs, rights registries, and router entries while running on shared runtime container clusters.

{
  "tenant": "Robsons",
  "app_id": 2,
  "prefix": "rb",
  "metadata": {
    "entities": "zxf_entity",
    "attributes": "zxf_attribute",
    "router": "zxf_router"
  },
  "schema": "shared",
  "custom_pages": {
    "rb_newtrip": "rb_newtrip.html"
  }
}

Appendix M - Error Handling Specification

Errors in xF are deterministic mutations written directly into the z‑segment, ensuring that workflows do not crash web sessions or drop user state:

{
  "xf_entity": "rb_booking",
  "xf_id": 5,
  "xf_e": -1,
  "xf_ex": "Validation failed: driver_ is mandatory before allocation.",
  "xf_version": "2026-10-01T14:23:16.087"
}

Appendix N - Performance & Scaling Specification

{
  "runtime": {
    "stateless": true,
    "horizontal_scaling": true,
    "metadata_cache": "in_memory",
    "execution_protocol": "O(1)",
    "logic_gateway": {
      "jit": "cached_delegate",
      "rest": "async_safe"
    }
  },
  "frontend": {
    "build": "none",
    "templates": "cached",
    "vendor_loading": "lazy"
  },
  "database": {
    "auto_ddl": true,
    "schema_drift": "none",
    "primary_key": "xf_id identity",
    "indexes": "auto"
  }
}