e-Pattern Compiler in development

A converter that turns existing knitting and crochet patterns into interactive e-patterns: steps, sizes and repeats captured in a structured form, every adopted instruction linked to its place in the original. Language models interpret the document; a small deterministic core checks what they propose.

What we are building

We are developing a converter that turns existing knitting and crochet patterns into interactive e-patterns. It is meant to capture steps, sizes and repeats in a structured form, detect certain contradictions, and link every adopted instruction to its place in the original. Step by step we are also researching stitch-exact execution and the visualisations that follow from it. The project is in research and development. Here we report on progress, experiments and the challenges that remain open.

Crazypatterns, a marketplace for knitting and crochet patterns, is a project of SIA "AISYS", as is this lab. 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

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:

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:

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

State of development, 10 September 2026

The work has left the pure preliminary study and includes concrete implementation. The first phase examined existing approaches, mathematical models, possible architectures and checking methods, with limited synthetic experiments and counter-examples. Development then started on a corpus provided by Crazypatterns.

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.

ComponentState
Local source intake and native PDF extractionImplemented and run on the corpus; original archives checked for integrity
Structured pattern formatPrototype available
Browser readerPrototype available; functions and states partly covered by automated checks; a fully accepted browser and conversion path for the whole scope is not yet shown
OCR and image-based extractionChecked on synthetic examples; technically successful runs still contained individual recognition errors, and later conversion samples showed errors of meaning despite largely correct text
Textile execution core for limited knitting and spiral crochet sequencesImplemented; addressed operations, target relations, state changes and defined finishing sequences; synthetic complete examples and targeted counter-cases checked
Link between pattern program and stitch coreStarted and checked; one status gap corrected: a mechanically complete text part must not show known unresolved image content as done
Interactive 2D viewConcrete design exists, showing operation nodes, target stitches, working order and source references; implementation and acceptance not shown
Full semantic check of a real development caseNot yet completed successfully; the latest visible attempt failed on an invalid source reference in a model response and was discarded as a whole
3D and physical formFurther research direction

Dated findings from this work, including the documented error examples, appear in the posts below.

The development corpus

Development runs on the collection "patterns-1", 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 (source: data/epattern/inventory-2026-09-10.json in the site repository):

ItemCount
ZIP archives63
File occurrences contained268
Distinct file contents265, with three identical duplicate occurrences
Distinct PDFs182
Distinct image files83
PDF pages in total2,433
PDFs with native text on every page166
PDFs without native words16, together 514 pages

These figures describe what was taken in. They are not a number of successfully converted patterns, and individual files are not automatically independent designs or product families.

Next research questions

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 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 locally or on approved LAN processing within the project. 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:

Posts about this project

Project feed (RSS)