Palantir: Zero to Monopoly

Action Definition and Execution

Actions are governed operations — every execution is typed, validated, audited, and reversible. Unlike direct database writes, an Action cannot be invoked without passing permission checks, business rule validation, and audit logging.

Action structure:

interface ActionDefinition {
  name: string                      // e.g., "HoldVehicle"
  parameters: ParameterSchema[]     // Typed inputs
  validation: ValidationRule[]      // Pre-execution checks
  sideEffects: SideEffect[]         // State changes and integrations
  permissions: Permission[]         // RBAC/ABAC rules
  auditConfig: AuditConfiguration   // Logging requirements
  reversibility: ReversalConfig     // Undo capability
}

HoldVehicle Action Implementation

Action: HoldVehicle
Parameters:
  - vehicleId: ObjectId<Vehicle> (required)
  - riskScore: Float (0–100, required)
  - reasonCode: Enum<QualityRiskReason> (required)
  - approverId: ObjectId<User> (optional, required for manual triggers)

Validation Rules:
  1. Vehicle.ProductionStatus must be in ["IN_PRODUCTION", "QUALITY_REVIEW"]
     - Reject if status = "SHIPPED" or "DELIVERED"
  2. User must have permission: "quality.hold.execute" OR automation service account
  3. Risk score must be >= 70 (configurable threshold)
  4. If manual trigger: approverId must have role "QualityManager" or higher

Side Effects (executed transactionally):
  1. Update Vehicle.ProductionStatus = "HOLD"
  2. Create HoldTicket linking Vehicle, Batch, Supplier with risk score,
     reason, timestamp, triggering user/automation
  3. POST to MES API (/api/v2/production/holds) — 3-attempt exponential backoff
  4. Notify production floor dashboard (WebSocket)
  5. Write complete audit log entry (see Security section)

Reversibility:
  - ReleaseVehicle action can undo hold
  - Restores previous ProductionStatus
  - Maintains complete history of hold/release cycles
  - Requires justification and approval for reversal

Action Execution Flow

Parameter Validation: Type checking, required field validation, range checks
Permission Check: RBAC evaluation against user/service account
Business Rule Validation: Custom validation logic (e.g., vehicle status check)
Transaction Begin: Start distributed transaction across Foundry and external systems
Side Effect Execution: Update ontology objects, trigger external APIs
Audit Logging: Record complete action context and lineage
Transaction Commit: Atomic commit or rollback on failure
Notification: Trigger downstream automations and user notifications

Automation Engine Architecture

Automations are event-driven workflows defined declaratively. They run continuously, react to ontology changes, and invoke Actions with optional human approval gates.

interface AutomationDefinition {
  name: string
  trigger: TriggerConfig        // What starts the automation
  conditions: Condition[]        // When to execute
  actions: ActionInvocation[]    // What to do
  approvalFlow?: ApprovalConfig  // Human-in-the-loop
  schedule?: ScheduleConfig      // Time-based execution
}

SupplierProcessMonitor Automation

Automation: SupplierProcessMonitor
Trigger:
  - Type: ObjectPropertyChange
  - Object: Batch
  - Property: ProcessParameters.Temperature
  - Frequency: Real-time (event-driven)
  - Batch window: 5 minutes (debounce rapid changes)

Conditions (evaluated in order):
  1. Temperature deviation check:
     - Calculate: |actual - spec| / spec
     - Threshold: > 3% deviation
  2. Batch status: must be "IN_PRODUCTION" or "PENDING_APPROVAL"
  3. Supplier tier:
     - Tier 1: Require approval
     - Tier 2/3: Auto-execute

Action Invocations:
  If deviation > 3% AND < 5%:
    1. NotifySupplier(severity: "MEDIUM")
    2. FlagBatch(flagType: "QUALITY_WATCH")

  If deviation >= 5%:
    1. NotifySupplier(severity: "HIGH")
    2. HoldVehicle(ALL vehicles using this batch, riskScore: 94)
    3. EscalateToQualityManager(urgency: "HIGH")

Approval Flow (Tier 1 suppliers only):
  - Approver: Quality Manager assigned to supplier
  - Timeout: 30 minutes
  - On timeout: Auto-escalate to Director of Quality

Automation Engine Performance

Trigger latency: <100ms from ontology change to trigger evaluation
Condition evaluation: <50ms for typical business rules
Action execution: 200ms – 2s depending on external integrations
Throughput: 10,000+ automation executions per second per cluster
Reliability: 99.95% success rate with automatic retry logic

The August 15 event: furnace sensor reads 1,847°F at 14:23. By 15:02 — 39 minutes later — 127 vehicles are on hold, the supplier has been notified, and the quality manager has been alerted. No human had to notice the anomaly. No one had to decide what to do. The system did all of it, with complete audit trail.

Model Binding and Inference

ML models are registered in the model registry and bound directly to ontology properties. Predictions become live properties of ontology objects — automatically updated, automatically triggering downstream automations.

Model: QualityRiskScoringModel
Version: v3.2
Type: RandomForestClassifier
Accuracy: 89% (validation set)

