⚖️ SLANG-Claims

🧾 What If an Insurance Claim Could Be Determined from Declared Evidence — Not Just Workflow History?

A bounded way to determine PAYABLE, NOT_PAYABLE, or an explicit non-result from declared insurance-claim structure — while keeping payment authority completely outside the resolver.

⚖️ SLANG-Claims

Claims systems usually contain many moving parts.

A claim may pass through:

  • intake
  • assessment
  • coverage review
  • loss evaluation
  • exclusions
  • controls
  • approvals
  • fraud checks
  • legal review
  • settlement
  • payment

Those processes can be essential.

But they also raise an interesting structural question:

Does the historical workflow itself have to be the thing that determines the bounded claim result?

SLANG-Claims explores a narrower alternative.

Instead of asking:

“Which workflow step happened last?”

it asks:

“Given the declared claim context, bound claim-authority evidence, and identified versioned rules, what bounded structural result follows?”

The central relation is:

declared claim context + bound claim-authority evidence + versioned rules -> bounded claim-payability state

And for admitted canonical structure:

same admitted canonical structure + same versioned contract -> same bounded result

That is the core idea.

But there is an equally important boundary:

PAYABLE != PAYMENT_AUTHORIZED

SLANG-Claims does not authenticate claimants or evidence sources, interpret policy or law, determine fraud, settle claims, authorize payment, or move money. It resolves only the bounded structural state defined by its identified contract.

🌐 Explore SLANG-Claims on GitHub

🧩 How SLANG-Claims Turns Declared Evidence into a Bounded Claim Result

Figure: SLANG-Claims takes declared claim context and bound claim-authority evidence through deterministic structural admission and bounded claim arithmetic, producing PAYABLE, NOT_PAYABLE, or an explicit non-result while keeping settlement, payment authorization, and money movement outside the resolver.

🧠 So What Does SLANG-Claims Actually Do?

Think of SLANG-Claims as a deterministic structural admission layer.

An existing claims environment may already have produced declared evidence such as:

coverage_result = COVERED

occurrence_result = ESTABLISHED

exclusion_result = CLEAR

control_result = CLEAR

SLANG-Claims does not independently discover whether those declarations are true.

Instead, it checks whether the supplied structure is:

  • supported
  • complete
  • internally consistent
  • correctly bound
  • admitted under the declared evidence mode
  • compatible with the identified profile and ruleset
  • sufficient to produce a bounded result

The question is deliberately smaller:

Given the declared and bound claim evidence, does this exact structural contract admit PAYABLE or NOT_PAYABLE?

If the required structure is not sufficient:

insufficient admissible structure -> no forced PAYABLE outcome

That refusal behavior is just as important as a successful resolution.

💰 The Claim Arithmetic Is Explicit

For the current reference profile, let:

C = claim_amount_minor

A = assessed_loss_minor

D = deductible_minor

L = remaining_limit_minor

Then:

admitted_loss_minor = min(C, A)

post_deductible_minor = max(admitted_loss_minor - D, 0)

payable_amount_minor = min(post_deductible_minor, L)

Or in one expression:

payable_amount_minor = min(max(min(C, A) - D, 0), L)

For example:

claim_amount_minor = 500000

assessed_loss_minor = 450000

deductible_minor = 100000

remaining_limit_minor = 1000000

So:

admitted_loss_minor = 450000

post_deductible_minor = 350000

payable_amount_minor = 350000

The bounded outcome can therefore be PAYABLE.

But again:

PAYABLE is a structural result inside this reference contract.

It is not a bank instruction.

It is not settlement.

It is not legal entitlement.

It is not authorization to transfer money.

PAYABLE != PAYMENT_AUTHORIZED

The arithmetic and its bounded status are explicitly defined by the current reference profile.

🚦 A Result Is Never Forced

SLANG-Claims currently recognizes explicit resolution states including:

RESOLVED

INCOMPLETE

CONFLICT

FORBIDDEN

UNSUPPORTED

ABSTAIN

These states have different meanings.

If required evidence is missing:

