10 Real Business Schemas from Production Deployments

Theory is useful. Examples are better.

These are real schemas from production Business-as-Code deployments: anonymized, but structurally identical to what runs in client environments. Each schema includes the JSON definition, an explanation of what it encodes, and how AI agents use it in practice.

Use these as reference patterns. The field names and values are specific to each deployment, but the structural patterns transfer to any business.

All schemas follow JSON Schema Draft 2020-12 and are published at schemas.nimblebrain.ai as part of our Context Engineering practice, structuring organizational knowledge so any agent can operate on it.

1. Customer Entity

The most common starting point. This schema defines what a customer means across all systems and agents.

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "Customer",
  "description": "Core customer entity with segmentation and lifecycle tracking.",
  "type": "object",
  "properties": {
    "customer_id": {
      "type": "string",
      "pattern": "^CUS-[0-9]{6}$",
      "description": "Unique identifier, format CUS-NNNNNN"
    },
    "legal_name": { "type": "string", "minLength": 1 },
    "segment": {
      "type": "string",
      "enum": ["enterprise", "mid-market", "smb"]
    },
    "annual_contract_value": {
      "type": "number",
      "minimum": 0,
      "description": "Annual contract value in USD"
    },
    "lifecycle_status": {
      "type": "string",
      "enum": ["prospect", "onboarding", "active", "at-risk", "churned"]
    },
    "assigned_csm": {
      "type": "string",
      "description": "Employee ID of assigned customer success manager"
    }
  },
  "required": ["customer_id", "legal_name", "segment", "lifecycle_status"]
}

What it encodes: Customer identity, segmentation tier, contract value, lifecycle position, and account ownership. The segment enum creates a controlled vocabulary that drives downstream routing. Enterprise customers trigger different workflows than SMB.

How agents use it: Lead qualification agents validate incoming records against this schema. Routing agents read segment to assign the correct onboarding workflow. Churn prediction agents monitor lifecycle_status transitions from “active” to “at-risk.”

2. Order

Orders are where entity schemas and process schemas intersect. This schema captures both the content of the order and its operational state.

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "Order",
  "type": "object",
  "properties": {
    "order_id": {
      "type": "string",
      "pattern": "^ORD-[0-9]{8}$"
    },
    "customer_id": {
      "type": "string",
      "pattern": "^CUS-[0-9]{6}$",
      "description": "Reference to Customer entity"
    },
    "line_items": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "sku": { "type": "string" },
          "quantity": { "type": "integer", "minimum": 1 },
          "unit_price": { "type": "number", "minimum": 0 }
        },
        "required": ["sku", "quantity", "unit_price"]
      },
      "minItems": 1
    },
    "total_amount": { "type": "number", "minimum": 0 },
    "status": {
      "type": "string",
      "enum": ["draft", "submitted", "approved", "fulfilled", "cancelled"]
    },
    "requires_approval": { "type": "boolean" },
    "submitted_at": { "type": "string", "format": "date-time" }
  },
  "required": ["order_id", "customer_id", "line_items", "status"]
}

What it encodes: The full order structure: who ordered, what they ordered (as an array of line items with quantity and pricing), the order total, its current status in the fulfillment pipeline, and whether it requires manual approval.

How agents use it: Order processing agents validate incoming orders against this schema, compute totals, and check the requires_approval flag. Fulfillment agents monitor status transitions. Finance agents aggregate total_amount across orders for revenue reporting.

3. Approval Workflow

Process schemas define how work moves through your organization. This one encodes a multi-level approval chain with dollar thresholds.

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "ApprovalWorkflow",
  "description": "Multi-tier approval process with dollar-amount thresholds and escalation rules.",
  "type": "object",
  "properties": {
    "workflow_id": { "type": "string" },
    "entity_type": {
      "type": "string",
      "enum": ["order", "expense", "contract", "discount"],
      "description": "Which entity type this workflow applies to"
    },
    "tiers": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "threshold_min": { "type": "number", "minimum": 0 },
          "threshold_max": { "type": "number" },
          "approver_role": {
            "type": "string",
            "enum": ["manager", "director", "vp", "cfo"]
          },
          "sla_hours": {
            "type": "integer",
            "minimum": 1,
            "description": "Maximum hours before escalation triggers"
          }
        },
        "required": ["threshold_min", "approver_role", "sla_hours"]
      }
    },
    "escalation_action": {
      "type": "string",
      "enum": ["notify_manager", "auto_approve", "block"],
      "description": "What happens when SLA expires without approval"
    }
  },
  "required": ["workflow_id", "entity_type", "tiers", "escalation_action"]
}

