Before choosing an AI model, a smart contract, or a database, I recommend answering four questions:

1. Source: Where does the original information come from?
2. Authority: Who can create or modify it?
3. Verification: How can another person reproduce the result?
4. Recovery: What happens when a service fails or the information is incorrect?

Consider a hypothetical product-traceability application. A blockchain transaction can provide evidence that a record existed at a particular point in the system's history. It cannot independently prove that the physical product was correctly identified.

That requires trustworthy data capture, operational controls, and an auditable connection between the physical and digital worlds.

The same principle applies to AI. A generated answer is not evidence until its sources and assumptions can be examined.

My approach to software development is to begin with the problem, define verification criteria, and introduce technology only where it provides measurable value.

Discussion: What is the most difficult part of verification in the systems you build?

Juan Pablo Abadía Medina — Full-stack development, blockchain and AI.

#Blockchain #ArtificialIntelligence #SoftwareArchitecture #Web3

Consider a small business that consolidates weekly sales. Start with a documented input format and validation rules. Reject missing mandatory fields. Record which files contributed to each report. Separate deterministic calculations from language generation, and require human approval before distribution.

Measure preparation time, correction frequency and the number of reports requiring manual intervention. Compare the new workflow against the existing process. If a script solves the problem reliably, an AI component may not be necessary.

For developers, the real challenge is building a system that remains understandable when something goes wrong. Observability, reproducibility and clear responsibility matter more than an impressive demonstration.

Juan Pablo Abadía Medina — Full-stack development, blockchain, AI and practical technology education.

A training provider wants to issue digital certificates. The first request sounds straightforward:

“Let’s put the certificates on a blockchain.”

Before opening a Solidity editor, I would want to understand what a verifier needs to know.

Does the certificate exist? Was it issued by an authorized organization? Has it been revoked? Does it belong to the person presenting it?

These are different questions. A useful architecture needs to address each one.

I’m Juan Pablo Abadía Medina, a full-stack developer, founder of Blockchain Technology S.A.S., and creator of Ponwi and Ponwi Academy. In this first article, I want to share how I approach a design question before committing to an implementation.

The example below is a hypothetical design exercise, rather than a description of a deployed product.

1. Describe the verification process

Imagine three participants:

• An issuer creates a certificate.
• A learner receives it.
• An employer checks it.

A minimal verification process might need to establish:

• The issuer’s identity and authority.
• The integrity of the certificate’s contents.
• Its current status.
• Its association with the person presenting it.

Recording a certificate hash on a blockchain addresses only part of that process.

It can help establish that the submitted data matches a previously recorded fingerprint. The application still needs a trustworthy way to identify the issuer, interpret the record, and check revocation.

2. Consider a conventional implementation

An initial design could use a database, an issuer dashboard, and a public verification page.

The issuer creates a record. The learner receives a certificate containing a verification link. An employer opens that link and checks the current status.

That approach may be sufficient when participants accept the provider as the authority and can rely on its service remaining available.

Its dependencies should be explicit: verification relies on the provider’s domain, application, database, and operational security.

Understanding those dependencies gives us something concrete to compare with other designs.

3. Ask what an independent record would add

A blockchain-based registry becomes worth investigating when there is a requirement for verification beyond a single provider’s database.

For example, several independent issuers might need to publish records under a shared set of rules. Verifiers might want to inspect those records using their own infrastructure.

Even then, the team needs to decide:

• Who can register an issuer?
• Who can issue or revoke a credential?
• Can those permissions change?
• Who controls upgrades?
• What happens if an issuer loses control of a key?
• Which network will support the registry, and who will maintain access to it?

These decisions define the trust model. The contract implements part of it.

4. Specify exactly what gets hashed

“Store the document hash” leaves an important detail unresolved: which representation of the document?

Hashing the exact bytes of a PDF makes verification sensitive to any byte-level change. A visually identical PDF exported by another tool may have a different hash.

Hashing structured certificate data introduces another requirement: deterministic encoding. Field order, whitespace, character encoding, and date formatting must be handled consistently.

The design should specify:

• The fields included in verification.
• Their encoding and normalization rules.
• A format version.
• The hashing algorithm.
• How verifiers obtain the original data.

Without a shared specification, the issuer and verifier can produce different fingerprints for information that appears identical to a person.

5. Keep personal information out of the registry design

For this example, I would begin with a requirement to keep names, identification numbers, email addresses, and certificate documents off-chain.

A registry could reference a credential fingerprint and status while the certificate itself is shared through an appropriate off-chain process.

A hash should not automatically be treated as anonymous. If the underlying information is predictable, someone may be able to guess candidate values and compare their hashes.

Privacy therefore needs to be considered when designing the credential format and verification flow, before choosing storage fields.

6. Test failure scenarios before building the interface

A successful demonstration proves that one expected path works. Architecture review also needs to examine what happens when something fails.

For this certificate example, I would test questions such as:

• Can an unauthorized account issue a credential?
• What happens when the same credential is submitted twice?
• How does verification display a revoked certificate?
• What happens if the frontend cannot reach its RPC provider?
• Does the interface distinguish a pending transaction from a confirmed record?
• Can a verifier inspect the record without relying on the issuer’s website?

The answers should influence both the contract and the user interface.

A verification page should explain what it checked and what remains outside its scope. A matching hash, for example, does not establish that a learner attended a course or earned a qualification honestly.

My starting point

For this hypothetical project, I would write a short verification specification before implementing the registry.

It would describe the participants, the claims being checked, the credential format, permission management, revocation, and failure handling.

Only then would I compare a database-backed service, digitally signed credentials, and a blockchain registry against those requirements.

That comparison gives the implementation a purpose—and gives future reviewers a way to assess whether it serves that purpose.

What requirement would make independent verification valuable in a system you are building?

Juan Pablo Abadía Medina
Full-stack developer and technology entrepreneur
Valle del Cauca, Colombia

GitHub · Ponwi · Blockchain Technology S.A.S.