missing required structure -> INCOMPLETE

If supported declarations cannot coexist:

incompatible declarations -> CONFLICT

If prohibited material or caller-supplied derived authority fields are present:

prohibited structure -> FORBIDDEN

If the input lies outside the exact supported profile:

unsupported structure -> UNSUPPORTED

If evaluation itself is not authorized:

evaluation_authorized = false -> ABSTAIN

And a very important distinction is preserved:

CONFLICT != ABSTAIN

SLANG-Claims does not silently turn every problem into one generic failure state.

It preserves why the resolver refused to force an outcome. The current state meanings and precedence are explicitly frozen by the reference contract.

👥 What If More Than One Authority Provides Evidence?

SLANG-Claims supports two evidence modes.

SINGLE_AUTHORITY

Exactly one expected authority is declared.

Exactly one matching evidence record must be present.

Simple.

MULTI_AUTHORITY_EXACT_AGREEMENT

Two or more expected authorities may be declared.

Every expected authority must be represented exactly once.

And the admitted evidence must agree exactly on the bounded result fields.

The principle is:

exact agreement -> continue

material disagreement -> ABSTAIN

There is no:

  • majority voting
  • weighting
  • ranking
  • averaging
  • first-arrival winner

The resolver does not decide that two authorities can simply outvote a third.

Agreement is structural, not political.

🧩 Why This Is Interesting

Traditional systems often blend many separate questions:

Is the data structurally valid?

Does it correspond to the right claim?

Does the evidence agree?

What result follows?

Should that result be shown?

Was the artifact authenticated?

Is the signer trusted?

Is anyone authorized to act?

SLANG-Claims deliberately separates those questions.

For example:

structural integrity != correspondence

correspondence != authenticity

authenticity != real-world truth

real-world truth != authorization to act

And at the claims boundary:

PAYABLE != PAYMENT_AUTHORIZED

This is one of the most important ideas in the project.

A system becomes easier to reason about when one successful check does not silently acquire the meaning of five stronger checks.

🧾 Receipts Answer Two Different Questions

SLANG-Claims can produce a compact receipt.

But even the word verify is carefully bounded.

A receipt integrity check asks:

“Is this receipt internally valid under its declared contract?”

That gives:

RECEIPT_INTEGRITY: PASS

But it deliberately reports:

BUNDLE_CORRESPONDENCE: NOT_CHECKED

That is because self-consistency and exact correspondence are different questions.

To ask whether the receipt actually corresponds to a specific reconstruction bundle, a stronger verification path is used.

Then:

RECEIPT_INTEGRITY: PASS

BUNDLE_CORRESPONDENCE: PASS

This gives a very useful distinction:

receipt integrity != bundle correspondence

and still:

bundle correspondence != source authenticity

and still:

source authenticity != payment authority

Verification becomes a ladder rather than one giant green checkmark.

🛑 Non-Results Can Also Be Preserved as Evidence

A system does not become more trustworthy by storing evidence only when everything succeeds.

SLANG-Claims v0.2.1 also introduces portable non-result attestations.

For example, an ABSTAIN result can be represented as a deterministic artifact containing:

  • the bounded state
  • reason codes
  • diagnostics
  • contract identities
  • submission bindings
  • result bindings
  • fixed authority exclusions

This allows the system to preserve:

“Why did we not produce PAYABLE or NOT_PAYABLE?”

without pretending that a payout decision existed.

The principle is:

non-result state -> portable evidence

And verification again has separate levels:

attestation integrity != input correspondence

That matters because refusing to decide can itself be something worth reconstructing and auditing.

👁️ Resolution and Visibility Are Not the Same Thing

SLANG-Claims also separates the private resolved result from its presentation.

A resolved result may be:

visibility_state = VISIBLE

or:

visibility_state = WITHHELD

When an outcome is withheld, the public summary neutralizes outcome-sensitive fields.

For example:

admission_state = WITHHOLD

claim_outcome = NONE

payable_amount_minor = 0

outcome_id = NONE

result_id = NONE

