Technology
One source, one structured draft, one human review
This direction starts from a single bounded task: one document of an agreed format becomes a structured record draft, every draft value names the source line it came from, and a person reviews and approves before anything is used.
The workflow
One document in, one reviewed record out
The capability is designed around one repeated task — reading a source document into a structured record — never around replacing the company core system or covering every process at once.
Three bounded steps
One source
One document of one agreed format enters the flow, and the format is confirmed with the company before anything is read.
Structured draft
The source is read into draft fields. Every value stays tied to the exact source line it came from, so no part of the draft floats without an origin.
Human review
A person checks every field: empty values are marked, doubtful values are flagged, corrections are written down, and nothing is final before approval.
Where the scope stops
The flow covers one workflow and one reviewed record. It does not replace a core system, does not promise to control every process, and writes nothing into other systems on its own.
The bounded flow is shown as a static illustration with invented text — not a service that runs, and not a document anyone can submit.
Local synthetic functional demo — not an offered service or production system.
Open the local synthetic functional demo
Document → draft → human review
Fixed rules run in your browser; no external provider, upload, database, tracking or saved records. This is not AI. Use synthetic edits only. Reloading discards your work.
The same frozen English source tokens and machine values are used in both languages; interface instructions are localized.
Synthetic source document
Title: Synthetic tray check
Owner: review-role
Date: 2030-01-01
Summary: Count paper tokens
Decision: proceed
Next: Inspect trayReady to run
Inspect all six fields against their source. A human must correct ambiguity, confirm review, then explicitly approve. A later edit invalidates review. Approval is local only.
Review reason: Synthetic fixture correction or confirmation
Method / corpus / reviewer protocol: fr18-rules-1 / fr18-corpus-1 / fr18-review-1
Limitations: one frozen plain-text format and six exact-label fields. No OCR, semantic understanding or arbitrary documents. These fixtures are not production accuracy or generalization evidence. A match can mean an expected failure, not a successful extraction.
Frozen evaluation — protocol replay
This automated replay applies only the predefined synthetic reviewer corrections. It is separate from your interactive review, not a human study. Approval, fallback and failure are mutually exclusive outcomes.
Protocol: synthetic-reviewer confirms normal drafts; corrects C06 ownerRole and C07 nextAction from explicit fixture instructions; never approves fallback or failed cases. No hidden human judgment is measured.
An inspectable example
An invented source, a mapped draft, a human decision
The shortest sample shows the whole shape before any real work: a few source lines feed a draft whose values name their lines, one deliberate ambiguity is corrected, and the reviewer explains the decision.
Static illustration — invented sample, no real document
Source lines (invented and anonymous)
- From: the equipment supplier
- To: the regional depot
- Carries: twelve corner braces, painted black
- Carries: one box of mounting pins
- Checked: braces counted before loading
- Stamp: receipt pending at the depot
Draft record with its sources
- Field
- Receiver
- Draft value
- The regional depot
- Source snippet
- the regional depot
- Field
- Item one
- Draft value
- Corner brace
- Source snippet
- twelve corner braces
- Field
- Item one quantity
- Draft value
- Twelve
- Source snippet
- twelve
- Field
- Item one finish
- Draft value
- Black — needs a source check
- Source snippet
- painted black
- Field
- Item two
- Draft value
- Mounting pins
- Source snippet
- one box of mounting pins
- Field
- Receipt status
- Draft value
- Pending — the stamp is not a confirmed receipt
- Source snippet
- receipt pending at the depot
What a reviewer sees
Deliberate ambiguity
The source says "painted black". The draft first read that as the finish of the braces, but the same words could describe the packaging. The source alone cannot settle the question.
Correction
The reviewer changes the field to "needs a source check" instead of keeping a guess, and writes the question to the sender into the review note.
Reject or approve
The reviewer rejects "Receipt status" because a pending stamp is not a fact, keeps the receiver and the item names as read, and treats the finish question as a blocker for approval. This is the same choice a person would make on a real record — shown here as text, with nothing submitted.
What runs on this illustration
- Static illustration
The panels and their text are fixed here; nothing reacts, changes, or moves.
- Manual steps
Reading, checking, and entering the record are human actions, shown only as text.
- Mock integration
No other system is connected, so nothing is read from or written to one.
- Working functionality
This illustration has no running functionality: none runs here; no model reads the source and nothing is submitted or stored.
Explicit boundary: these panels and values are fixed text in this page. No AI model executes, no system is connected, and no document or record is sent anywhere.
A real engagement would agree the format, the fields, and the review rules first, then replace this sample with its own reviewed output.
Negative cases
What stops, what is flagged, and the manual path
Rules for problem inputs are agreed before any document is read. The kinds below are the shape of that agreement for one sample format.
Format limit
- One source layout at a time — the layout the company confirms it really uses.
- A second layout, handwriting, or an image without text stays outside the same flow.
Missing input
- A field the source does not contain is left empty and marked "not in source".
- A source that cannot be read at all stops the flow instead of producing a guess.
Conflicting input
- Two source lines that disagree produce a visible flag and a question for the reviewer.
- No conflicting value is chosen silently; the record stays unapproved until a person decides.
Unsupported input
- Anything outside the agreed format is marked unsupported rather than forced into the draft.
Manual fallback
- When a case cannot be read safely, a person completes the same review form by hand, and every value still names its source.
These are design rules for one flow, written here in plain language — not a report of a run or of tests that have passed.
Boundaries and responsibilities
Who answers, what data joins, where it stops
Five plain commitments keep the flow small enough to review. Each one is settled with the company before any real document is handled.
Reviewer responsibility
The reviewer answers for the record: every kept value, every correction, and every rejection is recorded together with the person who decided and the reason.
Data boundary
Only the agreed sample format enters the flow. Source and draft stay inside the agreed scope, and the page runs no intake: nothing is collected, sent, or stored.
Integration boundary
A first build writes nothing into other systems. Any future connection is scoped and approved separately, and stays read-only until a person decides otherwise.
A simpler alternative
Where the layout is stable, a plain form, a spreadsheet, or a rule-based import can solve the task without AI — and would be compared first.
Not a system replacement
This is one workflow, not an ERP replacement, a core-system migration, or a promise of company-wide control.
The manual fallback and the human decision stay in place at every step, so a blocked or doubtful case never forces an automated choice.
Honest status
Planned state, from the same registry
The three axes below come from the typed registry every public page reads: one capability at its planned state, nothing more.
- Stage
- concept design
- Availability
- not offered
- Proof
- design illustration
The capability stands at concept design: no document has been processed by this flow and no run has been measured. The capability reports no result; this page shows the direction above, not an operational result.
No evaluation is claimed here. The separate local synthetic demo is a reviewed step with its own labelled evidence; this page does not claim an operational result.
Local preview
Try the sample brief builder
The private consultation preview runs entirely on this site: three local, rule-based questions about one real operational problem produce a brief you can review and edit in ephemeral in-tab memory. It does not contact Halsamer. Clipboard/download only on explicit user action; browser restore/session behavior is outside page control.
Open the sample brief builderLocal preview only: rule-based and no AI model runs; no answer/form submission or contact occurs; form answers exist only in ephemeral in-tab memory and are not sent to Halsamer. Clipboard/download only on explicit user action; browser restore/session behavior is outside page control.