What it encodes: A tiered approval structure. Orders under $10K go to a manager. Orders between $10K and $50K go to a director. Orders above $50K require VP approval. Each tier has an SLA, and when the SLA expires, the defined escalation action fires.

How agents use it: When an order or expense hits the requires_approval flag, an agent reads this schema to determine which tier applies based on the dollar amount. It routes to the correct approver role, tracks the SLA countdown, and triggers the escalation action if the SLA expires. The entire approval chain is encoded: no human has to remember the thresholds.

4. Pricing Rule

Pricing logic is the business knowledge most likely to live in one person’s head. This schema makes it explicit.

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "PricingRule",
  "description": "Dynamic pricing rules based on customer segment, volume, and contract terms.",
  "type": "object",
  "properties": {
    "rule_id": { "type": "string" },
    "rule_name": {
      "type": "string",
      "description": "Human-readable rule name for audit logs"
    },
    "applies_to": {
      "type": "object",
      "properties": {
        "segments": {
          "type": "array",
          "items": { "type": "string", "enum": ["enterprise", "mid-market", "smb"] }
        },
        "product_categories": {
          "type": "array",
          "items": { "type": "string" }
        }
      }
    },
    "discount_type": {
      "type": "string",
      "enum": ["percentage", "fixed", "tiered"]
    },
    "discount_value": {
      "type": "number",
      "minimum": 0,
      "description": "Percentage (0-100) or fixed USD amount"
    },
    "volume_tiers": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "min_quantity": { "type": "integer", "minimum": 1 },
          "discount_percentage": { "type": "number", "minimum": 0, "maximum": 100 }
        },
        "required": ["min_quantity", "discount_percentage"]
      }
    },
    "valid_from": { "type": "string", "format": "date" },
    "valid_until": { "type": "string", "format": "date" }
  },
  "required": ["rule_id", "rule_name", "applies_to", "discount_type"]
}

What it encodes: Which customer segments and product categories a pricing rule applies to. Whether the discount is a flat percentage, a fixed dollar amount, or volume-tiered. What the discount value is. When the rule is active.

How agents use it: Proposal generation agents read pricing rules to calculate quotes automatically. When an agent builds a proposal for an enterprise customer ordering 500 units, it finds the applicable pricing rule, looks up the volume tier, applies the discount, and produces an accurate quote, without asking a sales manager for the “special pricing.”

5. Support Ticket

Support operations depend on consistent triage and routing. This schema encodes both.

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "SupportTicket",
  "type": "object",
  "properties": {
    "ticket_id": {
      "type": "string",
      "pattern": "^TKT-[0-9]{7}$"
    },
    "customer_id": { "type": "string" },
    "priority": {
      "type": "string",
      "enum": ["critical", "high", "medium", "low"]
    },
    "category": {
      "type": "string",
      "enum": ["billing", "technical", "onboarding", "feature-request", "outage"]
    },
    "assigned_tier": {
      "type": "string",
      "enum": ["tier-1", "tier-2", "engineering"],
      "description": "Current support tier handling this ticket"
    },
    "sla_deadline": {
      "type": "string",
      "format": "date-time",
      "description": "Response SLA deadline based on priority and customer segment"
    },
    "resolution_status": {
      "type": "string",
      "enum": ["open", "in-progress", "waiting-on-customer", "resolved", "closed"]
    }
  },
  "required": ["ticket_id", "customer_id", "priority", "category", "resolution_status"]
}

What it encodes: Ticket identity, the customer relationship, priority and category for triage, which support tier owns it, the SLA deadline, and the current resolution status.

How agents use it: Triage agents classify incoming tickets by priority and category, assign the initial assigned_tier, and calculate the sla_deadline by cross-referencing the customer’s segment (from the customer schema). Escalation agents monitor tickets approaching their SLA deadline and promote them to the next tier.

6. Employee

Internal operations need schema definitions too. This one powers agent-based task routing and permissions.

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "Employee",
  "type": "object",
  "properties": {
    "employee_id": {
      "type": "string",
      "pattern": "^EMP-[0-9]{6}$"
    },
    "name": { "type": "string" },
    "role": {
      "type": "string",
      "enum": ["ic", "manager", "director", "vp", "c-suite"]
    },
    "department": {
      "type": "string",
      "enum": ["engineering", "sales", "support", "operations", "finance"]
    },
    "reports_to": {
      "type": "string",
      "description": "Employee ID of direct manager"
    },
    "approval_limit": {
      "type": "number",
      "minimum": 0,
      "description": "Maximum dollar amount this employee can approve without escalation"
    }
  },
  "required": ["employee_id", "name", "role", "department"]
}

