Extend Evidence-Based Requirement Extraction from Grant PDFs in an Existing Python System

We are looking for an experienced Python / document intelligence engineer to extend an existing production-oriented system that extracts structured requirements from public funding and grant documents.

This is not a greenfield project and we do not want the existing architecture rewritten.

We already have a working Python codebase with:

PDF text extraction;
page-addressable document blocks;
structured data models;
typed requirement objects;
evidence/provenance tracking;
deterministic validation;
automated tests;
integration with an existing decision-analysis engine;
several requirement families already working on real documents.

Your task is to increase the semantic coverage of the existing requirement extraction layer.

The system currently extracts a limited number of requirement types correctly. We want to extend it so that it can reliably identify the most important eligibility and application conditions contained in real funding documents.

Examples of requirement families we want to support

Priority areas include:

eligible applicant / organization types;
geographic eligibility;
required target groups;
required or permitted activities;
project duration and implementation period;
minimum or maximum funding amounts;
budget restrictions;
own contribution / co-financing requirements;
application deadlines;
number of applications allowed;
required documents and attachments;
required experience;
staff or qualification requirements;
institutional requirements;
participation fees or similar restrictions.

The exact implementation scope and priority list will be agreed before development. We are not asking for universal support for every possible document or rule.

The goal is a strong, bounded v0.1 implementation covering the most valuable requirement families.

Evidence-first approach

A requirement must never be generated as an unsupported AI assumption.

Every extracted requirement must preserve evidence such as:

source document identity/hash;
page number;
exact supporting passage or evidence quote;
structured requirement type;
extracted value;
extractor/parser version or identifier;
validation/status information where applicable.

If the document is ambiguous, contradictory, incomplete or unsupported by the current extractor, the system must remain fail-closed.

The correct result is:

UNKNOWN / unresolved / human review required

rather than guessing.

Important architectural constraints

You will work inside an existing Python repository.

Please do not redesign the system.

In particular:

do not replace the existing data models with your own architecture;
do not introduce a new framework unless explicitly approved;
do not move the business logic into n8n;
do not build a new frontend;
do not redesign the database;
do not change unrelated parts of the system;
do not silently infer requirements that are not supported by source evidence;
do not treat LLM output as verified evidence by itself.

You will be given the relevant existing models, interfaces, tests, examples and real documents.

The implementation should extend the existing contracts rather than bypass them.

Expected workflow

Conceptually:

Official PDF / document
→ page-addressable extraction
→ bounded requirement extraction
→ evidence-backed candidates
→ validation
→ typed requirements
→ existing decision engine

LLMs may be used where appropriate, but the final output must remain structured, testable and evidence-backed.

We are open to a hybrid approach using:

deterministic parsing;
rules/regex where appropriate;
LLM-assisted extraction;
structured-output models;
validation passes.

The architecture must prioritize correctness, traceability and fail-closed behavior over extracting something at all costs.

Documents and language

The primary source documents are in Polish.

Native Polish fluency is helpful but not mandatory if you are comfortable working with Polish-language documents using modern LLMs, translation tools and provided test cases.

You will receive real examples together with expected outputs / acceptance cases so that correctness does not depend only on your personal interpretation of the language.

Deliverables

We expect:

implementation of the agreed additional requirement families;
integration with the existing Python extraction layer;
deterministic automated tests;
tests using real or representative source documents;
preservation of page-level evidence/provenance;
fail-closed handling of ambiguous or unsupported cases;
a short coverage report describing:
supported requirement families,
unsupported cases,
known ambiguities/limitations;
concise technical documentation;
clean source code ready for independent review.
Definition of Done

The project will be considered complete when:

the agreed requirement families are implemented;
existing functionality continues to work;
automated tests pass;
real test documents produce the expected structured requirements;
every positive requirement has traceable source evidence;
unsupported or ambiguous cases remain UNKNOWN rather than being guessed;
the changes can be reviewed as a bounded addition to the existing codebase.
Out of scope

This project does not include:

building the organization/client intake system;
profiling organizations;
grant matching;
frontend development;
n8n workflow orchestration;
application-writing functionality;
database redesign;
rebuilding the existing platform.
Ideal candidate

We are particularly interested in developers with experience in some combination of:

Python;
document parsing / PDF processing;
LLM structured extraction;
information extraction / NLP;
schema-driven outputs;
data validation;
pytest or similar testing frameworks;
provenance/evidence systems;
production AI pipelines;
working within an existing codebase without unnecessary rewrites.
When applying, please include

Please briefly explain your estimated delivery time;

We are looking for someone who can extend an existing, test-driven document intelligence component while preserving strict evidence and validation guarantees, rather than someone proposing a complete rewrite.