Predictika · Fathom Data tenant provisioning

An AI platform operations agent's tenant provisioning request, checked before it goes out

An AI platform operations agent prepares a request to provision a new tenant on one of Fathom Data's neocloud clusters. Before it goes out, the agent sends it to Predictika, which checks it against a declarative model of the cluster rules, compares the figures the agent states with the ones it computes, and returns a verdict, every reason, and the figures it computed.

Scope: tenant provisioning requests on Fathom Data's two neocloud clusters, Blue Mesa East and Kinetic West. See everything this validator covers

This validator models one process: provisioning a new tenant on Fathom Data's neocloud clusters, Blue Mesa East (Nitro class) and Kinetic West (Prime class). It handles any provisioning request involving these clusters, not just the scenarios shown on this page. It checks:

  • Throughput — the guaranteed read-throughput ceiling each cluster can sell, against what existing tenants already hold plus the new request.
  • Flash capacity — physical flash with best-effort overcommit (best-effort flash is backed at 80 percent), and KV cache, which runs only on Nitro-class clusters and is capped at a share of the cluster's flash.
  • Licenses — the flash and object-storage license limits for each cluster; going past a limit needs a person to approve a license expansion.
  • Tenant configuration — Guaranteed versus BestEffort service class consistency, per-tenant encryption (which needs the cluster's key service), and tenant-name uniqueness within a cluster.
  • The agent's stated figures — the guaranteed throughput and physical flash the agent says the cluster will have after provisioning must match what the validator computes.

It does not cover pricing or billing, changes to or removal of existing tenants, placement across clusters other than these two, or network configuration.

The AI platform operations agentBuilds the tenant provisioning request from the conversation and says it is ready.
Predictika validatorChecks every rule at once and returns the verdict, each finding, and the computed figures.

7 scenarios in 4 groups · each group runs from the agent’s first attempt to the outcome · click one to switch

What the agent proposes

The AI platform operations agent says

Illustrative agent statement. The validator receives the structured request below.

Proposing agent: AI platform operations agent (scripted)

Before provisioning, the agent must call Recorded run

Predictika validator


      

        
        
        
      

      
Waiting for the call.

      
    

  

  
  
  

    
What this validator catches: findings from its test cases
Click to expand
    
Every rule is checked on every call, in any order the choices arrive; one problem never hides another. Blocking findings stop the provisioning request; approval findings need a person to sign off; everything else is computed.

    
1Guaranteed throughput above the cluster ceiling. Blue Mesa East can sell 1,600 GB/s of guaranteed read throughput; tenants already hold 1,100 GB/s, and this request takes it to 1,700 GB/s.
2Stated throughput does not match. The request states 1,500 GB/s guaranteed on Blue Mesa East after provisioning, but the computed figure is 1,700 GB/s.
3KV cache on a cluster that cannot run it. KV-cache memory runs only on Nitro-class clusters; Kinetic West is Prime class.
4More flash than the cluster physically has. Blue Mesa East has 20,000 TB of physical flash. Guaranteed tenants plus best-effort tenants at 80 percent backing would need 21,000 TB.
5Flash license would be exceeded. Flash provisioned on Blue Mesa East would reach 22,000 TB against a 16,000 TB license. Order a license expansion before provisioning.
6Encryption needs a key service the cluster lacks. Per-tenant encryption needs the key service, which Kinetic West does not run.
7Tenant name already in use. A tenant named LabA already exists on Blue Mesa East.
8Service class and throughput guarantee disagree. A Guaranteed tenant needs a throughput guarantee above zero, and a BestEffort tenant cannot carry one. This request has class Guaranteed with 0 GB/s.
9KV cache above its share of flash. KV cache on Blue Mesa East would reach 4,300 TB, above the 20 percent share of flash allowed for it.
10Object storage license would be exceeded. Object storage on Blue Mesa East would reach 105,000 TB against a 100,000 TB license. Order a license expansion before provisioning.
11Stated physical flash does not match. The request states 13,000 TB of physical flash in use on Blue Mesa East, but the computed figure is 14,000 TB.

  

  

    
Scenarios and results
Click to expand
    
The recorded result of the validator for each scenario on this page: the request the AI agent sent, the verdict, and every finding, in the order they appear above.

    
1. Guaranteed throughput: LabH on Blue Mesa East

    
The agent's request. Please provision tenant LabH on Blue Mesa East as a Guaranteed tenant with 1,000 TB of flash and a 600 GB/s read guarantee. This brings guaranteed throughput on the cluster to 1,500 GB/s and physical flash in use to 14,000 TB. It is ready to provision.

    
Verdict: Blocked.

    
    
      
  • Guaranteed throughput above the cluster ceiling. Blue Mesa East can sell 1,600 GB/s of guaranteed read throughput; tenants already hold 1,100 GB/s, and this request takes it to 1,700 GB/s.
    • 
      
  • Stated throughput does not match. The request states 1,500 GB/s guaranteed on Blue Mesa East after provisioning, but the computed figure is 1,700 GB/s.
    • 
    

    
2. Guaranteed throughput: LabH at 400 GB/s

    
The agent's request. Please provision tenant LabH on Blue Mesa East as a Guaranteed tenant with 1,000 TB of flash and a 400 GB/s read guarantee. This brings guaranteed throughput on the cluster to 1,500 GB/s and physical flash in use to 14,000 TB. It is ready to provision.

    
Verdict: Allowed.

    
3. KV cache: LabN on Kinetic West

    
The agent's request. Please provision tenant LabN on Kinetic West as a BestEffort tenant with 300 TB of flash and 200 TB of KV cache for its inference workload. Guaranteed throughput on the cluster stays at 450 GB/s, and physical flash in use comes to 6,940 TB. It is ready to provision.

    
Verdict: Blocked.

    
    
      
  • KV cache on a cluster that cannot run it. KV-cache memory runs only on Nitro-class clusters; Kinetic West is Prime class.
    • 
    

    
4. KV cache: LabN on Blue Mesa East

    
The agent's request. Please provision tenant LabN on Blue Mesa East as a BestEffort tenant with 300 TB of flash and 400 TB of KV cache for its inference workload. Guaranteed throughput on the cluster stays at 1,100 GB/s, and physical flash in use comes to 13,240 TB. It is ready to provision.

    
Verdict: Allowed.

    
5. Flash capacity and license: LabK with 8,000 TB of flash

    
The agent's request. Please provision tenant LabK on Blue Mesa East as a Guaranteed tenant with 8,000 TB of flash and a 300 GB/s read guarantee. This brings guaranteed throughput on the cluster to 1,400 GB/s and physical flash in use to 21,000 TB. It is ready to provision.

    
Verdict: Blocked.

    
    
      
  • More flash than the cluster physically has. Blue Mesa East has 20,000 TB of physical flash. Guaranteed tenants plus best-effort tenants at 80 percent backing would need 21,000 TB.
    • 
      
  • Flash license would be exceeded. Flash provisioned on Blue Mesa East would reach 22,000 TB against a 16,000 TB license. Order a license expansion before provisioning.
    • 
    

    
6. Flash capacity and license: LabK with 5,000 TB of flash

    
The agent's request. Please provision tenant LabK on Blue Mesa East as a Guaranteed tenant with 5,000 TB of flash and a 300 GB/s read guarantee. This brings guaranteed throughput on the cluster to 1,400 GB/s and physical flash in use to 18,000 TB. It is ready to provision.

    
Verdict: Needs approval.

    
    
      
  • Flash license would be exceeded. Flash provisioned on Blue Mesa East would reach 19,000 TB against a 16,000 TB license. Order a license expansion before provisioning.
    • 
    

    
7. Encryption: BankQ on Kinetic West

    
The agent's request. Please provision tenant BankQ on Kinetic West as a BestEffort tenant with 200 TB of flash and per-tenant encryption. Guaranteed throughput on the cluster stays at 450 GB/s, and physical flash in use comes to 6,860 TB. It is ready to provision.

    
Verdict: Blocked.

    
    
      
  • Encryption needs a key service the cluster lacks. Per-tenant encryption needs the key service, which Kinetic West does not run.
    • 
    

  

  

    
Narration transcript
Click to expand
    
The text of the narrated walkthrough, step by step.

    
    
      
  1. Welcome to a demo of Predictika's Validator. An AI platform operations agent prepares a request to provision a new tenant on one of Fathom Data's neocloud clusters. Before it goes out, the agent sends it to Predictika, which checks it against a declarative model of the cluster rules, compares the figures the agent states with the ones it computes, and returns a verdict, every reason, and the figures it computed.
    2. 
      
  2. I will start with the first request by the agent.
    3. 
      
  3. The agent says. Please provision tenant LabH on Blue Mesa East as a Guaranteed tenant with 1,000 TB of flash and a 600 GB/s read guarantee. This brings guaranteed throughput on the cluster to 1,500 GB/s and physical flash in use to 14,000 TB. The rest of the request is on screen.
    4. 
      
  4. Before it goes out, the agent calls the validator.
    5. 
      
  5. Blocked, with two findings, all in one answer. Blue Mesa East can sell 1,600 GB/s of guaranteed read throughput; tenants already hold 1,100 GB/s, and this request takes it to 1,700 GB/s. The request states 1,500 GB/s guaranteed on Blue Mesa East after provisioning, but the computed figure is 1,700 GB/s.
    6. 
      
  6. The validator returned two blocking findings in one answer. A check that reads one field at a time would pass most of this; it shows only when the choices in the provisioning request are checked against each other.
    7. 
      
  7. Now the agent resubmits.
    8. 
      
  8. The corrected request.
    9. 
      
  9. It calls the validator again.
    10. 
      
  10. This time the validator clears it.
    11. 
      
  11. Both earlier findings are cleared, and the validator's figure matches the provisioning request.
    12. 
      
  12. Two problems caught in one call, fixed in one pass, and a clean request. That is the value of Predictika's validator: catching mistakes before the action runs. Now you can try the other scenarios yourself.
    13.