ValidJSON for Business Workflows

Move at agent speed.
Keep the account intact.

Agents propose and revise records. ValidJSON evaluates each representation and returns evidence of what happened and what remains unresolved.

Start here

Bring the agent. Keep your model.

Follow a documented integration path. ValidJSON receives the record, not your model credentials; connecting a client grants no operational authority.

Two operations, one clear boundary

Proposal and validation never collapse.

A Default

Record validation

Validate a record you already have.

Check caller-supplied JSON against your schema or an exact published business pack. The record is never repaired or re-authored.

Caller-supplied schema or published pack
Accepted or refused
Evaluation receipt v2

B Candidate only

Structured extraction

Produce a candidate from bounded text.

Map labelled text into JSON under a supplied schema. The output remains a candidate until you explicitly transfer it into Mode A.

Bounded labelled text only
No automatic validation
Fresh admission required

The useful answer first

What happened? What governed it? What remains unresolved?

Accepted

Record validation · purchase_order_v1 · version 1

No downstream authority

Why these guides

Evidence infrastructure for agent-run business operations.

Agents can create and revise business records at machine speed. These guides show how ValidJSON keeps proposals and proposed corrections distinct from validation, evidence, and authority.

Guide 01 · Silent introduction

Why valid JSON can still be wrong.

A short illustrated explanation of silent LLM repair, ambiguous business meaning, and the operational boundary ValidJSON preserves.

Audio + subtitles 1 min 37 sec Narrated

Illustrated introduction

The hidden decision inside clean JSON

1 / 9

The hidden risk

0:00 / 1:36

Read the full transcript

A business record can be valid JSON and still be wrong. The danger begins when an LLM makes an unresolved business decision look settled.

The source says two event tickets at fifty dollars each, with a total charge of one hundred fifty dollars. Those three facts cannot all be true.

A model under pressure to return one clean record may silently change the total to one hundred. The arithmetic now works, but the source has been rewritten.

ValidJSON's role is different. Under an applicable schema or published business pack, it can preserve the supplied facts, expose the conflict, and refuse to choose which value should control.

Ambiguity can be just as dangerous. A ten percent discount may apply to every item, one line item, the subtotal, or the final total.

Each interpretation can produce valid JSON and correct arithmetic. If the source never names the scope, selecting one is a business decision, not extraction.

At batch scale, a single silent choice does not stay small. It can alter totals, reconciliation, accounting, and every downstream system that trusts the clean-looking record.

ValidJSON preserves the operational boundary: what was proposed, what governed the evaluation, what was refused or accepted, and what remains unresolved.

The model may propose. ValidJSON validates the representation. Neither result authorizes payment, export, approval, or any other downstream consequence.

Learning path

One concept at a time.

Connection guide

Connect an agent to ValidJSON.

Keep inference in your environment. Send completed records to Mode A, or bounded labelled text to Mode B.

Your model proposes. ValidJSON validates without receiving the model credential.

Contract reference

MCP for agent-side validation

One bounded tool: validjson.validate_record. It exposes Mode A over STDIO and performs no network or model call.

MCP
0.2.0

Agent configuration

{
  "mcpServers": {
    "validjson": {
      "command": "python3",
      "args": ["-m", "validjson_mcp"]
    }
  }
}

Can validate caller JSON Can use supplied schema or pack Cannot extract text Cannot authorize action

Contract reference

Typed Python client

Call the public contract without rebuilding request and problem semantics.

Py

Mode A example

from validjson import ValidJSONClient

client = ValidJSONClient(base_url="https://api.validjson.dev")
result = client.validate_record(
    record={"supplier": "TEST-SUPPLIER-ALPHA", "total": 42.5},
    supplied_schema=schema,
)

if result.result_type == "accepted":
    retain(result.evaluation_receipt)

The agent loop

Fast operations, explicit transitions.

01Agent proposesJSON or bounded text
02ValidJSON evaluatesDeterministic contract
03Evidence returnsAccepted or refused
04Authority stays separateFresh admission required

Mode A · Record validation

Validate a record.

Checks JSON exactly as supplied. No repair, coercion, or re-authoring.

Live public operation Contract reference: POST /v2/validate-record

Validation authority My JSON SchemaRequest-scoped selection Published packExact ID and version

