https://www.ambacelar.com Portfolio updates and writing by Adilson Bacelar. en-gb Sun, 05 Apr 2026 00:00:00 GMT https://www.ambacelar.com/blog/are-you-richer-or-just-more-expensive https://www.ambacelar.com/blog/are-you-richer-or-just-more-expensive GDP measures how much money moves through an economy, not how good life actually is for the people living in it. adi@ambacelar.com (Adilson Bacelar) Sun, 05 Apr 2026 00:00:00 GMT https://www.ambacelar.com/blog/building-a-digital-kimbundu-dictionary-in-the-age-of-ai https://www.ambacelar.com/blog/building-a-digital-kimbundu-dictionary-in-the-age-of-ai How I turned a historical scanned Kimbundu–Portuguese dictionary into a structured lexical corpus, and why digital cultural libraries matter more than ever. adi@ambacelar.com (Adilson Bacelar) Tue, 10 Mar 2026 00:00:00 GMT Do not treat the dictionary as a single OCR task. Treat it as a staged corpus-engineering problem. ## The pipeline I built The workflow eventually became a twelve-stage pipeline: from PDF acquisition and page rendering, through column segmentation and OCR capture, into deterministic parsing, chunked extraction, and corpus consolidation, then reconstruction across line, column, page, and chunk boundaries, cleanup into a Portuguese-first lexical dataset, a conservative LLM audit, editorial merge, and finally a publication layer for the website. That architecture now lives explicitly in the project documentation, rather than as tribal knowledge in scripts and terminal history. What mattered most was that every stage stayed **inspectable**. Raw OCR is preserved. Page and column provenance are retained. Cleanup is separated from semantic enrichment. Audit output is advisory, never destructive. Editorial changes are batched and merged explicitly. The corpus is digital, and it is **traceable**. ## Why deterministic parsing mattered Large language models are powerful, but they are not a substitute for structure. The core parsing and reconstruction pipeline had to be deterministic. I did not want the source of truth to shift every time I reran a script. The system needed to produce stable outputs, preserve evidence, and make it obvious where uncertainty remained. So the main workflow stayed deliberately conservative: - raw OCR stayed raw - parsing extracted only what could be supported structurally - reconstruction repaired fused entries before semantic cleanup - cleanup produced a Portuguese-first lexical dataset - LLMs were used later as auditors, not silent editors The most useful role for the model was not "rewrite the dictionary for me." It was: > "Flag suspicious entries, classify likely issues, and suggest where human attention is warranted." That distinction kept the project honest. ## What the system actually produced The end state is a layered corpus with multiple explicit outputs: a cleaned corpus, an audited corpus, an editorial working corpus, a final merged version, a slim public corpus, and a site publication bundle. After editorial recovery, the final merged corpus contains **10,679 entries**, including 376 approved editorial resolutions, 58 entries recovered during editorial work, and 28 dropped false or redundant fragments. On the website side, the current application serves that public corpus in a dictionary-first interface with landing/search, word pages, alphabetical browse, noun-class pages, and multilingual routing. The project is already a usable public resource, not just a research artefact. ## The hardest part was structural recovery Historical dictionaries do not stop cleanly at machine-friendly boundaries. Entries bleed into each other across line wraps. A page heading can leak into lexical content. A cross-reference can look like a new definition. A broken scan can make one entry look like three, or three look like one. Some of the most useful work in the pipeline involved reconstructing entries across line, column, page, and chunk boundaries. This is where the project stopped being "document parsing" and became something closer to **historical corpus reconstruction**. I now think of the project less as a dictionary site and more as the foundation of a digital cultural archive. ## Why this matters in the age of LMs There is a broader reason I care about this work. We are entering a period where more and more people will not search the web in the traditional sense. They will ask language models. They will ask assistants. They will rely on generated summaries, synthetic answers, and systems that compress the world into a handful of probable responses. Those systems will only know what has been made digitally available to them. If a language is poorly digitised, its representation in future AI systems will be thin, distorted, or absent. If a culture's best sources remain trapped in scans, inaccessible archives, or hard-to-parse books, future systems will reflect that absence. The problem is not technical. It is civilisational. A high-quality digital cultural library is infrastructure. It gives learners something trustworthy to build on, researchers something structured to analyse, future tools something real to retrieve, and a community something that preserves voice, memory, and meaning in machine-readable form. I do not want my children, twenty years from now, to inherit a future where their access to Angolan culture is mediated mainly through whatever random scraps Silicon Valley happened to ingest. I want them to have access to real archives, real voices, and materials built with care and proximity to the people and histories involved. ## Why kimbundu.org is only the beginning The dictionary matters, but it is not the endpoint. The broader goal is a genuine **digital Kimbundu cultural library**. That means, over time: - a modernised Portuguese display layer alongside the historical source text - English and French translation layers - grammar resources and noun-class guides - Kimbundu Bible texts and audio - stories, proverbs, songs, and oral materials - linked references between dictionary entries and broader learning resources The website already reflects that direction: the app is intentionally dictionary-first, but clearly positioned as the beginning of a wider language-preservation platform. That pacing is deliberate. A strong archive should be built on a stable foundation. ## What I learned building it ### Good intermediate artefacts are worth the effort Debug images, page-level JSON, chunk summaries, corpus reports, audit summaries, editorial manifests -- all of it felt like overhead at first. It wasn't. It was the reason the project remained debuggable as complexity grew. ### Reviewability is a feature When you work with historical material, being able to explain _why_ a transformation happened matters almost as much as the transformation itself. ### LLMs are best used carefully The most valuable use of language models here was constrained issue detection and conservative audit suggestion, not freeform rewriting. That boundary protected the corpus from becoming a moving target. ### Structure comes before enrichment It is tempting to jump into translation, glossing, or more visible product features. But once the underlying structure is unstable, everything on top of it becomes expensive to trust. ## Where I want to take it next The next phase is about making the corpus more useful without losing fidelity: - modern Portuguese display forms alongside the original dictionary Portuguese - future Kimbundu standardisation support as orthographic guidance becomes clearer - better educational presentation of noun classes and grammar - deeper links between lexical entries and texts, songs, and stories - eventually, richer language tools built on top of a stable, inspectable archive The dictionary was the first hard problem. It will not be the last. ## Final thought The most important result of this project is not that a historical dictionary became searchable. It is that the path from scan to structured cultural resource is now explicit, auditable, and reusable. Preservation is not just about keeping artefacts alive. It is about making them legible to the systems that shape future access to knowledge. And increasingly, those systems are no longer shelves or search engines. They are models. If we want languages like Kimbundu to remain visible in that future, we need to build the libraries now.]]> https://www.ambacelar.com/blog/why-does-everything-suck https://www.ambacelar.com/blog/why-does-everything-suck The Mathematical Reality Behind the "Enshitification" of Everything adi@ambacelar.com (Adilson Bacelar) Wed, 30 Oct 2024 00:00:00 GMT https://www.ambacelar.com/blog/from-monoliths-to-microservices https://www.ambacelar.com/blog/from-monoliths-to-microservices **Navigating the Architectural Maze: From Monoliths to Microservices** adi@ambacelar.com (Adilson Bacelar) Fri, 25 Oct 2024 00:00:00 GMT https://www.ambacelar.com/blog/too-big-to-use-todo https://www.ambacelar.com/blog/too-big-to-use-todo Why Code Annotations Aren't Enough in Large Projects adi@ambacelar.com (Adilson Bacelar) Mon, 30 Sep 2024 00:00:00 GMT https://www.ambacelar.com/blog/between-legacy-and-reality https://www.ambacelar.com/blog/between-legacy-and-reality Do I want children? Or do I need children to justify all my past actions? adi@ambacelar.com (Adilson Bacelar) Mon, 23 Sep 2024 00:00:00 GMT https://www.ambacelar.com/blog/the-dangers-of-ai https://www.ambacelar.com/blog/the-dangers-of-ai Amplifying Political Agendas and Racism on Social Media adi@ambacelar.com (Adilson Bacelar) Wed, 18 Sep 2024 00:00:00 GMT https://www.ambacelar.com/blog/ai-will-not-take-your-tech-job https://www.ambacelar.com/blog/ai-will-not-take-your-tech-job At least, not all of them... adi@ambacelar.com (Adilson Bacelar) Sat, 14 Sep 2024 00:00:00 GMT https://www.ambacelar.com/blog/blockchain-intro https://www.ambacelar.com/blog/blockchain-intro A friend asked me for an intro, so I will share it with you too adi@ambacelar.com (Adilson Bacelar) Tue, 20 Aug 2024 00:00:00 GMT =0.7.3; contract HelloStephanie { // Declares a state variable `message` of type `string`. // State variables are variables whose values are permanently stored in contract storage. The keyword `public` makes variables accessible from outside a contract and creates a function that other contracts or clients can call to access the value. string public message; // Declares a variable for the contract owner, the lack of "public" keyword means that this variable is not accessible from outside the contractr. address owner; TokenCreator creator; // This is the constructor that is run when the smart contract is initialised, it will register the creator and the initial message. constructor(string memory initMessage) { // Accepts a string argument `initMessage` and sets the value into the contract's `message` storage variable. message = initMessage; // sets the value of the address of the smart contract owner, this wallet will have admin permissions over this smart contract (this should be changed when transferring the smart contract) owner = msg.sender; // The token creator should never change, could be used to ensure royalties are gathered when withdrawing any value from the contract. (Yes, smart contracts can hold onto funds) creator = TokenCreator(msg.sender); } //Emitted when update function is called //Smart contract events are a way for your contract to communicate that something happened on the blockchain to your app front-end, which can be 'listening' for certain events and take action when they happen. event UpdatedMessages(string oldStr, string newStr); // A public function that accepts a string argument and updates the `message` storage variable. function changeMessage(string memory newMessage) public { // if you aren't the current owner of this smart contract, you cannot change the value of the message, so we exit early. if (msg.sender != owner) return; string memory oldMsg = message; message = newMessage; emit UpdatedMessages(oldMsg, newMessage); } } ``` But the above would be the source code to create a smart contract that, when deployed would provide a message to anyone that wishes to look at it, for free! But only one account can make changes to them. If you want to see an example of a production level smart contract, let's look at the Bored Ape Yacht Club (BAYC) smart contract: found [here](https://etherscan.io/token/0xbc4ca0eda7647a8ab7c2061c2e118a18a936f13d#code) Clicking that link, will take you directly to the source code for the contract, available for all to see! But that's not the important thing, if you click on the `read contract` tab, you will be able to see all of the `public` variables which are all "immutable" unless you allow them to be updated via another transaction. (It is common practice to enable a way to "freeze" a contract once all the values are finalised, with similar logic to how we checked for the contract owner) e.g. ```js pragma solidity >=0.7.3; contract CheckFrozen { bool public isFrozen; string public message; address owner; TokenCreator creator; constructor(string memory initMessage) { message = initMessage; owner = msg.sender; creator = TokenCreator(msg.sender); } function freezeContract() public { // can only be ran once. Cannot be undone. if (isFrozen == true) return; if (msg.sender != owner) return; isFrozen = true; } function changeMessage(string memory newMessage) public { if (isFrozen == true) return; if (msg.sender != owner) return; string memory oldMsg = message; message = newMessage; } } ``` Take note, that every interaction with a smart contract is a `transaction` and therefore will have a transaction fee! ## Okay, what else is there? I mean, I think that we have covered everything already to get you at the level of the base Web3 developer/project owner. Other topics to look into, considering the project that you are working on: - Real World Events triggering a smart contract - What are the nature of the data that needs to be stored? Do you need Web3 file storage systems? (for things like PDFs?) please take note, that there isn't any _real_ privacy on the blockchain, and if the files are added onto the blockchain, there is no encryption that will endure a concentrated attack attempt for very long. So making careful use of private variables is essential! - [IPFS](https://ipfs.io/) is a distributed file system designed to help store and access data across a peer-to-peer network. IPFS empowers developers to store, timestamp, and secure large files without having to put the data itself on-chain. - [Arweave](https://www.arweave.org/) takes the idea of decentralized file storage further by ensuring the permanence of data. Arweave is building a permaweb, managed by a global community of users and developers who are incentivized to maintain the data storage layer. - [Gaia](https://github.com/stacks-network/gaia) is a decentralized storage platform available to developers building apps on Stacks. The transactional metadata of the apps is stored on the blockchain itself, while user application data is stored in Gaia to ensure that users enjoy high performance and availability. - Security, for the things that you are trying to so, a high level of assurance and security may be essential. Blockchain will only be as good as the people designing it. And once something exists, even if you make a new transaction to update it please, be aware that the prior version that is potentially compromised will forever exist on the blockchain.]]> https://www.ambacelar.com/blog/i-will-not-wear-your-gpt https://www.ambacelar.com/blog/i-will-not-wear-your-gpt I finished work today and jumped on twitter to see a single payment AI wearable "friend"... adi@ambacelar.com (Adilson Bacelar) Wed, 31 Jul 2024 00:00:00 GMT https://www.ambacelar.com/blog/on-data-and-death https://www.ambacelar.com/blog/on-data-and-death What will my grandchildren learn of me if they can not read this? adi@ambacelar.com (Adilson Bacelar) Wed, 31 Jul 2024 00:00:00 GMT https://www.ambacelar.com/blog/career-planning https://www.ambacelar.com/blog/career-planning What do I see in my future right now? adi@ambacelar.com (Adilson Bacelar) Sat, 20 Jul 2024 00:00:00 GMT https://www.ambacelar.com/blog/scrum https://www.ambacelar.com/blog/scrum The Missteps of Misusing SCRUM: Navigating Fixed Constraints and Prolonged Crunch Periods adi@ambacelar.com (Adilson Bacelar) Wed, 10 Jul 2024 00:00:00 GMT https://www.ambacelar.com/blog/hello-world https://www.ambacelar.com/blog/hello-world I am trying to figure out what my goal is for this site adi@ambacelar.com (Adilson Bacelar) Fri, 05 Jul 2024 00:00:00 GMT