Glossary
Quick reference for all domain terms used across Fascia.
Core Domain Model
Value
Computed or derived data defined using the restricted Value DSL. Values are pure functions with no side effects — they calculate results from existing data without modifying anything.
Examples: total_price, is_overdue, available_stock
Constraints: No arbitrary code. No external calls. Bounded computation.
Entity
A business object abstraction that encapsulates domain concepts. Each Entity includes fields, relationships, a status machine, and invariants. The database storage model (tables, columns, indexes) is automatically derived from the Entity spec.
Examples: Reservation, Payment, Order, Customer
Includes:
- Fields — Typed data attributes (string, number, boolean, date, enum, reference)
- Relationships — Connections to other entities (1:1, 1:N, N:M)
- Status Machine — Allowed states and transitions (e.g.,
pending → confirmed → completed) - Invariants — Business rules that must always be true (e.g., "order total must be positive")
Learn more: Entity concept guide
Composite (Read Model)
A read-only aggregation of multiple entities, optimized for querying and display. Composites are denormalized views — they combine data from several entities into a flat structure for UI or reporting purposes. No direct writes are allowed.
Use cases: Dashboard summaries, report views, list pages with joined data
Actor
A complete definition of a service user — who they are, how they authenticate, what data they can access, and what pages they see in the Portal. Actor replaces role-based access with a richer, spec-driven user model.
Includes:
- entity — Reference to the Entity that holds this actor's profile data
- auth — Registration method (
self,invite_only,setup) and login methods (email,phone,guest) - dataScope — Data access scope:
all(full access) orown(only records with a direct reference) - pages — Portal page presets visible to this actor (
dashboard,table,card,form,catalog)
Examples: Owner, Stylist, Customer, Operator
Tool
An executable server logic unit — the fundamental building block for backend operations. Equivalent to an API endpoint, webhook handler, or cron job. Each Tool is defined by a spec that includes its trigger, flow graph, input/output schemas, and policies.
Includes:
- Trigger (how it's invoked)
- Flow Graph (nodes + edges defining execution logic)
- Input/Output Schema
- Policy Metadata
- Version
Learn more: Tool concept guide
Flow
A directed acyclic graph (DAG) of nodes that defines the execution logic of a Tool. Each node performs a specific operation, and edges define the data flow between nodes. Flows are designed visually in Flow Studio.
Learn more: Flow concept guide
Flow Node Types
| Category | Node | Description |
|---|---|---|
| Data | Read | Fetch from Entity or Composite |
| Data | Write | Create, update, transition, soft-delete Entity |
| Logic | Transform | Data transformation using Value DSL |
| Logic | If/Switch | Conditional branching |
| Logic | Retry | Retry on failure (count/backoff) |
| Logic | Timeout | Execution time limit |
| External | Payment | Payment service call |
| External | Email/SMS | Send email or SMS |
| External | HTTP Request | External HTTP API call |
| Safety | Transaction | Explicit transaction boundary |
| Safety | Policy Check | Policy check (row limit, budget) |
| Safety | Assert | Invariant enforcement |
Trigger Types
| Trigger | Description |
|---|---|
| HTTP Trigger | External clients call the Tool via HTTP |
| Webhook Trigger | Invoked by an external service callback |
| Cron Trigger | Invoked on a schedule (e.g., every hour, daily at midnight) |
| Queue Trigger | (Future) Invoked by a message queue event |
Safety & Governance
Risk Level
A classification assigned to each Tool based on its flow patterns. Risk levels determine whether a Tool can be deployed.
| Level | Criteria | Deploy? |
|---|---|---|
| Green | Entity actions only, transaction exists, idempotent, no raw writes | Allowed |
| Yellow | External call in state transition, missing retry, high row impact | Allowed with acknowledgment |
| Red | Raw write, unbounded update, payment without rollback, missing transaction | Blocked |
Learn more: Risk Rules reference
Policy
A rule enforced at design time (not runtime) to prevent unsafe operations. Policies are checked by the Risk Engine before deployment.
Examples: Row limit policies, budget check policies, required transaction policies
Learn more: Policy concept guide
Invariant
A business rule that must always be true for an Entity. Invariants are enforced at step 6 of the Execution Contract — after the flow executes but before the transaction commits.
Examples: "Order total must be positive", "Reservation end date must be after start date"
Safety Agent
An AI-powered component that operates during the build phase only. It analyzes Tool specs, detects unsafe patterns, suggests fixes, generates test cases, and assigns risk levels. Uses multi-model cross-checking for reliability.
The Safety Agent never executes runtime logic.
Execution
Execution Contract
The immutable 9-step sequence that every Tool execution follows:
- Validate input
- Authorize (JWT + RBAC + row-level policy)
- Policy check
- Start transaction
- Execute flow graph
- Enforce invariants
- Commit / rollback
- Write audit log
- Return normalized output
Learn more: Execution Contract
Spec Registry
The versioned storage system for all Entity, Actor, Tool, Policy, and Invariant specifications. All specs are immutable once versioned — changes create new versions.
Infrastructure
BYOC (Bring Your Own Cloud)
Fascia's deployment model where all runtime infrastructure lives in your own Google Cloud project. Fascia never stores or processes your business data — it only generates and deploys the execution artifacts.
Your GCP resources:
- Cloud Run (Executor)
- Cloud SQL (PostgreSQL) — one instance per workspace
- Cloud Scheduler
- Secret Manager
Learn more: BYOC architecture
Control Plane vs Data Plane
| Component | Location | Description |
|---|---|---|
| Control Plane | Fascia-hosted | Chat Studio, Flow Studio, Spec Registry, Safety Agent, Risk Engine. Where design happens. |
| Data Plane | Your GCP | Executor, Database, Scheduler, Secrets. Where execution happens. |
Auth System
Built-in Auth
Fascia's integrated authentication and authorization system provided as first-class Entities and auto-generated Tools.
Supports:
- Self-login — Email/password registration and login
- Social login — OAuth 2.0 providers (Google, GitHub)
- Passkey — WebAuthn/FIDO2 passwordless authentication
Components:
- Actor spec (defines auth, data scope, and portal pages per user type)
- User Entity (system entity, extensible)
- Actor-based access control (dataScope:
allorown, replaces legacy RBAC + row-level access) - JWT lifecycle (access token + refresh token)