《兩份波蘭官方文件，教我點睇一間外國細供應商》Two Polish Official Documents Taught Me How to Read a Small Overseas Supplier

[Zheng Ge's Take] Column: Zheng Ge's blog commentary | Date: 2026-10-27

Last week someone put two PDFs in front of me, both in Polish. One was headed Komisja Oceny, the review committee report; the other Certyfikat Ukończenia Projektu, the project completion certificate. On the first page was a company name I had never heard: Vistula Data Systems Sp. z o.o.

My first reaction was not "is this company any good". I asked myself a different question: if all I have is public documents, how much can I actually see?

So this is not a verdict on a company. It is how I read a small overseas supplier from public documents — Vistula Data Systems is simply the specimen I practised on. If you are checking a small firm in Vietnam, India or Mexico, the method is the same.

To avoid singling out a real company, the company names, institution names and some details in this article have been altered and do not correspond to any existing business. The technical judgement and methodology are real.

1. The first thing I check is not the content — it is whether it can be verified

Two documents, two different projects, two different things.

The first is a review committee report (Komisja Oceny), reference A-R-04, revised 13 May 2025. What it records is not an acceptance; it is an extension request: project code VDS-2, for an "Urządzenie do łagodzenia ataków DDoS", a DDoS mitigation appliance, and the party carrying it is the same Vistula Data Systems Sp. z o.o. The project started on 19 December 2022, ran to a planned 24 months on a budget of PLN 490,632. By April 2025 the company had applied for six more months, to 19 December 2025. Three external reviewers scored it 27/30, 24/30 and 21/30, and all three agreed to the extension.

The second is a project completion certificate (Certyfikat Ukończenia Projektu), issued by a technology park in southern Poland on 13 January 2025. It certifies something else: project 75562, "development of AI-based firewall software", started 21 December 2021, completed 15 November 2024, with an official approval number. The project finished and the state acknowledged it.

One records an extension, the other a completion. On the surface they look like they are saying opposite things — hold that thought; in section 2 I will explain why the two sit together perfectly well.

But the point I care about is a third thing, the QR code at the foot of the page: it leads to a verification mechanism you can use to check whether the document is genuine.

Many Polish technopark documents come with a lookup service. The photocopy in your hand can be checked against the issuing body's own site.

That is the first gate I put any foreign document through, and the most important one: not what it says, but whether it can be checked.

A document that will not resolve is barely different from no document at all. A document that resolves on the issuer's own site proves at least one thing: the issuing body exists and is willing to stand behind the paper. That difference matters far more than how handsome the document looks.

2. An extension is not a failure: how to read a review report

Most people see the word "extension" and quietly mark the company down. I do not read it that way.

The reason given in the report is specific, not boilerplate:

Integrating the AI algorithms into the eBPF XDP environment required more analysis and development work than expected. Adapting the algorithms to an eBPF XDP environment running at kernel level brought deep optimisation requirements; the algorithm has to be both low-latency and high-accuracy while using system resources efficiently, and the existing architecture needed to be redesigned.

There is information in that paragraph. It tells me the team is working on something genuinely hard, and that the wall they hit was a technical wall, not a management one.

More informative still is the process itself. An extension is not a letter a company writes to itself: a report has to be filed, three external reviewers score it separately, and all three have to agree before the clock moves.

So an approved extension report does not prove "this company could not deliver". It proves "this project was supervised, and the supervisors were outside experts". That is the product of an institution, not of a press release.

And I have to be equally clear about the other side: this document proves nothing at all about whether the product sells. Not one line of it.

3. The technical core: where eBPF and XDP actually bite

Two words in the extension request carry the weight of the whole thing: eBPF and XDP.

XDP (eXpress Data Path) is a high-performance data path inside the Linux kernel. When a network card receives a packet, the normal route runs the whole kernel network stack before your application ever sees it; XDP intercepts the packet before the stack, at the driver layer, and decides right there whether to keep it or drop it.

eBPF is a mechanism for running sandboxed programs safely inside the kernel. You write a small program, the kernel verifies it, and it runs attached at the XDP hook.

Put together, they let you filter and drop packets at the network card with very little overhead. For DDoS that is the ideal battlefield — the earlier the scrubbing happens, the less likely the system is to collapse under a flood.

But that is the theory. In practice there are three hard constraints.

First, it cannot be slow. An XDP program's budget is measured in nanoseconds per packet. Run a respectable model and ten thousand more packets have arrived before you finish one.

Second, it cannot be big. The eBPF virtual machine has an instruction limit and a 512-byte stack. Five hundred and twelve bytes. A real neural network does not fit in that; it is not close.

Third, it cannot crash. A bug in kernel-space code does not return an error, it panics the machine or takes the network down. In production that is not a bug, it is an outage.

So no architecture that actually ships puts the whole model in the kernel. What works is a split: lightweight feature extraction and a fast verdict on the kernel side, the full model for training and complex judgement on the user side.

Read "the existing architecture needed to be redesigned" at engineering level and it means work along exactly that boundary: which features get computed inside XDP, how far the model can be compressed, how much accuracy you are willing to lose, and what a false positive on legitimate traffic costs you.

There is no shortcut in this kind of engineering; it is ground out by measurement. Which is why, when I read "more work than expected", I do not hear an excuse. I hear an accurate sentence.

4. Beyond the documents: the public facts I found (without judging them)

The documents describe projects; they do not describe a company. So I did another round of reading. Below is what I found that can be stated publicly. I list it; I do not score it.

Every line above is copied as fact. I use none of it to reach a judgement.

Which needs saying plainly: how many people a company employs, how much it raised, where it is registered — none of that means anything on its own. A team of two to ten can own a very profitable niche, or burn money every month on a project. US$167,000 is one kind of ammunition for a hardware R&D shop and quite another for a pure software shop. The same number weighs differently depending on the business model underneath it.

So there is no "what is commendable" and no "what to be wary of" in this section. Those two hats belong to whoever is holding the financials and the customer data.

5. How documents like these get produced: Poland's technopark system

Both documents run through the same institution: the technology park in southern Poland.

Parks of this kind have a few decades of history in Poland and usually work alongside a university or a research institute. The park offers an incubator, mentoring, laboratories, R&D funding matchmaking, intellectual property advice, and tax relief.

The basis is Poland's technopark and special economic zone system: R&D carried out inside a zone can qualify for tax relief. The exact rates and conditions depend on the rules in force that year, and they differ by park and by activity. That is why a fair number of small Polish software firms choose to register inside one — the tax difference is large.

But tax relief is only one side. The other side is process management: project approval, interim review, extension review, completion audit, each stage with external reviewers. The 27/30, 24/30 and 21/30 in that report are a product of this system.

Understand that layer and you understand why these documents are worth reading: they are not marketing the company wrote about itself; they are the by-product of an administrative process with outside experts, issuing numbers, and a verification mechanism.

One line has to be drawn very clearly, though:

Government backing means "a funded R&D project was completed compliantly and documented". That is not the same sentence as "the product succeeded commercially".

A Certyfikat Ukończenia Projektu can prove the project finished, that an official approval number exists, that acceptance was passed. It cannot prove that anyone bought, that anyone renewed, that anyone will pay for the same class of product. That gap is one no government document can close.

6. What I always ask about a small foreign company

I am not going to end with a verdict on Vistula Data Systems — the material I have cannot support one. What I want to leave behind is a checklist.

Whether you are looking at a small supplier in Poland, Vietnam, Mexico or Romania, these are the four things I will always ask for.

One: the last two years of financial statements, or revenue evidence. Not the estimate on a third-party platform — the company's own numbers, signed by an accountant. A small firm may not have an audit, but it should have bank records or a tax filing.

Two: original certification documents. Not a screenshot from the company's own website. An ISO 27001 certificate has a number, an issuing body and an expiry date, and it can be looked up on the issuing body's register. A screenshot is the easiest thing in the world to produce, which is exactly why it is worth the least.

Three: customer cases, or a POC report. Not a wall of customer logos — a document that states the scenario, the volume, and the result. A POC report is best, because it was produced for you.

Four: third-party performance testing. Especially for hardware and network products: throughput, false-positive rate, and the conditions under which they were measured. Numbers a vendor states about itself do not count; you need the test method and the environment.

What the four have in common: every one of them can be checked. Same principle as the verification mechanism in section 1 — when I open a document, the first thing I look at is not how impressive it reads, but whether it resolves.

So back to the opening question: how much can public documents tell you about a small foreign company?

The answer is that you can see the institutional facts — whether it is properly registered, whether it has run a supervised project, whether it passed external review, whether the paperwork can be verified. Those are hard, and they are checkable.

What you cannot see are the market facts — whether anyone buys, whether they buy again, whether the price holds. None of that appears in any government document.

And that seam is where I keep my eyes: the distance between "compliantly completed a funded R&D project" and "the product sells". Some companies cross it in a year, some take ten, some turn off halfway. Documents will not help you there — only numbers and customers will.

Two Polish documents taught me not the inside story of one company, but where a particular line falls. That line is useful in whichever country you happen to be checking.

This article is based only on public documents and web research. Financial and customer data have not been independently verified, and nothing said here about any company is investment or procurement advice.