CyberSygn Detection Technical Guide: How Two Layers Find Every Field

Most signature spots are already labeled inside the file. The hard part is reading all of them in milliseconds.

You drop a contract into CyberSygn, and a second later every signature line, initial box, and date field already sits in place. No dragging, no squinting. That is the CyberSygn detection technical engine doing its job, and here is the part most people overlook. The detector runs across two distinct layers, and the first one needs no AI at all. A fast text-based reader resolves about ninety-five percent of contracts on its own, while a vision model steps in only for the unusual cases that defeat it. In this post you will see how each layer of the PDF detection pipeline works, why the split exists, and what this automatic field detection means for the contracts you send every week.

Layer One: The Text Walker That Reads Your PDF Like a Recipe

A PDF page is not actually a picture, even though it looks like one on screen. Underneath the surface, the page is a sequence of drawing commands that tell the renderer to move here, set this font, draw this text, and draw this line. Think of it as a recipe the page follows in order to paint itself. The detector reads that recipe one instruction at a time, and this traversal is what we call the walk. As it proceeds, it tracks the current font and position, then assembles the loose fragments of text into clean labels and lines. This stage matters more than it first sounds, because in a raw PDF the word "Signature" might be scattered across several commands and drawn letter by letter, which forces the walker to reconstruct those fragments into a single word before it can match anything. Every command also carries exact coordinates, which means the detector always knows where each word sits, down to the point. That precision is what makes accurate placement possible, because PDF content stream parsing delivers both the text and its location on the page at the same time.

How the Matcher Turns Labels Into Placed Fields

Once the text is clean, the matching stage begins, and this is where the signature detection engineering searches for familiar shapes. It identifies "Signature:" followed by a line, "(Initial)" beside a short underscore, "Date:" next to a blank, or a checkbox square paired with its label. Each match returns two facts, the field type and where it belongs, so a hit on "Date:" becomes a date field placed right after the colon, while a long underscore after "Signature" becomes a signature field sized to that exact line. The pattern list is deliberately narrow, and it stays conservative because a mistaken addition is worse than an omission. If the detector inserts a field you never wanted, you have to find it and delete it, whereas if it overlooks one, you simply click once to add it. So the parser only commits to fields it is genuinely confident about. This principle is the foundation of the CyberSygn detection technical design. The detector is not examining a flat image and guessing, because it reads the page's own underlying instructions directly. That is exactly why this layer of the PDF detection pipeline finishes in milliseconds, runs free inside your browser, and still gets the placement right.

Layer Two: When the Text Walker Comes Up Empty

So what happens with a contract that contains no labels at all? Consider a hand-drawn form, or a scanned page run through OCR where the text was interpreted from a photograph and came back messy or incomplete. Consider a contract that marks where to sign using nothing more than a visual cue and no actual words. For documents like these, the text walker returns nothing, because there is no clean label embedded in the recipe to match against. The page itself might be a single large image with no genuine text underneath it, and that is the moment when CyberSygn deliberately switches paths. The detection algorithm falls back to vision. The page is rendered into an image, and that image is forwarded to a multimodal model, Anthropic's Claude Sonnet 4.5, accompanied by a structured prompt that tells the model exactly what to look for and what shape of answer to return. The model then examines the page much the way your own eyes would. It recognizes the empty line beneath a typed name and the box waiting for an initial, then returns those positions in the identical format the text walker uses. As a result, the rest of the app never has to care which layer discovered them. This vision fallback is the safety net of the CyberSygn detection technical design, and it captures the line a human would obviously notice even when no text marks it. The trade-off here is real and worth stating plainly. This path runs slower, measured in seconds rather than milliseconds, and it consumes API credit on every run, and like any model it is not perfect, so you still get a quick chance to confirm before you send. That is why vision remains in reserve as the careful specialist, called in only when the fast reader comes up empty, which delivers the safety net without imposing the speed or cost penalty on every single contract.

Why the CyberSygn Detection Technical Split Wins for You

Here is the reason two layers outperform one. The text walker runs in milliseconds, costs nothing, and clears roughly ninety-five percent of contracts, whereas the vision layer is slower, consumes credit, and handles the remainder. By attempting text first and reserving vision as the fallback, the pipeline captures both advantages at once: speed and zero cost on the common case, plus accuracy on the rare one. Compare that to a vision-only design, where some tools forward every page to a model regardless. That approach is slower for everyone, and it wastes credit on contracts that never needed it, because your plain NDA does not require a vision model to find a line that literally reads "Signature:" beside it. A text-only design carries the opposite weakness, because it would simply fail on a scanned or hand-drawn page and leave you dragging boxes by hand. The split neatly sidesteps both failure modes. So what does this mean for you in practice? You never have to know which path ran, because you upload a contract and the fields appear. A straightforward NDA gets the fast lane, a scanned and hand-drawn page gets the careful lane, and either way the work finishes before you reach the end of the first paragraph. That outcome is the entire purpose of disciplined signature detection engineering, because the machinery stays hidden and you see one smooth result, contract after contract. The design quietly keeps costs low too, which is part of why the price can stay low. Every field gets placed, and you spend your time signing instead of dragging boxes by hand.