e-Pattern Compiler in development

A converter that turns knitting and crochet patterns into interactive e-patterns, with steps, sizes and repeats structured and every instruction linked to its place in the original. Language models interpret; a deterministic core checks.

• Every model reading counts as provisional until the deterministic core has checked it
• Correct counts prove little: fidelity, meaning, executability and depiction are judged apart
• Developed on one author's patterns; nothing is claimed for other authors or layouts

What we are building

The converter is also meant to detect certain contradictions; step by step we are researching stitch-exact execution and the visualisations that follow from it. The project is in research and development.

Crazypatterns, a marketplace for knitting and crochet patterns, is a project of SIA "AISYS", as is this research programme. Inputs are PDFs, text patterns and blog posts released for the purpose. The originals may contain running text, tables, several sizes, abbreviations, images, knitting or crochet charts and assembly notes. From these the converter is to produce one coherent pattern program whose steps can be executed, followed and checked.

What an e-pattern contains

• Materials, tools, measurements and whatever the original says about gauge.
• Technique, language, abbreviations and the conventions the original states.
• Size variants and the parameters a user may set.
• Ordered working steps, rows, rounds and repeats.
• The individual components, and how they are joined and assembled.
• Starting, finishing, stuffing and weaving-in steps.
• Source references, so that every adopted instruction can be found in the original.
• Diagnoses of contradictions, missing information and unsupported techniques.
• An interactive representation for later use.

The whole action counts. A system might capture how a body is crocheted and then skip the stuffing, the sewing together of the parts, or the weaving in of the ends. Such a conversion is not complete.

Who is meant to benefit

Users should be able to work through a pattern step by step, pick a size, and save their progress. Repeats and the current step should be shown in a way that is easy to follow, and the corresponding place in the original should be one step away.

Authors should receive notes on specific problems: contradictory stitch counts, missing definitions, incomplete cross-references. For Crazypatterns an interactive use of the existing catalogue could follow.

Fewer questions from users, lower abandonment, economical conversion and a more attractive experience are hypotheses to be examined. There are no reliable figures on any of them yet.

Three stages

1. Interactive reader. Source-bound steps, size selection, repeats that are easy to follow, progress, resumption, and a complete finish.
2. Stitch-exact execution and a 2D view. Each operation is executed with its target stitches, the stitches it creates, the working direction and the change of state it causes. A depiction is to be generated from exactly these checked sequences, not drawn independently of them.
3. 3D and physical form. A structural preview and a realistic prediction of the finished piece are different tasks. The physical prediction needs additional information about yarn, tension, gauge, material and handling.

The third stage is a further research direction. No finished, realistic 3D simulation exists. A pleasing 2D or 3D drawing also proves nothing about whether the original was interpreted correctly.

How the conversion is meant to work

The preferred direction combines AI with a small deterministic execution core. Language and vision models interpret the document and produce structured program candidates. Every candidate is, at first, a possibly wrong interpretation.

A deterministic core executes defined operations by fixed rules. It checks, for example, whether target stitches exist, whether repeats can be carried out, whether state transitions are permitted, and whether the computed stitch counts match the counts the original states.

1. Take in the original unchanged and version it.
2. Capture text, layout, images and the other parts of the document.
3. Build a source inventory, so that omitted content becomes visible.
4. Generate structured, source-bound instruction candidates from it.
5. Check structure, references, completeness and the supported textile operations.
6. Assign a traceable result status with diagnoses.
7. Feed the reader and later visualisations from the same structured base.

This architecture is the preferred research hypothesis, not a proven winner. Direct AI generation under the same checking conditions is examined as well, and so is the processing of controlled notations and charts. Learned parsers, author-specific templates and similar methods come into question later, once a suitable, checked body of data exists.

For code and architecture one rule applies: maximum simplicity and readability, and minimalism in the entire code and architecture. That means the smallest understandable solution that meets the actual requirements. Unnecessary frameworks, abstractions and parallel data models are avoided. Dropping requirements does not count as simplification.

What "as automatic as possible" means

Operation without routine manual editing of every result. For that the system must be able to report on its own that a pattern is unclear, contradictory, incomplete or outside the supported scope. Automatic release is to rest on demonstrated quality for clearly named areas of application. The kinds of result foreseen are:

• Processed successfully within the named scope of checking.
• Usable as a reader, but not yet executed stitch by stitch.
• Extracted incompletely.
• Missing definition or legend.
• Ambiguous interpretation.
• Contradiction between the source's figures and the computed sequence.
• Unsupported operation.
• No valid candidate found.

An open user parameter can be correct: "repeat until the desired length" is not automatically an error. A missing definition, on the other hand, must not be reinterpreted as a free user choice. The original is never silently repaired. Stated and computed figures are kept apart. A detected conflict is a finding under documented assumptions, not automatically a proven author's error.

Why correct numbers are not enough

Several different stitch sequences can produce the same stitch count. An increase in the wrong place can be numerically correct and still change the structure. Knit and purl stitches have the same balance. In crochet a different insertion point changes the meaning without changing the count.

The following shortcuts are not sufficient to judge quality either:

• A formally valid data format does not prove that the text was understood.
• A source citation does not prove that the interpretation is right.
• Agreement between several models does not replace an independent proof of correctness.
• A plausible visualisation does not prove correct construction.
• Successful text recognition does not prove successful conversion.

Document fidelity, fidelity of meaning, structural executability, geometric depiction and physical prediction are therefore assessed separately.

State of development, 21 September 2026

Since the state of 10 September the conversion has gone from preliminary study to a running path: intake, extraction, interpretation by a locally run language model, checking by a deterministic core, package, reader. The interim report of 21 September describes the way there; this is the state.

Labels used below, in ascending order: planned; prototype available; checked on synthetic examples; tried on a real development case; independently accepted. Nothing has reached the last label yet.

Measured reach. All figures hold for the corpus of one author.

A candidate is a package that passed the structural check. That proves no fidelity of meaning: every package carries the mark "not checked by an expert", and the reader shows it.

The development corpus

Development runs on a collection provided by Crazypatterns. It comes from one author. No reliability for other authors, styles or layouts can be derived from it.

The mechanical inventory as documented on 10 September 2026:

A later review refined the corpus: 63 of the 182 PDFs are single-page leaflets without pattern content; the remaining 119 documents with 2,370 pages between them are the patterns. They are split into a development set of 93 and a holdout set of 26 documents. These figures describe what was taken in, not a number of successfully converted patterns.

Next research questions

• Have fidelity of meaning checked by people with textile expertise, independently of format validity.
• Settle the legal question before the reader shows excerpts of real original pages.
• Symbol charts made of many small signs, which so far stay unresolved on principle.
• Connect stitch-exact execution with the reader and the 2D view.
• Bring in further authors before any reach beyond one style is claimed.
• Accept a first real pattern completely in the browser, from the original to the result.

A parser that rejects every difficult case meets the project goal as little as a reader without automatic conversion. Named limits remain necessary; frequent, solvable gaps remain development work.

What we do not claim

No universal freedom from errors. No proven fidelity of meaning. No full automation for every pattern. No fully converted catalogue. No demonstrated reliability across different authors. No realistic 3D prediction of shape. No business improvements achieved. No market leadership or uniqueness. There is currently no release date, no product pricing and no reliable general conversion rate.

Handling of originals

Original patterns and raw document content are handled only on the project's own machines. Nothing about that releases such content for publication here. Public demonstrations will use our own synthetic examples; real patterns need a matching release from their author.

Updated: 4 October 2026