What it encodes: The employee’s identity, their position in the org hierarchy, their department, reporting chain, and financial approval authority.

How agents use it: When an approval workflow fires, agents look up the approver by role and department using this schema. The approval_limit field determines whether a given employee can approve a specific dollar amount or whether it needs to escalate. The reports_to field lets agents traverse the management chain for escalation.

7. Onboarding Process

This process schema defines the stages and requirements for customer onboarding: turning a signed contract into a fully operational account.

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "OnboardingProcess",
  "description": "Customer onboarding stages with completion criteria and ownership.",
  "type": "object",
  "properties": {
    "customer_id": { "type": "string" },
    "current_stage": {
      "type": "string",
      "enum": ["contract-signed", "kickoff-scheduled", "data-migration", "training", "go-live", "completed"]
    },
    "stages": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "stage_name": { "type": "string" },
          "owner_role": { "type": "string" },
          "completion_criteria": { "type": "string" },
          "completed": { "type": "boolean", "default": false },
          "completed_at": { "type": "string", "format": "date-time" }
        },
        "required": ["stage_name", "owner_role", "completion_criteria"]
      }
    },
    "target_completion_date": { "type": "string", "format": "date" },
    "blockers": {
      "type": "array",
      "items": { "type": "string" },
      "description": "Active blockers preventing progress"
    }
  },
  "required": ["customer_id", "current_stage", "stages"]
}

What it encodes: Where a customer is in the onboarding pipeline, what each stage requires, who owns each stage, whether stages are complete, and what’s currently blocking progress.

How agents use it: Onboarding agents track current_stage and check completion_criteria for each stage before advancing. They surface blockers in daily standups. They calculate whether the target_completion_date is at risk based on remaining stages and historical completion times.

8. Inventory Item

For businesses that manage physical or digital inventory, this schema encodes stock levels, reorder logic, and supplier relationships.

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "InventoryItem",
  "type": "object",
  "properties": {
    "sku": {
      "type": "string",
      "pattern": "^[A-Z]{3}-[0-9]{5}$"
    },
    "product_name": { "type": "string" },
    "quantity_on_hand": { "type": "integer", "minimum": 0 },
    "reorder_threshold": {
      "type": "integer",
      "minimum": 0,
      "description": "Quantity at which automatic reorder triggers"
    },
    "reorder_quantity": {
      "type": "integer",
      "minimum": 1,
      "description": "Standard reorder amount"
    },
    "supplier_id": { "type": "string" },
    "unit_cost": { "type": "number", "minimum": 0 },
    "warehouse_location": { "type": "string" }
  },
  "required": ["sku", "product_name", "quantity_on_hand", "reorder_threshold"]
}

What it encodes: The item’s identity, current stock level, the threshold that triggers a reorder, how much to reorder, and where it’s stored.

How agents use it: Inventory monitoring agents compare quantity_on_hand against reorder_threshold on a continuous basis. When stock drops below the threshold, the agent generates a purchase order for reorder_quantity units from the designated supplier_id. No manual stock checks. No forgotten reorders.

Patterns Across These Schemas

Look at these eight examples together and patterns emerge:

ID fields use pattern constraints. CUS-NNNNNN, ORD-NNNNNNNN, TKT-NNNNNNN, EMP-NNNNNN. Consistent ID formats make cross-entity references unambiguous. An agent reading customer_id: "CUS-004291" in an order schema knows exactly which entity type to look up.

Status fields use enum arrays. Every lifecycle or workflow state is a controlled vocabulary, not a freeform string. This eliminates the “Active” vs. “active” vs. “ACTIVE” problem and gives agents a finite set of valid transitions to reason about.

Descriptions encode operational knowledge. The segment description includes revenue thresholds. The sla_hours description explains escalation behavior. The reorder_threshold description defines the trigger condition. These descriptions carry the tribal knowledge that would otherwise live in someone’s head.

Required fields are minimal. Most schemas require 4-6 fields out of 8-12 total. This keeps data entry friction low while maintaining a useful minimum for agent operations. Optional fields get populated over time as agents and humans interact with the data.

Cross-entity references use typed ID fields. customer_id in an order schema, reports_to in an employee schema, supplier_id in an inventory schema. Agents follow these references to build a connected understanding of the business.

These patterns are consistent across every production deployment we’ve built at NimbleBrain. They work because they balance structure (agents need precision) with flexibility (businesses need to evolve). Start with these patterns. Adapt the specific fields to your domain. Deploy, observe, and iterate.

More schema patterns and templates are available at schemas.nimblebrain.ai.