The reference then tests a stronger property:

withheld PAYABLE summary == withheld NOT_PAYABLE summary

for otherwise presentation-equivalent cases.

In simple language:

If the result is supposed to be hidden, the public summary should not quietly leak whether the private result was positive or negative.

This is called withheld-outcome noninterference.

But it is still only a presentation property.

presentation noninterference != encryption

🔒 Sensitive Material Does Not Belong Inside the Claim Resolver

SLANG-Claims uses a strict supported-field boundary.

It also recognizes representative forbidden field-name families involving things such as:

  • bank-account data
  • card data
  • government identifiers
  • secrets
  • keys
  • tokens
  • caller-supplied derived authority fields

The basic design is:

strict allowlist = primary gate

forbidden-name recognition = defense-in-depth classification

But there is an important warning:

field-name recognition != secret-content detection

The resolver is not a magical secret scanner.

Callers still have the responsibility to keep passwords, tokens, private keys, personal data, and other sensitive information out of unsupported places.

📜 The Contract Is Machine-Readable

SLANG-Claims does not rely only on explanatory prose.

The current package includes a machine-readable contract that freezes things such as:

  • profile and ruleset identifiers
  • canonicalization identity
  • evidence modes
  • resolution-state precedence
  • supported symbols
  • reason-code registry
  • resource limits
  • authority exclusions
  • receipt verification scopes
  • attestation verification scopes
  • forbidden-field behavior
  • the payable formula
  • runtime compatibility

The contract itself also has a deterministic identity.

And there is a subtle but useful distinction:

contract_id != file_sha256

The contract identity is derived from the declared canonical contract material rather than simply hashing the saved file bytes.

That allows contract meaning and file serialization to remain conceptually separate.

🔐 Optional Authenticity Can Wrap the Evidence

The deterministic core does not require signatures.

But SLANG-Claims v0.2.1 also provides an optional authenticity layer:

artifact -> outer signed envelope

The important architectural rule is:

Authenticity wraps the deterministic artifact instead of changing it.

The bundle, receipt, or attestation keeps its original deterministic identity.

The outer envelope can then bind:

  • contract identity
  • artifact kind
  • artifact schema
  • artifact identity
  • canonical payload hash
  • signer identity
  • key identity
  • signing purpose
  • optional timestamp

The reference supports:

HMAC-SHA256

and optionally:

Ed25519

through the cryptography package.

But even a valid signature has a strict boundary:

signature valid != trust root established

trusted signing key != real-world claim truth

real-world claim truth != payment authority

This is another important design choice.

Cryptography answers a cryptographic question.

It does not automatically answer a legal, institutional, factual, or payment question.

⏳ What About Replay, Expiry, and Revocation?

The authenticity envelope can include a timestamp.

But SLANG-Claims v0.2.1 deliberately does not pretend that this solves the entire lifecycle problem.

The current reference does not itself impose:

  • a freshness window
  • nonce tracking
  • replay prevention
  • key expiry
  • key rotation
  • revocation
  • certificate chains
  • institutional trust roots

Instead, the verifier can explicitly report:

FRESHNESS: NOT_EVALUATED

REPLAY_PROTECTION: EXTERNAL

That is much safer than silently implying that a valid signature means:

“This artifact is fresh, trusted, authorized, and safe to act on.”

It doesn’t.

🏦 What Does SLANG-Claims Absolutely Not Do?

This boundary matters enough to repeat.

Every resolved result preserves:

payment_authority = NONE

settlement_authority = NONE

legal_authority = NONE

policy_interpretation_authority = NONE

fraud_determination_authority = NONE

money_movement = NONE

An authenticity envelope does not change those constants.

So a possible larger operational system might conceptually look like:

claim evidence + domain controls + structural resolution + operational authorization + settlement controls -> possible payment execution

SLANG-Claims occupies only the bounded structural-resolution part of that larger relationship.

🧪 Current Reference Status

The current reference is SLANG-Claims v0.2.1.