Record JSON

JSON Schema

Stateless evaluation · no record stored

Mode B · Candidate production

Produce a JSON candidate.

Bounded labelled text only. Candidate production is the UI name for the structured_extraction operation. A candidate is not a validated record.

Live public operation Contract reference: POST /v2/process

Required grammar validjson-labelled-text-v1

One labelled field per line. JSON text, CSV text, broader prose, PDFs, and images are not admitted. The source is never sent to a model.

Labels match schema property names case-insensitively; spaces and underscores are equivalent label forms. Grounded values must still satisfy the supplied schema constraints.

Request problem: The request could not be evaluated. No completed evaluation means no receipt.
Completed refusal: The evaluation ran and refused. A receipt may preserve why, but no candidate or authority is returned.

Labelled source text

Required output schema

Bounded grammar · stateless request

Static design reference

Rigor without interface weight.

This example shows evidence hierarchy. It is not bound to a current input and is not a live receipt.

01

Example immediate result

Accepted

A live response would state the completed outcome before exposing technical fields.

02

Example operational context

Record validation under a published pack.

Operation: record_validation
Authority source: published_pack
Pack: purchase_order_v1 · 1
Further action: Fresh admission required

03

Example technical evidence

A live receipt would bind the completed evaluation.

receipt_ofrecord_validation

receipt_typestateless_evaluation

execution_modedeterministic_record_validation

receipt_hash_familyreceipt.evaluation_receipt_hash_v1

Show AuthorityLimits

durable_resource_created false schema_registered false review_completed false export_authorized false current_downstream_authority false cryptographically_authenticated false

Published validation authority

Business packs, exactly versioned.

A pack selects deterministic validation rules. It does not approve, register, export, pay, or authorize a record.

POPublished

purchase_order_v1

Purchase Order

Version: 1
Operation: Mode A

INPublished

invoice_v1

Invoice

Version: 1
Operation: Mode A

Bring Your Own Endpoint

Connection is not authorization.

Endpoint identity and immutable revision foundations exist. Live endpoint verification, admission, selection, and execution are not enabled here.

Policy foundation only

01RegisterIdentity + immutable revision Foundation exists

02VerifyConnectivity + capability probes Not implemented

03AdmitWorkflow + privacy + environment Not implemented

04ExecutePersist actual endpoint identity Not implemented

Frozen direction

Bring your own endpoint. ValidJSON governs whether, when, and how it may be used.

Registration does not authorize workflow use.
Credential possession does not authorize endpoint use.
Fallback never silently crosses an authority boundary.
Requested, admitted, and executed identities remain distinct.

Move at agent speed.
Keep the account intact.

Bring the agent. Keep your model.

Proposal and validation never collapse.

Validate a record you already have.

Produce a candidate from bounded text.

What happened? What governed it? What remains unresolved?

Why valid JSON can still be wrong.

The hidden decision inside clean JSON

One concept at a time.

Connect an agent to ValidJSON.

MCP for agent-side validation

Typed Python client

Public HTTP contract

Try the operations manually

Fast operations, explicit transitions.

Validate a record.

Produce a JSON candidate.

Rigor without interface weight.

Accepted

Record validation under a published pack.

A live receipt would bind the completed evaluation.

Business packs, exactly versioned.

Purchase Order

Invoice

Connection is not authorization.

Bring your own endpoint. ValidJSON governs whether, when, and how it may be used.

Move at agent speed. Keep the account intact.

Bring the agent. Keep your model.

Proposal and validation never collapse.

Validate a record you already have.

Produce a candidate from bounded text.

What happened? What governed it? What remains unresolved?

Why valid JSON can still be wrong.

One concept at a time.

Connect an agent to ValidJSON.

MCP for agent-side validation

Typed Python client

Public HTTP contract

Try the operations manually

Fast operations, explicit transitions.

Validate a record.

Produce a JSON candidate.

Rigor without interface weight.

Accepted

Record validation under a published pack.

A live receipt would bind the completed evaluation.

Business packs, exactly versioned.

Purchase Order

Invoice

Connection is not authorization.

Bring your own endpoint. ValidJSON governs whether, when, and how it may be used.

Move at agent speed.
Keep the account intact.