Signal Types - Parmana Systems

integer

Whole numbers only. Floats and strings are rejected.

"amount": { "type": "integer" }

Value	Valid?	Error
`100`	✅	-
`-50`	✅	-
`0`	✅	-
`1.5`	❌	`VAL-007`
`"100"`	❌	`VAL-007`
`null`	❌	`VAL-007`

boolean

Must be exactly true or false. Truthy values like 1 or "true" are rejected.

"verified": { "type": "boolean" }

Value	Valid?	Error
`true`	✅	-
`false`	✅	-
`1`	❌	`VAL-006`
`"true"`	❌	`VAL-006`
`null`	❌	`VAL-006`

string

Any string value, including empty string.

"user_id": { "type": "string" }

Value	Valid?	Error
`"abc"`	✅	-
`""`	✅	-
`123`	❌	`VAL-008`
`null`	❌	`VAL-008`

enum

String value restricted to a declared set of values. The values array is required.

"status": {
  "type": "enum",
  "values": ["active", "inactive", "pending"]
}

Value	Valid?	Error
`"active"`	✅	-
`"pending"`	✅	-
`"unknown"`	❌	`VAL-011`
`""`	❌	`VAL-011`
`null`	❌	`VAL-009`

VAL-009 is thrown when the value is not a string at all (e.g. null, 1, true). VAL-011 is thrown when the value is a string but is not in the declared values array. Missing values array in the signal definition raises POL-012 at compile time.

Why float is not allowed

Floating-point arithmetic is non-deterministic across platforms — 0.1 + 0.2 can yield different bit representations on different CPUs, runtimes, and JavaScript engines. Since every Parmana execution must be byte-for-byte reproducible, floating-point signals would break the determinism guarantee. Use scaled integers instead: multiply your float value by a power of 10 and work in integer space.

"signalsSchema": {
  "rate_bps": { "type": "integer" }
}

// Signal value: 3.75% → store as 375 basis points
{ "rate_bps": 375 }

// Condition in policy: greater than 5.00% = 500 bps
{ "signal": "rate_bps", "greater_than": 500 }

The scaling factor (100 for percentages, 100 for cents, 1000 for per-mille, etc.) is an application-layer contract that you document alongside your policy.

Common validation errors

Code	Signal type	Cause
`VAL-003`	any	Signal not declared in `signalsSchema`
`VAL-004`	any	Required signal missing from input
`VAL-005`	any	Invalid schema definition: signal definition missing `type` field
`VAL-006`	boolean	Non-boolean value
`VAL-007`	integer	Non-integer (float or string)
`VAL-008`	string	Non-string value
`VAL-009`	enum	Non-string value (e.g. `null`, `1`, `true`)
`VAL-011`	enum	String value not in declared `values` array
`VAL-012`	any	Unsupported signal type — use `integer`, `boolean`, `string`, or `enum`

Scaled integer conversion table

Common financial values that require fractions and their integer equivalents:

Real-world value	Signal name	Integer encoding	Scale factor
3.75% interest rate	`rate_bps`	`375`	× 100 (basis points)
₹82,000.50 income	`monthly_income`	`8200050`	× 100 (paise)
0.97 confidence score	`confidence_pct`	`97`	× 100 (percentage)
1.5x debt-to-income ratio	`dti_ratio_bps`	`15000`	× 10000
87.3% LTV ratio	`ltv_ratio_pct`	`8730`	× 100
₹4,200,000 loan amount	`loan_amount`	`4200000`	× 1 (rupees, integers only)

For rupee amounts that are always whole numbers, no scaling is needed — loan_amount: 4200000 is already a valid integer.

Use Cases

Personal loan signal schema

An NBFC evaluates personal loans using the following signal schema. All fractional values are scaled to integers:

"signalsSchema": {
  "monthly_income":    { "type": "integer" },
  "loan_amount":       { "type": "integer" },
  "credit_score":      { "type": "integer" },
  "emi_obligations":   { "type": "integer" },
  "employed":          { "type": "boolean" },
  "employment_type":   { "type": "enum", "values": ["salaried", "self_employed", "government"] },
  "blacklisted":       { "type": "boolean" }
}

Signal values sent with each request:

{
  "monthly_income":  82000,
  "loan_amount":     500000,
  "credit_score":    720,
  "emi_obligations": 18000,
  "employed":        true,
  "employment_type": "salaried",
  "blacklisted":     false
}

UPI fraud detection with scaled risk score

A payment processor evaluates each UPI transaction with a risk score from a fraud model. The model outputs a float (0.0–1.0); it is scaled to an integer (0–100) before being passed as a signal:

"signalsSchema": {
  "transaction_amount": { "type": "integer" },
  "risk_score":         { "type": "integer" },
  "is_foreign":         { "type": "boolean" }
}

{
  "transaction_amount": 50000,
  "risk_score":         87,
  "is_foreign":         false
}

The policy rule uses "greater_than": 75 to match high-risk transactions. The scaling factor (× 100) is documented in the policy’s README — not embedded in the signal schema, which has no concept of units.

Catching type errors at the validation boundary

A developer accidentally passes credit_score: "750" (a string) instead of credit_score: 750 (an integer). The signal schema declares { "type": "integer" }. Validation throws VAL-007 before evaluation begins — the error is caught at the boundary, not silently coerced. This is the intended behavior: type safety is enforced structurally, not by convention.

​integer

​boolean

​string

​enum

​Why float is not allowed

​Common validation errors

​Scaled integer conversion table

​Use Cases

​Personal loan signal schema

​UPI fraud detection with scaled risk score

​Catching type errors at the validation boundary

​See also