Houser & Houser works with several companies to improve their operational and business processes. For two of them, the Catenara Association and ACI, it produces recurring reports on public procurement in Catalonia: which technical-service contracts were awarded, which tenders were published, and how the member firms fared. We built a platform that produces those reports, keeps the member firms informed of new opportunities, and delivers the results. Claude interprets unstructured documents; deterministic code verifies everything Claude returns; and a person answers only what neither can prove.
The challenge
Manual effort
Each quarter began with a spreadsheet from a paid data provider, listing the tenders three public bodies had awarded (Infraestructures de la Generalitat, BIMSA and the Agència Catalana de l'Aigua), with a link to each one. For every row the process owner followed the link to the public procurement portal, looked through the tender's pages for the technical committee's valuation report, opened a second PDF embedded inside it, read the economic figures off a table, computed the indicators by hand, classified the tender, decided whether it belonged in the report, and finally assembled a 44-page report in Catalan. Between 110 and 160 tenders survive that filter each quarter.
Her work did not stop there. A second provider's export fed a half-yearly report on published tenders, built by hand in the same way. Every weekday, a commercial email of newly published tenders was read, filtered, stripped of the provider's branding and forwarded to the member firms by hand.
Unstructured information
The documents have no consistent name or location. Each public body publishes them differently, and the key table often sits in a PDF attached inside another PDF. Some information exists as structured data; the rest exists only in the text of a document. Tenders published by Spanish state bodies live on a different platform, in a different language.
Reliability
The reports are published and nobody re-checks their figures, so a plausible but wrong value is the worst possible outcome. And the most common error is exactly that: the discount has to be computed on the biddable part of the budget only, not the whole budget. Computed the obvious way, it gives a figure that looks right and is wrong. The provider's own discount column makes that mistake.
Building on the owner's own work
The provider's files were never the answer, but they were the starting point, and they gave us two things to build and test against.
First, the owner's worked copies of them: six quarters and 835 tenders where she had added her figures, her classifications and her decisions on what to include, by hand. The inclusion rules, the service-type lookup and the classification were built from those and are measured against them, trained on 2025 and tested blind on 2026.
Second, the provider's lists themselves, which we ran beside the platform's own discovery quarter after quarter, to prove the platform finds the same tenders. The platform no longer depends on those files. They run beside it for one more month, as a final evaluation, before the subscription is cancelled.
The solution: one platform, five products
1. The quarterly awards report
The core of the platform, and the one that needs the most verification.
- Discovery. Every morning, the platform reads the Generalitat's open-data publication of the procurement portal and records each new award by the three bodies. From there, each tender is followed into the portal's own API for its structured details and to the published documents for what exists only in text.
- The inclusion gate. Named, written rules read the procedure, contract type, framework flag, publication phase and title, and decide whether a tender belongs in the report. Each rule states its reason and who decided it, and the rules page is generated from the code the gate runs, so the two cannot disagree. When no rule applies, the gate does not guess: the tender is referred to a person. The asymmetry is deliberate. A tender wrongly kept is a line a reader can question; a tender wrongly dropped leaves no trace.
- Finding the document. Through the portal's API, code follows each body's own route to the valuation report, downloads it and extracts the table embedded inside. This is deterministic, and cached.
- Reading. Claude reads the table once: the split between fixed and biddable budget, the published mean discount and deviation, and the full bid table, one row per company. Every value comes with the verbatim quote it was read from.
- Proving the reading. Code checks Claude's output before it can be stored:
- each quote must exist, letter for letter, in the PDF's text;
- the arithmetic must close: fixed + biddable = budget; fixed + winning bid = awarded amount;
- the table's published mean and deviation are recomputed from the extracted bids and must match, so the document checks the extraction;
- where the platform publishes the same figure by another route, the budget, awarded amount and bidder count must agree.
- Classification. The service type is a lookup on the tender's code prefix, with no model involved. Whether the work is civil engineering or a building cannot be looked up, so Claude reads the description and answers with a confidence. Below the threshold the field is left empty and the tender is referred.
- Matching the winner. The top score in the valuation table is not always the winner, so the winner is matched by name and amount against the awardee the platform publishes. The winner is then checked against the association's member list, which holds join and leave dates, so a firm is never credited with awards from before it joined.
- The report. The Catalan report is generated from verified rows only, with an annex listing every tender that was excluded or referred and the reason. A referred tender does not print until a person resolves it. Claude drafts the written assessment from the quarter's own figures and hands it to the owner to edit; it is never published on its own.
2. The report on published tenders
Catenara's half-yearly Informe de licitació and the first half of ACI's quarterly report count published tenders, not awarded ones, and across every public body in Catalonia rather than three. The platform builds them from two public sources: the Generalitat's open data for Catalan bodies, and the Spanish state procurement platform (PLACSP) for state bodies such as ADIF, Aena or the port authority, which the Catalan data does not carry.
Because the population is every public tender in Catalonia, the rules here are an allow-list in both Catalan and Spanish: a tender enters only by matching one of the service families the association reports. The verification problem is also different. Every figure is a sum over hundreds of tenders, so leaving a doubtful tender out is not neutral; it silently shrinks a total.
So these reports print their own residual: tenders the rules could not classify appear in an explicit No classificat column, with their euros and their count, and the reader sees how much the system did not know. Claude drafts the written assessment, as in the awards report.
Doubts are answered by rule, not tender by tender: one answer about a rule, a public body or a contract category settles every tender it covers, including tenders published later. Thousands of open questions reduce to a few dozen.
3. Oportunitats: open tenders for the member firms
Every morning, after discovery, the platform reads the tenders still open for bidding by the three bodies and applies the same criteria as the report, as a suggestion with the rule that gave it. A person confirms or discards each one, singly or by group, and the platform composes the email in the association's own look and sends it to the member firms' contacts who subscribed. A tender comes back only when something about it changes, such as a deadline extended or a budget revised, and the change is named. Every send is logged with the email exactly as it went out.
4. Reports for each member firm, and for the market
Because the platform stores every bid from every company, not only the winners, it can answer questions the quarterly report could not:
- The firm's own report. For any member firm and quarter: where it bid, its wins and win rate, its discount against the market's, and the tenders in its own specialities where it did not bid. Built because members said the general report "says everything about everyone"; it is currently a proposal on real data, for the association to shape before it is sent.
- The thermometer. A report on how public tendering is moving over time: how many tenders, what average amounts, deliberately about the market rather than about any firm.
5. Delivery and operation
- Sharing and sending. A report can be shared by password-protected link with an expiry, for members who will never have an account, or sent from the platform with a preview of exactly what goes out. The platform counts who opened it. Marking a report as delivered pins its headline figures, so a later correction cannot silently change what a reader was sent.
- Running without a terminal. Discovery runs on its own every morning. The owner starts the paid processing of a quarter from a button, with a budget ceiling and a confirmation, and the screen reports what the run produced.
- Several clients, one platform. Catenara and ACI read the same public facts but keep their own criteria, their own products and their own decisions. What an association buys is a row of configuration, not a new deployment. Each association can use its own Claude API key, so its usage is billed to it.
Where Claude fits
Claude does three jobs across the whole platform:
- it reads what exists only inside documents, the valuation tables;
- it judges the one classification no field or rule can answer, civil engineering or building;
- it drafts the written assessment of each report from the period's own figures, for a person to edit.
Everything else is code: finding tenders, the inclusion rules, locating documents, computing indicators, matching winners and members, the alert feed, delivery. For the reading job, every value is proven against the document before it is stored. For the judging job there is nothing to prove against, so the guard is a confidence threshold, and a doubt is referred rather than guessed. For the drafting job, a person always edits before anything is published.
Claude interprets, code verifies, and people resolve what neither can prove.
The result
Reliable by design
A value reaches a report only if the code has proven it; everything else becomes a question with its reason written out. Where a report is a sum, it declares what it could not classify instead of quietly leaving it out. We measure the system against 835 tenders the owner worked by hand.
Human judgement where it matters
Instead of finding, reading and checking every tender, the owner answers the questions the system could not settle, on one screen, with the document, the figures and the reason in front of her. We estimate that one of those cases takes a couple of minutes, against roughly twenty to rediscover a tender from scratch.
Quality at scale
A full quarter is processed in under an hour for a few euros of API usage, every tender goes through the same rules and checks, and the platform no longer depends on paid data files. As a side effect, every processed quarter becomes a market dataset: every bid from every company in every tender, the raw material for the firm reports and the thermometer, and for what comes next.
Managing this information on a daily basis and producing reports consumed significant resources across our organization, both interms of time and employee effort. In addition, such a manual approach created a constant risk of human error, often difficult to detect and correct.
We were convinced that AI held the answer to this, but we could not find a solution that combined the level of personalization we required. zenital's solution met every equirement: more accurate, clearer, and fully customizable information, with a great reduction in manual and repetitive work".
Alejandro Casero, Houser & Houser
Houser & Houser works with several companies to improve their operational and business processes. For two of them, the Catenara Association and ACI, it produces recurring reports on public procurement in Catalonia: which technical-service contracts were awarded, which tenders were published, and how the member firms fared. We built a platform that produces those reports, keeps the member firms informed of new opportunities, and delivers the results. Claude interprets unstructured documents; deterministic code verifies everything Claude returns; and a person answers only what neither can prove.
The challenge
Manual effort
Each quarter began with a spreadsheet from a paid data provider, listing the tenders three public bodies had awarded (Infraestructures de la Generalitat, BIMSA and the Agència Catalana de l'Aigua), with a link to each one. For every row the process owner followed the link to the public procurement portal, looked through the tender's pages for the technical committee's valuation report, opened a second PDF embedded inside it, read the economic figures off a table, computed the indicators by hand, classified the tender, decided whether it belonged in the report, and finally assembled a 44-page report in Catalan. Between 110 and 160 tenders survive that filter each quarter.
Her work did not stop there. A second provider's export fed a half-yearly report on published tenders, built by hand in the same way. Every weekday, a commercial email of newly published tenders was read, filtered, stripped of the provider's branding and forwarded to the member firms by hand.
Unstructured information
The documents have no consistent name or location. Each public body publishes them differently, and the key table often sits in a PDF attached inside another PDF. Some information exists as structured data; the rest exists only in the text of a document. Tenders published by Spanish state bodies live on a different platform, in a different language.
Reliability
The reports are published and nobody re-checks their figures, so a plausible but wrong value is the worst possible outcome. And the most common error is exactly that: the discount has to be computed on the biddable part of the budget only, not the whole budget. Computed the obvious way, it gives a figure that looks right and is wrong. The provider's own discount column makes that mistake.
Building on the owner's own work
The provider's files were never the answer, but they were the starting point, and they gave us two things to build and test against.
First, the owner's worked copies of them: six quarters and 835 tenders where she had added her figures, her classifications and her decisions on what to include, by hand. The inclusion rules, the service-type lookup and the classification were built from those and are measured against them, trained on 2025 and tested blind on 2026.
Second, the provider's lists themselves, which we ran beside the platform's own discovery quarter after quarter, to prove the platform finds the same tenders. The platform no longer depends on those files. They run beside it for one more month, as a final evaluation, before the subscription is cancelled.
The solution: one platform, five products
1. The quarterly awards report
The core of the platform, and the one that needs the most verification.
- Discovery. Every morning, the platform reads the Generalitat's open-data publication of the procurement portal and records each new award by the three bodies. From there, each tender is followed into the portal's own API for its structured details and to the published documents for what exists only in text.
- The inclusion gate. Named, written rules read the procedure, contract type, framework flag, publication phase and title, and decide whether a tender belongs in the report. Each rule states its reason and who decided it, and the rules page is generated from the code the gate runs, so the two cannot disagree. When no rule applies, the gate does not guess: the tender is referred to a person. The asymmetry is deliberate. A tender wrongly kept is a line a reader can question; a tender wrongly dropped leaves no trace.
- Finding the document. Through the portal's API, code follows each body's own route to the valuation report, downloads it and extracts the table embedded inside. This is deterministic, and cached.
- Reading. Claude reads the table once: the split between fixed and biddable budget, the published mean discount and deviation, and the full bid table, one row per company. Every value comes with the verbatim quote it was read from.
- Proving the reading. Code checks Claude's output before it can be stored:
- each quote must exist, letter for letter, in the PDF's text;
- the arithmetic must close: fixed + biddable = budget; fixed + winning bid = awarded amount;
- the table's published mean and deviation are recomputed from the extracted bids and must match, so the document checks the extraction;
- where the platform publishes the same figure by another route, the budget, awarded amount and bidder count must agree.
- Classification. The service type is a lookup on the tender's code prefix, with no model involved. Whether the work is civil engineering or a building cannot be looked up, so Claude reads the description and answers with a confidence. Below the threshold the field is left empty and the tender is referred.
- Matching the winner. The top score in the valuation table is not always the winner, so the winner is matched by name and amount against the awardee the platform publishes. The winner is then checked against the association's member list, which holds join and leave dates, so a firm is never credited with awards from before it joined.
- The report. The Catalan report is generated from verified rows only, with an annex listing every tender that was excluded or referred and the reason. A referred tender does not print until a person resolves it. Claude drafts the written assessment from the quarter's own figures and hands it to the owner to edit; it is never published on its own.
2. The report on published tenders
Catenara's half-yearly Informe de licitació and the first half of ACI's quarterly report count published tenders, not awarded ones, and across every public body in Catalonia rather than three. The platform builds them from two public sources: the Generalitat's open data for Catalan bodies, and the Spanish state procurement platform (PLACSP) for state bodies such as ADIF, Aena or the port authority, which the Catalan data does not carry.
Because the population is every public tender in Catalonia, the rules here are an allow-list in both Catalan and Spanish: a tender enters only by matching one of the service families the association reports. The verification problem is also different. Every figure is a sum over hundreds of tenders, so leaving a doubtful tender out is not neutral; it silently shrinks a total.
So these reports print their own residual: tenders the rules could not classify appear in an explicit No classificat column, with their euros and their count, and the reader sees how much the system did not know. Claude drafts the written assessment, as in the awards report.
Doubts are answered by rule, not tender by tender: one answer about a rule, a public body or a contract category settles every tender it covers, including tenders published later. Thousands of open questions reduce to a few dozen.
3. Oportunitats: open tenders for the member firms
Every morning, after discovery, the platform reads the tenders still open for bidding by the three bodies and applies the same criteria as the report, as a suggestion with the rule that gave it. A person confirms or discards each one, singly or by group, and the platform composes the email in the association's own look and sends it to the member firms' contacts who subscribed. A tender comes back only when something about it changes, such as a deadline extended or a budget revised, and the change is named. Every send is logged with the email exactly as it went out.
4. Reports for each member firm, and for the market
Because the platform stores every bid from every company, not only the winners, it can answer questions the quarterly report could not:
- The firm's own report. For any member firm and quarter: where it bid, its wins and win rate, its discount against the market's, and the tenders in its own specialities where it did not bid. Built because members said the general report "says everything about everyone"; it is currently a proposal on real data, for the association to shape before it is sent.
- The thermometer. A report on how public tendering is moving over time: how many tenders, what average amounts, deliberately about the market rather than about any firm.
5. Delivery and operation
- Sharing and sending. A report can be shared by password-protected link with an expiry, for members who will never have an account, or sent from the platform with a preview of exactly what goes out. The platform counts who opened it. Marking a report as delivered pins its headline figures, so a later correction cannot silently change what a reader was sent.
- Running without a terminal. Discovery runs on its own every morning. The owner starts the paid processing of a quarter from a button, with a budget ceiling and a confirmation, and the screen reports what the run produced.
- Several clients, one platform. Catenara and ACI read the same public facts but keep their own criteria, their own products and their own decisions. What an association buys is a row of configuration, not a new deployment. Each association can use its own Claude API key, so its usage is billed to it.
How to change an entire data strategy
I imagine 8wires as that sincere and honest partner that takes you out of all that noise and helps you focus on what is important, no matter how unsexy it may be, to achieve a great long-term goal.
The one who accompanies you through the hard times and helps you through the tough decisions, knowing that there is no easy road. The one who gives you the push or the tools so that you climb and be yourself the one who reaches the summits you propose in a healthy, sustainable and energetic way. And above all, the one who steps aside when he knows that he is not helping you or that he will not be able to give you what you need.
I don't know if it is helpful, but somehow I saw on the web a visual explanation of the problem in the data/technology world (I don't know if with this metaphor) before showing how it is to work with us and finally, another visual explanation of the result.

Like a bridge over troubled waters
I imagine 8wires as that sincere and honest partner that takes you out of all that noise and helps you focus on what is important, no matter how unsexy it may be, to achieve a great long-term goal.
The one who accompanies you through the hard times and helps you through the tough decisions, knowing that there is no easy road. The one who gives you the push or the tools so that you climb and be yourself the one who reaches the summits you propose in a healthy, sustainable and energetic way.
Houser & Houser works with several companies to improve their operational and business processes. For two of them, the Catenara Association and ACI, it produces recurring reports on public procurement in Catalonia: which technical-service contracts were awarded, which tenders were published, and how the member firms fared. We built a platform that produces those reports, keeps the member firms informed of new opportunities, and delivers the results. Claude interprets unstructured documents; deterministic code verifies everything Claude returns; and a person answers only what neither can prove.
The challenge
Manual effort
Each quarter began with a spreadsheet from a paid data provider, listing the tenders three public bodies had awarded (Infraestructures de la Generalitat, BIMSA and the Agència Catalana de l'Aigua), with a link to each one. For every row the process owner followed the link to the public procurement portal, looked through the tender's pages for the technical committee's valuation report, opened a second PDF embedded inside it, read the economic figures off a table, computed the indicators by hand, classified the tender, decided whether it belonged in the report, and finally assembled a 44-page report in Catalan. Between 110 and 160 tenders survive that filter each quarter.
Her work did not stop there. A second provider's export fed a half-yearly report on published tenders, built by hand in the same way. Every weekday, a commercial email of newly published tenders was read, filtered, stripped of the provider's branding and forwarded to the member firms by hand.
Unstructured information
The documents have no consistent name or location. Each public body publishes them differently, and the key table often sits in a PDF attached inside another PDF. Some information exists as structured data; the rest exists only in the text of a document. Tenders published by Spanish state bodies live on a different platform, in a different language.
Reliability
The reports are published and nobody re-checks their figures, so a plausible but wrong value is the worst possible outcome. And the most common error is exactly that: the discount has to be computed on the biddable part of the budget only, not the whole budget. Computed the obvious way, it gives a figure that looks right and is wrong. The provider's own discount column makes that mistake.
Building on the owner's own work
The provider's files were never the answer, but they were the starting point, and they gave us two things to build and test against.
First, the owner's worked copies of them: six quarters and 835 tenders where she had added her figures, her classifications and her decisions on what to include, by hand. The inclusion rules, the service-type lookup and the classification were built from those and are measured against them, trained on 2025 and tested blind on 2026.
Second, the provider's lists themselves, which we ran beside the platform's own discovery quarter after quarter, to prove the platform finds the same tenders. The platform no longer depends on those files. They run beside it for one more month, as a final evaluation, before the subscription is cancelled.
The solution: one platform, five products
1. The quarterly awards report
The core of the platform, and the one that needs the most verification.
- Discovery. Every morning, the platform reads the Generalitat's open-data publication of the procurement portal and records each new award by the three bodies. From there, each tender is followed into the portal's own API for its structured details and to the published documents for what exists only in text.
- The inclusion gate. Named, written rules read the procedure, contract type, framework flag, publication phase and title, and decide whether a tender belongs in the report. Each rule states its reason and who decided it, and the rules page is generated from the code the gate runs, so the two cannot disagree. When no rule applies, the gate does not guess: the tender is referred to a person. The asymmetry is deliberate. A tender wrongly kept is a line a reader can question; a tender wrongly dropped leaves no trace.
- Finding the document. Through the portal's API, code follows each body's own route to the valuation report, downloads it and extracts the table embedded inside. This is deterministic, and cached.
- Reading. Claude reads the table once: the split between fixed and biddable budget, the published mean discount and deviation, and the full bid table, one row per company. Every value comes with the verbatim quote it was read from.
- Proving the reading. Code checks Claude's output before it can be stored:
- each quote must exist, letter for letter, in the PDF's text;
- the arithmetic must close: fixed + biddable = budget; fixed + winning bid = awarded amount;
- the table's published mean and deviation are recomputed from the extracted bids and must match, so the document checks the extraction;
- where the platform publishes the same figure by another route, the budget, awarded amount and bidder count must agree.
- Classification. The service type is a lookup on the tender's code prefix, with no model involved. Whether the work is civil engineering or a building cannot be looked up, so Claude reads the description and answers with a confidence. Below the threshold the field is left empty and the tender is referred.
- Matching the winner. The top score in the valuation table is not always the winner, so the winner is matched by name and amount against the awardee the platform publishes. The winner is then checked against the association's member list, which holds join and leave dates, so a firm is never credited with awards from before it joined.
- The report. The Catalan report is generated from verified rows only, with an annex listing every tender that was excluded or referred and the reason. A referred tender does not print until a person resolves it. Claude drafts the written assessment from the quarter's own figures and hands it to the owner to edit; it is never published on its own.
2. The report on published tenders
Catenara's half-yearly Informe de licitació and the first half of ACI's quarterly report count published tenders, not awarded ones, and across every public body in Catalonia rather than three. The platform builds them from two public sources: the Generalitat's open data for Catalan bodies, and the Spanish state procurement platform (PLACSP) for state bodies such as ADIF, Aena or the port authority, which the Catalan data does not carry.
Because the population is every public tender in Catalonia, the rules here are an allow-list in both Catalan and Spanish: a tender enters only by matching one of the service families the association reports. The verification problem is also different. Every figure is a sum over hundreds of tenders, so leaving a doubtful tender out is not neutral; it silently shrinks a total.
So these reports print their own residual: tenders the rules could not classify appear in an explicit No classificat column, with their euros and their count, and the reader sees how much the system did not know. Claude drafts the written assessment, as in the awards report.
Doubts are answered by rule, not tender by tender: one answer about a rule, a public body or a contract category settles every tender it covers, including tenders published later. Thousands of open questions reduce to a few dozen.
3. Oportunitats: open tenders for the member firms
Every morning, after discovery, the platform reads the tenders still open for bidding by the three bodies and applies the same criteria as the report, as a suggestion with the rule that gave it. A person confirms or discards each one, singly or by group, and the platform composes the email in the association's own look and sends it to the member firms' contacts who subscribed. A tender comes back only when something about it changes, such as a deadline extended or a budget revised, and the change is named. Every send is logged with the email exactly as it went out.
4. Reports for each member firm, and for the market
Because the platform stores every bid from every company, not only the winners, it can answer questions the quarterly report could not:
- The firm's own report. For any member firm and quarter: where it bid, its wins and win rate, its discount against the market's, and the tenders in its own specialities where it did not bid. Built because members said the general report "says everything about everyone"; it is currently a proposal on real data, for the association to shape before it is sent.
- The thermometer. A report on how public tendering is moving over time: how many tenders, what average amounts, deliberately about the market rather than about any firm.
5. Delivery and operation
- Sharing and sending. A report can be shared by password-protected link with an expiry, for members who will never have an account, or sent from the platform with a preview of exactly what goes out. The platform counts who opened it. Marking a report as delivered pins its headline figures, so a later correction cannot silently change what a reader was sent.
- Running without a terminal. Discovery runs on its own every morning. The owner starts the paid processing of a quarter from a button, with a budget ceiling and a confirmation, and the screen reports what the run produced.
- Several clients, one platform. Catenara and ACI read the same public facts but keep their own criteria, their own products and their own decisions. What an association buys is a row of configuration, not a new deployment. Each association can use its own Claude API key, so its usage is billed to it.
How to change an entire data strategy
I imagine 8wires as that sincere and honest partner that takes you out of all that noise and helps you focus on what is important, no matter how unsexy it may be, to achieve a great long-term goal.
The one who accompanies you through the hard times and helps you through the tough decisions, knowing that there is no easy road. The one who gives you the push or the tools so that you climb and be yourself the one who reaches the summits you propose in a healthy, sustainable and energetic way. And above all, the one who steps aside when he knows that he is not helping you or that he will not be able to give you what you need.
I don't know if it is helpful, but somehow I saw on the web a visual explanation of the problem in the data/technology world (I don't know if with this metaphor) before showing how it is to work with us and finally, another visual explanation of the result.

Like a bridge over troubled waters
I imagine 8wires as that sincere and honest partner that takes you out of all that noise and helps you focus on what is important, no matter how unsexy it may be, to achieve a great long-term goal.
The one who accompanies you through the hard times and helps you through the tough decisions, knowing that there is no easy road. The one who gives you the push or the tools so that you climb and be yourself the one who reaches the summits you propose in a healthy, sustainable and energetic way.

.png)