The supplied package reports:

  • core self-test: 101/101 PASS
  • frozen conformance corpus: 154/154 PASS
  • reconstruction bundle verification: PASS
  • receipt structural integrity: PASS
  • receipt-to-bundle correspondence: PASS
  • non-result attestation integrity: PASS
  • attestation-to-input correspondence: PASS
  • authenticity-envelope audit with Ed25519 available: 46/46 PASS
  • HMAC-only authenticity path when Ed25519 is unavailable: 35/35 PASS
  • Draft 2020–12 schema validation across the supplied artifact classes: PASS
  • Python 3.9 grammar compatibility: PASS

These are reference-package verification results.

They are not a production certification, insurance-law validation, independent security audit, or authorization for operational claims handling.

⚠️ What SLANG-Claims Claims — and Does Not Claim

SLANG-Claims demonstrates:

  • deterministic claim-payability admission from declared structure
  • strict bounded input handling
  • explicit versioned rules
  • exact evidence binding
  • exact multi-authority agreement
  • explicit non-result states
  • bounded claim arithmetic
  • deterministic identities
  • reconstruction bundles
  • compact receipts
  • portable non-result attestations
  • visibility-safe summaries
  • withheld-outcome noninterference
  • machine-readable contracts
  • machine-readable schemas
  • separate integrity and correspondence verification
  • optional authenticity envelopes
  • explicit authority boundaries

It does not provide:

  • claimant authentication
  • evidence-source authentication by itself
  • policy interpretation
  • legal adjudication
  • fraud determination
  • insurance underwriting
  • settlement
  • payment authorization
  • banking
  • accounting
  • money movement
  • regulatory certification
  • production claims administration

Its strongest supported claim is intentionally bounded:

same admitted canonical claim structure + same versioned contract -> same bounded claim result

And when the structure is insufficient:

non-result state -> no forced PAYABLE outcome

🌐 Explore SLANG-Claims

The GitHub demo folder contains the current reference implementation, profile, frozen vectors, canonical example input, reconstruction bundle, compact receipt, non-result attestation, machine-readable contracts, JSON Schemas, authenticity layer, verification commands, and reference diagram.

🔗 SLANG-Claims on GitHub

For technical details, verification commands, exact contract identities, schemas, artifact formats, and authenticity behavior, the GitHub README is the best reference.

🌌 The Larger Question

Real-world claims processing may involve people, systems, workflows, authentication, policy engines, legal controls, fraud controls, financial controls, settlement infrastructure, and payment systems.

SLANG-Claims does not try to erase any of that.

It asks something more specific:

Once the required declared claim context and bound evidence exist, can the bounded claim-payability state be resolved deterministically from that structure instead of depending on workflow history as the sole source of the result?

And if the structure is incomplete, contradictory, forbidden, unsupported, or evaluation is not authorized:

Can the system refuse cleanly instead of inventing an answer?

And if an artifact is later checked:

Can integrity, correspondence, authenticity, trust, and operational authority remain separate questions instead of collapsing into one vague “verified” label?

That leads to a simple structural principle:

Declare the context. Bind the evidence. Apply the identified rules. Resolve only what the contract justifies. Preserve non-results. Make evidence reconstructable. Add authenticity without changing deterministic reconstruction. Keep payment authority outside the resolver.

Or, in compact form:

evidence -> structural admission -> bounded resolution -> presentation -> verification -> optional authenticity

kept separate from:

settlement -> payment authorization -> money movement

That separation is the heart of SLANG-Claims.

✍️ Authorship and Disclaimer

Created by the authors of the Shunyaya Framework.

SLANG-Claims is a bounded deterministic structural-resolution reference for declared claim context and bound claim-authority evidence.

It is not an insurer, claims-administration platform, policy interpretation system, fraud-detection system, legal decision engine, settlement system, payment authority, banking system, accounting system, or regulatory certification.

Any operational, financial, insurance, legal, or safety-sensitive use requires independent implementation review, domain validation, security assessment, privacy analysis, appropriate organizational controls, suitable authorization, and applicable legal and regulatory review.

OMP