Circuit follows a schema-driven architecture to enforce structured validation and data protection at every stage of execution.

Using JSON Schema, Circuit defines:

• Expected fields and data types

• Validation rules and constraints

• Input and output structure

• Field-level data protection policies

This ensures consistent, secure, and compliant workflow processing.

Schema Validation Levels 

Schemas can be configured at two levels.

• Circuit Input Schema  : Validates incoming JSON before execution starts. If validation fails, the circuit does not start.

Each state supports:

• State Input Schema  : Validates states input JSON before state execution

• State Result Schema  : Validates state output before passing it to the next state

If validation fails, the state execution fails and the error is recorded in execution logs.

Data Protection Keywords (Core Security Feature)

These controls operate at the field level and are enforced automatically during execution.

Available Data Protection Methods

hide: true  

• Completely removes the field from the API response

• Highest protection priority

• Suitable for internal system fields or identifiers

encrypt: true  

• Encrypts the value before database persistence

• Decryption occurs only during Retry or Rerun

• Protects sensitive identifiers, tokens, and regulated data

redact: true  

• Replaces the value with a fixed placeholder (e.g., [REDACTED])

• The original value is securely retained

• The audit log records the user who performed the unredaction

• Suitable for strict PII and confidential data 

mask: true  

• Partially hides the value (e.g., ****)

• Allows controlled visibility while protecting sensitive data

If multiple protection rules are applied to the same field, they are enforced in the following order:

Hide → Encrypt → Redact → Mask

This ensures predictable and secure behaviour when multiple rules are configured.

Protection Priority Order 

Encryption At Rest (EAR)   

All execution context data is protected using Encryption At Rest.

• Fields marked with "encrypt": true are encrypted before storage.

• Decryption occurs only during Retry or Rerun.

• Data remains protected during idle and normal execution states.

• Execution context is isolated per workflow instance.

This architecture ensures sensitive data is never exposed unnecessarily.

Configuring Schema Properties in UI   

Step 1: Open Input Schema

Step 2: Add Properties

• Add New Property (manual)

1. Enter the Property Name.
2. Select the Data Type (string, number, integer, boolean, object, array).
3. Mark the property as Required, if applicable. 

• Generate Schema from JSON Data (auto-generate)

1. Paste your JSON payload on the left side of the converter, the equivalent JSON schema appears automatically on the right.
2. If you already have a JSON schema, click Generate Empty Schema and paste it directly on the right side.
3. Click Update Schema to auto-generate properties from schema.
4. Review the auto-generated properties.
5. Click Add Property to include additional fields if needed.

            

Step 3: Configure Validation Settings (Optional)

Click the expand icon next to a property name to configure additional validation settingsTitle and Description

• Minimum / Maximum values

• Format (e.g., email)

• Enum values

• Default value

• Data Protection Method: hide, encrypt, redact, or mask

Default Values  

If a field is not provided in the input and a default value is defined in the schema, the system automatically assigns the default value to that field before execution proceeds.

This ensures that:

• Missing optional fields are populated with predefined values

• Workflows continue without interruption due to missing inputs

Step 4: Add Nested Properties (Optional)

Step 5: Save Your Changes

1. After adding properties, click Save to apply changes at the client level.

2. To modify saved properties, make your edits and click Update.

3. To discard all existing properties and start over, click Reset.

4. Once finalized, click Save in the circuit to persist the schema to the database.

• Clicking Save within the schema properties panel applies changes at the client level only. To permanently save your configuration, you must also click Save in the circuit.
  

• Only properties marked as Required are considered mandatory during validation.

Schema Examples     

This example shows core employee fields with data protection applied at the top level.

Example 1 – Basic properties with data protection  

{
  "type": "object",
  "required": ["employeeId", "fullName", "email", "department"],
  "properties": {
    "employeeId": { "type": "integer", "title": "Employee ID",    "mask": true    },
    "fullName":   { "type": "string",  "title": "Full Name"                       },
    "email":      { "type": "string",  "title": "Work Email",    "encrypt": true  },
    "department": { "type": "string",  "title": "Department",    "redact": true   },
    "salary":     { "type": "number",  "title": "Annual Salary", "redact": true   }
  }
}

{
  "employeeId": “100423”,
  "fullName":   "Sarah Mitchell",
  "email":      "sarah.mitchell@company.com",
  "department": "Engineering",
  "salary":     “95000”
}

{
  "employeeId": "######",
  "fullName":   "Sarah Mitchell",
  "email":      "[ENCRYPTED]",
  "department": "[REDACTED]",
  "salary":     "[REDACTED]"
}

Example 2 – Nested properties   with data protection

This example shows personal details configured as a nested object inside the employee record, with data protection applied at both levels.

{
  "type": "object",
  "properties": {
    "fullName": { "type": "string", "title": "Full Name" },
    "email":    { "type": "string", "title": "Work Email", "encrypt": true },
    "personalDetails": {
      "type": "object",
      "title": "Personal Details",
      "properties": {
        "phone":   { "type": "string", "title": "Phone Number", "hide": true   },
        "address": { "type": "string", "title": "Home Address", "redact": true }
      }
    }
  }
}

{
  "fullName": "Sarah Mitchell",
  "email":    "sarah.mitchell@company.com",
  "personalDetails": {
    "phone":   "+1-555-987-6543",
    "address": "42 Maple Street, Austin, TX 78701"
  }
}

}

{
  "fullName": "Sarah Mitchell",
  "email":    "[ENCRYPTED]",
  "personalDetails": {
      "address": "[REDACTED]"
  }
}

Troubleshooting FAQs – JSON Schema Validation

1. What is schema-driven validation in Circuit?

2. What happens if schema validation fails?

1. Circuit Input Schema failure → Circuit execution does not start
2. State Input Schema failure → State execution fails before processing
   

3. What is the difference between Circuit-level and State-level schemas?

1. Circuit-level schema → Validates the overall workflow input before execution begins
   
2. State-level schema → Validates data at each step, including input and output of individual states
   

4. What are data protection keywords in Circuit?

7. When is encrypted data decrypted?

8. Can data protection be applied to nested fields?

9. What is Encryption At Rest (EAR)?

10. What happens if a field is missing in the input?

11. How do I create a schema in the UI?

• Manual → Add properties individually
• Auto-generate → Paste JSON and generate the schema automatically
  

12. Are all fields mandatory by default?

13. What is the difference between redact and mask?

• Redact → Fully hides the value (for example, [REDACTED])
• Mask → Partially hides the value while retaining readability
  

14. Can multiple data protection rules be applied to the same field?

15. Is the original data preserved when redacted?

16. Where are validation errors logged?