Imagine a candidate export whose 400,000 lines all parse. Then a reviewer asks which outcome belongs to which request, and nobody can answer without reopening the source system.

That is the silent failure mode of JSONL business datasets. The format accepts almost anything. The schema is what decides whether a case survives the export with its meaning intact.

If you are preparing approved operational histories, start from one question: what does a reviewer need to know to understand the task and its result?

Should JSONL store one event or one case per line?

JSONL stores one JSON value per line, and dataset producers commonly use one object per line. A workflow design might write each event as its own object and tie related events together with a stable case identifier.

Another design stores the complete case in a single object. Neither is universally better: event-per-line streams well and handles long histories, while case-per-line keeps context together and simplifies review. The intended task, record size and review process should make the call.

Whichever you choose, document it. Downstream users should never have to reverse-engineer your structure from five sample lines.

From raw events to a reviewable case. A conceptual sequence drawn from this article, not a measured result or a completed transaction.

The fields that carry meaning

For an illustrative, invented support workflow, a minimal event schema might look like this:

• case_id: stable identifier linking every event in the case
• event_time: timestamp, with its precision documented
• seq: explicit order within the case, so ties never get ambiguous
• role: customer, agent, supervisor or system
• event_type: request, action, approval, outcome
• context: only the information permitted for the task
• outcome_status: a documented status, with unknown, missing and not applicable kept distinct
• label_origin: source_system or derived

An invented excerpt might read {"case_id": "C-1042", "seq": 3, "role": "system", "event_type": "outcome", "outcome_status": null, "label_origin": "source_system"}. Use straight quotation marks in actual JSON. Here, null means the outcome was not verified. The last field identifies the label source: if preparation inferred a category, record that transformation rather than presenting it as an original system value.

Also stop collapsing unknown, missing and not applicable into the same empty string. Those are three different facts, and flattening them deletes a limitation the reviewer needed to see.

How do you prevent hindsight from leaking into evaluation?

Evaluation often needs only the information available before a decision. A resolution note written two days later should never surface in the earlier context.

The format accepts almost anything. The schema is what decides whether a case survives the export with its meaning intact.

Keep event order and decision boundaries explicit. If timestamps were generalized for privacy, say how that affects sequence and interval accuracy.

Choose group and time boundaries that fit the task. Related cases may need to stay together across training, development and final evaluation so a sibling record cannot reveal the answer. Keep the final holdout out of iterative prompt tuning and retrieval examples; a stable case_id makes those relationships visible but does not enforce the split.

Schema checks that matter: the four checks this article walks through.

Give every transformation a paper trail

The W3C PROV standard describes relationships among entities, activities and responsible agents. Its vocabulary is a useful model for recording where a prepared record came from and what happened to it along the way.

In practice you can implement the idea with a manifest and a transformation log shipped beside the data, without exposing restricted source identifiers in the delivered file. Record the preparation version, exclusions and known limitations so another reviewer can understand the artifact without guessing how it was built.

Does schema validation establish licensing rights?

A JSON Schema check catches a missing field or an unexpected type. It cannot establish licensing authority, outcome accuracy or the absence of sensitive contextual detail.

The company still has to review rights, confidentiality and personal information for the actual scope. Some material needs exclusion, not a new field name or a replacement token.

When that preparation serves a commercial use, the contract is between the company and SourceX, which licenses approved business records for AI training and evaluation. SourceX runs the pipeline from there: qualification, scope, rights review, preparation and payout, all under signed terms.

SourceX advertises up to $4 million for the largest enterprise datasets. It is not a typical payout, a price for producing JSONL or a guarantee that a valid export qualifies. A signed Dataset Deal Confirmation fixes the actual records, rights and compensation; technical validation and commercial acceptance are separate.

Extraction and delivery require a signed Master Supplier Licensing Agreement, a signed Dataset Deal Confirmation and SourceX's go-ahead. Signing does not guarantee a purchase: SourceX may decline the delivered data. Written acceptance and every Closing condition lead to a Closing Notice, then an invoice. Under standard terms, payment is due within 60 calendar days after SourceX receives a valid invoice, unless different terms are signed. Data that does not reach Closing earns no payment.

The reconstruction test: Give a second reviewer only your schema and one exported case. If they can’t explain request, decision and outcome in order, fix the schema before you scale.

What should a developer test first?

Run a reconstruction test. Take one authorized or fully invented case, give a second reviewer only your schema and the exported lines, and ask them to explain the request, the decision and the outcome in order.

If they cannot, fix the representation before you scale the export. Good JSONL business datasets preserve the business meaning that made the records worth exporting in the first place.

A valid schema is preparation, not acceptance. Start with SourceX's company fit check without uploading records, and agree the selected collection, rights and processing route before building a commercial export.

About the founder

Noah Loul is a four-time founder and the founder and CEO of SourceX, which licenses business data directly from companies for AI training and evaluation. He previously founded B2B Rocket, acquired by Blackpearl Group. His work focuses on building permission-based data infrastructure for AI.