Input Features (auto-extracted from ontology):
  - Batch.ProcessParameters.Temperature: Float
  - Batch.ProcessParameters.Pressure: Float
  - Supplier.HistoricalDefectRate: Float (rolling 6-month average)
  - Supplier.ProcessStability: Float (coefficient of variation)
  - Part.ComplexityScore: Integer (1–10)

Output Binding:
  - Target Property: Batch.QualityRiskScore
  - Type: Float (0–100)
  - Confidence: Batch.QualityRiskConfidence (0–1)
  - Explanation: Batch.RiskFactors (JSON — contributing features)

Inference Configuration:
  - Trigger: On Batch creation or ProcessParameters update
  - Latency SLA: < 500ms
  - Fallback: If model unavailable, use rule-based scoring (conservative)

Model Feedback Loop

1. Model generates prediction → Batch.QualityRiskScore = 94
2. Automation triggers HoldVehicle based on score
3. Quality team investigates → actual defect confirmed or rejected
4. Outcome recorded → Batch.ActualQualityOutcome = "DEFECT_CONFIRMED"
5. Training data updated → (features, prediction, actual outcome)
6. Monthly retraining → Model v3.3 with improved accuracy
7. Canary rollout → monitor accuracy improvement
8. Full promotion if accuracy improves

Security, Permissions, and Audit Trail

Role-Based Access Control (RBAC)

QualityEngineer:
  - Read: All quality objects (Vehicle, Part, Batch, Supplier)
  - Execute: InvestigateDefect, FlagBatch
  - Forbidden: HoldVehicle, NotifySupplier

QualityManager:
  - Inherits: QualityEngineer permissions
  - Execute: HoldVehicle, NotifySupplier, ReleaseVehicle
  - Approve: Automation actions for Tier 1 suppliers

ProductionManager:
  - Read: Vehicle.ProductionStatus, HoldTicket (view only)
  - Execute: RequestHoldOverride (requires justification)
  - Forbidden: Direct quality actions

Supplier:
  - Read: Own supplier data only (row-level security)
  - Forbidden: Other suppliers' data, MidWest internal data

Attribute-Based Access Control (ABAC)

Fine-grained permissions based on context:

Policy: Supplier Data Access
Rule: User can read Supplier object IF:
  - User.role = "QualityEngineer" AND Supplier.AssignedEngineer = User.id
  OR
  - User.role = "QualityManager"
  OR
  - User.organization = Supplier.organization (for supplier portal users)

Policy: Field-Level Masking
Rule: Mask Supplier.CostData IF:
  - User.role NOT IN ["Finance", "Executive"]
  - Show as "REDACTED" in query results

Complete Audit Trail: HoldVehicle Entry

{
  actionId: "act_20240815_150234_hv_127",
  actionName: "HoldVehicle",
  timestamp: "2024-08-15T15:02:34.123Z",

  trigger: {
    type: "AUTOMATION",
    automationName: "SupplierProcessMonitor",
    triggeringEvent: {
      objectType: "Batch",
      objectId: "batch_LOT-2024-0847",
      propertyChanged: "ProcessParameters.Temperature",
      oldValue: 1800,
      newValue: 1847
    }
  },

  dataLineage: [
    {
      source: "SupplierPortal_IoT_Sensor_847",
      timestamp: "2024-08-15T14:23:15.000Z",
      value: 1847,
      unit: "Fahrenheit"
    },
    {
      transformation: "SDDI_Ingestion",
      targetProperty: "Batch.ProcessParameters.Temperature"
    },
    {
      model: "QualityRiskScoringModel_v3.2",
      prediction: 94,
      confidence: 0.91,
      topFeatures: [
        { feature: "Temperature", contribution: 0.45 },
        { feature: "SupplierDefectRate", contribution: 0.32 }
      ]
    }
  ],

  decision: {
    condition: "RiskScore >= 90",
    conditionMet: true,
    riskScore: 94,
    threshold: 90
  },

  execution: {
    vehiclesAffected: 127,
    vinList: ["1HGBH41JXMN109186", ...],
    mesIntegration: {
      endpoint: "https://mes.midwest.com/api/v2/production/holds",
      requestId: "req_847_hold",
      responseCode: 200,
      responseTime: "342ms"
    }
  },

  approval: {
    required: false,
    reason: "Tier 2 supplier, auto-execute policy"
  },

  reversibility: {
    canReverse: true,
    reverseAction: "ReleaseVehicle",
    requiresApproval: true,
    approver: "QualityManager"
  }
}

Every link in the chain is captured: from the raw IoT sensor reading, through SDDI ingestion, through the model prediction, through the automation trigger, to the Action execution and MES API call. Any user can query why any vehicle was held, trace back to the sensor data that triggered it, and see exactly which model features drove the risk score.

Lineage Query Capabilities

Users can query audit logs to answer:

"Why was this vehicle held?" — Trace from action → automation → model → sensor reading
"What data influenced this prediction?" — Feature importance and input values
"Who approved this action?" — User, role, timestamp
"Can this be reversed?" — Reversibility config and current state
"What was the business impact?" — Affected objects, downstream effects

This is what makes the 95% automation rate possible: not just the technical capability to automate, but the governance infrastructure that makes teams willing to trust it.

Actions, Automations & Models Architecture