Jev and System 1 ModelsWhat Are They Not, and How Can We Use Them in AEC
Artificial Intelligence
6
min read
Within a week of launch, TypeSafe's Jev had been described as the end of the LLM wrapper, as a model that "never hallucinates", and as up to 200 times faster than frontier AI. Days later Convai Innovations released Laya, an open-weights rival, with a benchmark table claiming it beat Jev. Nearly all the coverage has been about speed, and some of it has gone further: if a model this small and fast can do the job, why pay for a large language model at all?
The speed is real. But speed is the least useful thing to know about these models. For anyone deciding whether to use them on a project, the useful questions are different. What kind of tool is this? Which jobs does it belong in? Which ones will it get wrong without warning?
This piece tries to answer those plainly: what a System 1 model is, what it isn't, where the launch claims hold up, and what happened when we tested one against a live safety workload we're building for a client.
What a System 1 model is
A System 1 model is a classifier. You give it a piece of text and a list of questions, and for each question you also give the answers it's allowed to choose from. It returns an answer to every question, with a probability for each, in a fraction of a second.
That's the whole contract. The text is called the state: a safety observation, an RFI, a contract clause, a page of a specification, or a JSON record. The questions are typed, meaning each one declares in advance what shape its answer must take. The model never writes a sentence. It only picks.
There are three question types:
type | what it asks | example |
|---|---|---|
| which one of these options? | which of our 30 hazard classifications fits this observation? |
| where on this ordered scale? | how severe is this, from 1 to 5? |
| is this true or false? | must work stop immediately? — answered as a probability |
A request looks like this:
The answer comes back as data rather than prose: the chosen classification with its probability — PPE: 0.96 in our test — and, for the yes/no question, a single probability that work should stop.
How that differs from an LLM. Ask an LLM the same thing and it reads the prompt, then writes its answer one word at a time, reasoning as it goes. That's what lets it explain itself, draft a response or work through a problem, and it's also why it takes seconds to minutes and costs cents per call. A System 1 model skips the writing. It reads the text once and scores every allowed answer to every question in a single pass. There's no reasoning step and no text to generate, which is where the speed and cost difference comes from.
Why that matters in practice. Three things follow from this design:
It's fast and cheap enough to run on everything. Answering eleven questions takes barely longer than answering one, and costs a fraction of a cent. You don't have to decide which records are worth processing.
It can only return answers from your list. There's no free text to parse and no invented categories, so an answer can go straight into a database field or a routing rule without a person checking its format.
It tells you how sure it is. Both Jev and Laya are trained to report honest probabilities — the training only rewards a model whose 90% answers are right about 90% of the time. That lets you set a threshold in ordinary code: above 0.75, file automatically; below it, send to a person. Whether the probabilities are that reliable in practice is a separate question, and we come back to it.
The name comes from Daniel Kahneman's distinction between fast, intuitive judgment (System 1) and slow, deliberate reasoning (System 2). The labels fit. These models make quick judgments against a fixed set of options. They don't deliberate.
What it is not
Most of the confusion in launch-week coverage comes from treating a System 1 model as a small LLM. It isn't, and what it doesn't do matters as much as what it does.
It does not reason. There is no chain of thought, no multi-step working, no ability to hold a premise and derive a conclusion from it. It maps a state to a distribution over answers you defined. If the right answer depends on working something out — reconciling a spec clause against a drawing note, checking whether a load path survives a change — that is System 2 work and it belongs to an LLM.
It does not explain itself. You get PPE: 0.96. You do not get why. For a regulated register that needs a rationale on file, something else has to write it.
It does not generate. It cannot draft the RFI response, the corrective action, or the notice. It can tell you an RFI is structural and probably a change in disguise. It cannot write back.
It does not act. No tools, no retrieval, no agent loop. It answers what it's asked about the state it's given.
It does not see. This matters most for AEC, so it's worth being exact. TypeSafe's model documentation says the input is "Text only. String, JSON object, or array of text values. No image, audio, or video input," and tells you to "pre-process non-text inputs (images, audio, video, binaries) into text or structured fields before sending them." Laya is built on ModernBERT and mmBERT text encoders, so it's text-only by construction. A drawing, a site photo, a scanned page with no text layer — none of these reach the model until something else has turned them into text.
It cannot be relied on to be right just because it cannot be malformed. TypeSafe's launch post is careful here — it concedes of its 0% hallucination figure that "our number is not empirical. Schema matching is guaranteed" — but coverage has not been. Pere Pages puts the limit exactly: Jev "cannot return a category you did not declare or a malformed value… It can still select the wrong one, confidently." Our test below shows what that looks like.
The accurate summary: a System 1 model is a classifier with a request-time schema and calibrated outputs, fast and cheap enough to sit inline in software. Nothing more, and that is plenty.
The hype, checked
TypeSafe's launch figures — 193.6× faster, 444.6× cheaper — pair Jev with whichever baseline gives the biggest ratio. Against the comparable model in its own table, Pages calculates about 25× faster and 76× cheaper. More importantly, TypeSafe's accuracy evaluation measures agreement with two frontier models' averaged answers, not human-labelled truth, on workflows its own team built — both of which TypeSafe discloses. On its own published invoice-processing workflow, Jev scored 61.8% against 74–79% for the frontier models.
Independent results are more useful. nibzard's benchmark measured Jev at a 264–276 ms median end to end, flat from 2 to 255 options, with a hard cap at 255. It also found Jev changed 13% of its choices when the option order was shuffled (the worst LLM tested changed 37%), and measured calibration error at 0.246 — respectable, but not the solved problem the marketing implies. Early third-party tests reported advantages from 1.6× to several hundred× depending on the comparison model, which is the real lesson: any single speed multiplier without its baseline is marketing.
None of that undoes the core result. The speed is real and reproduced. What it does mean is that the only benchmark worth trusting for your use case is the one you run on your own data.
The open-weights alternative: Laya
Laya matters for a reason that has little to do with benchmarks: you can run it yourself. It's Apache 2.0, in three checkpoints — a 421M-parameter English model on ModernBERT-large, a 322M-parameter multilingual model on mmBERT-base covering 100+ languages, and a variant fine-tuned for typed decisions. Convai report 32.8–39.5 ms per question on a Tesla T4, with no network hop.
For AEC that opens up two things Jev can't offer. Data stays inside the perimeter, which for many contractors and owners is a condition of using AI on project data at all. And a 322M model, quantised, runs on a phone, which matters where the work is — in a tank, a basement, or up a steel frame with no signal.
Convai's model card is also unusually honest about what the base model can't do. Its headline 0.766 on typed decisions comes from the fine-tuned checkpoint; the base checkpoints score 0.362 and 0.342 zero-shot, below the 0.461 you'd get by always picking the most common answer. In their words: "Laya is a fast base to specialise, not a zero-shot decision engine." It also ships over-confident — calibration error of 0.466, falling to 0.081 only after you fit temperatures on your own data — and its English checkpoint gives option text just 192 tokens by default. Thirty hazard classifications with descriptions need about 675.
Both of these limits showed up in our test.
The experiment: our live safety platform
We tested these models on a real job rather than a benchmark.
AECFoundry is currently building a safety intelligence platform for a major EPC contractor working on large-scale oil and gas projects. The platform collects safety observations from the jobsite, then triages, classifies, scores and routes each one to the teams that need to act on it. The client's sites produce more than 15,000 observations a month.
Anyone on site can raise an observation: an HSE officer on a walkdown, a supervisor, a worker with a card. Each one is a sentence or two of free text — barricade around the trench blown down overnight, first aid kit found understocked, vendor vehicle speeding past the gate. Before anyone can act on it, it has to be coded. In this client's register, that means five decisions:
Category — one of five: Unsafe Act, Unsafe Condition, Near Miss, Environmental, or Positive Observation.
Hazard classification — one of 30, each with a written definition and a list of common keywords: Working At Heights, Hot Works, Line of Fire, Energy Isolation, PPE, Barricades, Confined Space, Bypassing Safety Controls and so on.
Severity and likelihood — each on a 1–5 scale, multiplied into a risk matrix score.
Priority — High, Medium, Low, or No Priority for positive observations. Priority sets the close-out deadline: High within 24 hours, Medium within three days, Low within five. The Safety Team is told about every High immediately.
Routing — a table maps each of the 30 classifications to the teams that must be notified, from a list of 12: Safety, Construction, Maintenance, Scaffolding, Health, Environmental, Admin, HR, Engineering, Security, the Project Manager and the Project Director. A Fire observation goes to Safety, Construction, Security and the Project Director; a Heat Stress observation goes to Health and Safety.
Done by hand, that coding sits with HSE coordinators working through cards, often days behind, clearing the backlog before the weekly stats go to the client. At 15,000 a month, it's the bottleneck between an observation being raised and someone acting on it. That makes it exactly the kind of work System 1 models claim to be built for: high volume, fixed lists of answers, and a need for speed.
It's also less mechanical than it looks. In the register, four observations score an identical risk matrix of 6 and are coded High, Medium, Low and Low. The matrix isn't setting priority; override rules are. A dead man's switch taped down on a grinder goes High at a score of 6 because a safety control was deliberately defeated. Material stacked without barricading stays Low at the same score. In 28 of the 39 sample rows, severity and likelihood weren't filled in at all — the coder went straight to priority from judgment. Any automated system has to capture that judgment, not just the matrix.
So the question for the experiment was straightforward: could a System 1 model take on the triage layer of the platform, and where would it need help?
Turning the register into questions. We converted the coding process into eleven typed questions, sent in a single call:
question | type | options |
|---|---|---|
category |
| the register's 5 categories |
classification |
| all 30 hazard classifications |
lead team |
| the 12 teams |
severity, likelihood |
| 5 labelled levels each |
life-safety potential, control bypassed, person exposed, environmental release, stop work required, competence gap |
| yes / no, as a probability |
The six yes/no questions are the override rules made explicit: they ask about the things a coder actually weighs when a score of 6 becomes High. Everything else stays in ordinary code. The full notification list is looked up from the routing table rather than predicted, and priority is the matrix plus the overrides, with thresholds the HSE manager can read and change. The model answers the questions a table can't; the table answers the rest.
For a ground truth, we used the client's own coding. The register has a close match to our test observation — a worker doing substation maintenance without arc-flash rated coveralls, coded Unsafe Act / PPE / High. We sent the same eleven questions to Jev, to Laya's base checkpoint on its public demo, and to Claude Opus 5.
One observation, three models
Observed worker welding steel connection plates without a welding mask. Fabrication shop, bay 3. Still in progress.
Jev — 128 ms | Laya (base) — 2.2 s | Opus 5 — 31 s | register | |
|---|---|---|---|---|
category | unsafe_act (100%) | unsafe_condition (5%) | unsafe_act | unsafe_act |
classification | PPE (96%) | Hot Works (100%) | PPE | PPE |
lead team | Safety Team (100%) | Safety Team (100%) | Safety Team | Safety Team |
severity | major (94%) | minor (10%) | major | (coded High) |
likelihood | likely (27%) | unlikely (13%) | likely | |
life-safety potential | 0.90 | 0.08 | yes | |
control bypassed | 0.19 | 0.29 | no | |
person exposed | 0.90 | 0.15 | yes | |
stop work required | — | 0.74 | yes | |
input tokens | ~1.2k | ~1.8k | 121k | |
cost | ~$0.00005 | $0 (open weights) | $0.48 |
Bracketed figures are each model's reported confidence. Jev's playground showed 128 ms alongside a second figure of 224 ms, unlabelled; allow under 400 ms end to end. Laya was the public demo Space, not a warm GPU. Jev's cost is calculated from the payload size at $0.042 per million input tokens, with output free. Opus 5's figures come from the session usage panel (Figure 4): 121k tokens in, $0.48, 31 seconds. Most of those 121k tokens are the agent session's own context rather than the ~1.8k-token payload, so a bare API call with the same questions would cost less — but the gap would still be measured in orders of magnitude.Figure 1. Laya's base English checkpoint on the public Hugging Face demo. It picks Hot Works at 1.00 confidence, anchoring on "welding" rather than the missing mask. It also reports near-random confidence on category (0.05), severity (0.10) and likelihood (0.13), and correctly calls for work to stop (0.74). About 2.2 seconds end to end.
Figure 2. The same observation and questions in TypeSafe's Jev playground (jev-preview), sent with the 30 classifications as bare labels and no descriptions. It returns Unsafe Act (100%), PPE (96%) over Hot Works (3%), Safety Team (100%) and major severity (94%). Likelihood is split between likely (41%) and almost certain (37%), for 27% confidence. The response header shows 128 ms.
Figure 3. Claude Opus 5 on the same triage task: Unsafe Act, PPE, Safety Team, major severity, likely, with life-safety potential, person exposed, stop work and competence gap all flagged. This matches the register's coding of the comparable arc-flash row exactly. About 31 seconds.
Figure 4. Usage for the Opus 5 run: 121k input tokens, $0.48, 31 seconds wall time (30 seconds of API time). The input count covers the whole agent session, not just the observation and questions. At the same cost, Jev could classify roughly ten thousand observations.
Three things stand out.
Jev matched the frontier model on every answer shown — using bare labels. Jev was sent the 30 classifications as names only, with no descriptions. Laya had the full descriptions and keyword lists from the register. Jev still chose PPE over Hot Works 96 to 3.
Laya's failure has a name. Hot Works at 100% confidence. The observation contains "welding", and welding is in the Hot Works keyword list — taken from the register's own classification sheet. But the hazard isn't the welding; it's the missing mask. An encoder matching surface features finds a strong match for "welding" and nothing for an absence. Call it surface-feature anchoring. It will recur wherever a register codes what's missing — no barricade, no permit, no tag, no supervision — which describes most Unsafe Condition rows. The register handles this consistently: welding equipment not leak-tested is coded Hot Works, because there the activity is the hazard; a missing mask is PPE. That's a site convention, and teaching it is exactly what fine-tuning is for.
Figure 5. Laya Playground on Huggingface - same inputs, similar outputs and performance to Jev.
That point matters for reading this result fairly. What failed here is Laya's base checkpoint, out of the box: a general-purpose model trained on public datasets that has never seen a safety register. It isn't expected to know one site's coding conventions, and Convai don't claim it does; their own model card calls it "a fast base to specialise, not a zero-shot decision engine." This is also where the two models differ in kind, not just in score. Jev is a closed API: you get the model TypeSafe ships, however well it happens to suit your domain. Laya's weights are open under Apache 2.0, so you can fine-tune it on your own register. That means a few hundred coded observations where the answer is PPE, not Hot Works, and a model that learns the site's conventions and then runs on your own hardware. Convai's fine-tuned checkpoint went from 0.362 to 0.766 on their typed-decisions benchmark. Whether a fine-tune closes the gap on a safety register is something to test, not assume, but it's an option Jev doesn't offer at all.
The confidence numbers told two different stories. Laya's category (5%), severity (10%) and likelihood (13%) were close to random across five options — it was correctly signalling that it was guessing, and any sensible threshold would have escalated all three. Then it put 100% on the wrong classification. Confidence gating catches the uncertainty and misses the error. Jev's one low-confidence answer — likelihood at 27%, split between likely and almost certain — is where two experienced HSE coordinators would plausibly disagree too. That's what calibration is supposed to look like.
One row, one site. It proves nothing on its own — but it's exactly the kind of test to run fifty times before you trust either model.
What it costs at jobsite scale
One observation is a demo. The numbers only mean something at the volume the client's sites actually produce: more than 15,000 observations a month, each needing the same eleven decisions as the welding example.
Scaling the single-observation measurements to that volume:
per observation | per month (15,000) | per year | sequential compute per month | |
|---|---|---|---|---|
Claude Opus 5 | $0.48 · 31 s | $7,200 | $86,400 | ~129 hours |
Jev | ~$0.00005 · 128 ms | ~$0.76 | ~$9 | ~32 minutes |
Laya, self-hosted | $0 marginal · ~35 ms on a T4 | GPU cost only | GPU cost only | ~9 minutes |
Two caveats keep this honest. First, the $0.48 was measured inside an agent session, where most of the 121k input tokens were the session's own context; a lean, direct API integration would cost less per call. Assume it came in at a tenth of that — $720 a month — and the gap is still around a thousand to one. Second, Jev isn't free. It's just cheap enough that the line item rounds to nothing: under a dollar a month for the whole programme, at $0.042 per million input tokens with output unbilled.
Using a frontier reasoning model to put 15,000 cards a month into the right dropdown is a sledgehammer on a drawing pin. It works, and at this volume it's a real budget line — one that has to be justified to a client every quarter, for a task a classifier does as well in this test. The cost difference changes what's sensible to build. At $7,200 a month you ration the model: batch the cards, run them overnight, skip the low-priority ones. At under a dollar you run every observation the moment it's filed, run it twice to check agreement, and still have the whole frontier-model budget for the few hundred observations a month that actually need reasoning: the incidents, the dual-category rows, the ones where the two classifiers disagree.
That's the split this platform is built on. The System 1 model handles all 15,000; the LLM handles the few percent where judgment is required.
Why AEC is built for this
The pattern System 1 models fit is specific: many bounded questions against one piece of text, at volume. Construction runs on that pattern. Most of these judgments currently sit with one or two experienced people who do them hundreds of times a week.
Document and page classification for extraction. A tender package arrives as 4,000 pages. Before anything can be extracted, every page needs sorting: drawing, specification section, schedule, bill of quantities, calculation, correspondence. That's a choice. Then a handful of noul flags per page — contains a door schedule? references a superseded revision? — decide which extraction pipeline sees it. At $0.042 per million input tokens, sorting the whole package costs cents and takes seconds, so the expensive LLM only reads the pages that matter. One caveat: pages must have a text layer. Scanned sheets and drawings need OCR or a vision model first.
Risk classification on site reports and data. The worked example above, extended beyond observation cards to site diaries, toolbox talk records, daily reports and incident logs. The pattern is the same everywhere: a handful of classification questions, plus the yes/no flags that actually drive priority, with routing and thresholds left in code where the HSE manager can see them.
RFI triage by discipline. Discipline as a choice (architectural, structural, MEP, civil, façade); urgency as a score; and the question that matters commercially as a noul: does this read as a change rather than a clarification? Routing an RFI to the right consultant in 100 ms isn't the prize. Spotting the change in disguise before the clock runs is.
Parallel contract review against criteria. A contract is a set of clauses and a review is a checklist, so the two map cleanly. Run each clause as state, with forty questions in one pass: noul for contains a time bar, caps liability, requires a notice within a stated period, includes pay-when-paid; choice for risk allocation (employer / contractor / shared) and clause type. That produces a clause-by-criteria risk matrix in seconds, with probabilities attached, for a lawyer to review. The model flags; the lawyer decides. Which clauses to read first is a good job for a System 1 model. Advising on them isn't.
BIM compliance on element metadata. IFC property sets are already structured text, so they fit without conversion. Each element's properties become state; the questions are the requirements: noul for fire rating declared where the element type requires one, LoadBearing consistent with the element's classification; choice for the correct classification code against the one declared. A federated model with 200,000 elements is a batch job measured in minutes. What it can't check is geometry — clashes, clearances, spatial relationships. That's rule-based checking or an LLM with tools, not a classifier reading property sets.
All five share one shape: many decisions, bounded answers, and a cost of error that a human gate can absorb. Outside that — writing the response, judging a novel technical problem, reading a drawing — belongs to other tools.
Limitations
Text only. No drawings, no site photos, no scanned pages, confirmed in TypeSafe's documentation and inherent in Laya's text-encoder architecture. For a sector whose primary medium is the drawing, this is the biggest constraint. The workable pattern is a vision or OCR step that turns images into text or structured fields first, with the System 1 model working downstream of it.
No rationale. The output is a probability, not a reason. A deterministic rule with named inputs — priority High because control_bypassed = 0.91 exceeded the 0.60 policy threshold — is arguably more auditable than an LLM's explanation written after the fact. But plenty of ISO 45001 systems still want a named person to assign a risk rating.
Bounded answer spaces. 255 options maximum on Jev. On Laya, around 20 before the default token budget runs out; raise head_max_len or split the question into two stages.
Context. Jev: 64k tokens per request, 32k for state plus the longest question. Laya English: 512 tokens by default. A whole contract doesn't go in one call; its clauses do.
Multi-label. One register row is coded Unsafe Act and Near Miss. A single choice can't express that; model it as separate noul questions.
Calibration you haven't measured. Treat probabilities as rankings until you've fitted and tested them on your own data.
The architecture that works
Put the evidence together and the design is fairly clear:
System 1 first, on everything. All observations, all pages, all clauses. Its job is triage and the immediate flags — stop work, life-safety, potential change.
Code sets the thresholds. Neither model decides what counts as urgent. The HSE manager does, in a line of config.
The frontier model does the slow, careful part, in the background, on the subset that needs it: the rationale, the multi-label cases, the drafting.
Disagreement is the escalation trigger. In the table above, Laya's self-reported confidence missed its worst error. Disagreement with the other models caught it at once. A second System 1 call costs a fraction of a cent.
That's the real case for the category, and it answers the headline. A System 1 model isn't an LLM killer. A 128-millisecond classifier doesn't replace the model that reasons; it decides, at almost no cost, where the reasoning should go.
For our client's platform, that's the design we're now testing at scale: a System 1 model triaging every observation as it's filed, with the frontier model reserved for the cases that need judgment. One observation proved the idea is worth pursuing. The next step is running the full coded register through it and counting where each model agrees with the people who do this job today.
If you're interested in learning more about these models and how they can be applied within AEC workflows, book a working session to explore opportunities and possibilities.
