DEV Community: SotaTek | AI & Blockchain Innovation Partner

RAG vs Fine-Tuning: Debug the Failure Before Changing the Model

SotaTek | AI & Blockchain Innovation Partner — Mon, 12 Oct 2026 08:51:28 +0000

RAG vs Fine-Tuning: Debug the Failure Before Changing the Model

When an LLM application produces bad answers, the first instinct is often to change the model.

Try a larger model. Add more examples to the prompt. Fine-tune it on domain-specific data. Maybe introduce a vector database.

But these interventions solve different problems. Applying the wrong one can increase cost and complexity without improving the result.

Consider two failure cases:

An enterprise assistant gives an outdated answer because the latest policy never reached the model.

A classification system has all the information it needs but repeatedly produces inconsistent output formats.

The first is a knowledge-access problem. The second is a behavior problem.

RAG changes what information the model can access at inference time. Fine-tuning changes the behavior learned by the model.

At SotaTek, we approach this decision as an engineering problem: identify the failing layer, measure it, and introduce the smallest change that addresses the actual failure.

Let's break down how to do that.

Understand What Each Technique Actually Changes

Retrieval-Augmented Generation (RAG)

RAG retrieves external information at runtime and provides it as context to the LLM.

The model's weights remain unchanged. The application changes the information available to the model for a particular request.

This is useful when answers depend on private, changing, or traceable information, such as internal policies, product catalogs, technical documentation, or customer records.

When a policy changes, the knowledge source can be updated and re-indexed without retraining the model.

Fine-Tuning

Fine-tuning adjusts a pretrained model using additional training examples to reinforce desired behavior.

Suppose a model must transform incident reports into a fixed internal classification schema.

{
"input": "Surface blistering detected near connector.",
"output": {
"category": "MATERIAL_DELAMINATION",
"severity": "S2",
"inspection_route": "MICROSCOPY"
}
}

A fine-tuning dataset can contain many representative input-output examples that demonstrate the required behavior.

The objective is not primarily to teach the model which incident happened yesterday. It is to make the model more consistent at performing a particular task.

This can be useful for specialized classification, structured extraction, domain-specific transformations, and high-volume tasks where prompt overhead or inference efficiency matters.

Diagnose the Failure Before Choosing a Solution

A useful starting point is to separate the problem into three layers.

Layer

Diagnostic question

Potential intervention

Retrieval

Did the system find the correct evidence?

Improve search, metadata, chunking, or reranking

Context

Did the relevant evidence reach the model?

Improve context selection and prompt construction

Generation

Did the model use the evidence correctly?

Improve prompting, validation, or evaluate fine-tuning

This distinction prevents a common mistake: trying to fix a retrieval failure by changing the model.

Imagine an enterprise assistant that must answer questions about internal security policies.

The correct policy exists in the knowledge base, but retrieval consistently ranks it outside the top five results.

A larger LLM may generate a more convincing response, but it cannot reliably use evidence that never reaches its context window.

The right intervention is probably in the retrieval pipeline, not model training.

Evaluate the Baseline Before Changing Anything

Before introducing RAG or fine-tuning, establish a baseline using representative test cases.

For an enterprise assistant, you might track:

Metric

Baseline

Answer accuracy

71%

Groundedness

68%

Format compliance

91%

Retrieval Recall@5

62%

These figures are illustrative, not benchmark results.

Even this small dataset suggests a direction: retrieval recall is relatively weak, while format compliance is already stronger.

Fine-tuning should not be the first intervention without further evidence. The system may be failing because it cannot retrieve the information required to answer correctly.

For a RAG application, evaluate retrieval and generation separately.

def evaluate_rag(query, expected_doc_ids, retriever, generator):
retrieved = retriever.search(
query=query,
top_k=5,
)

retrieved_ids = {
    document.id for document in retrieved
}

relevant_ids = set(expected_doc_ids)

recall_at_5 = (
    len(retrieved_ids & relevant_ids)
    / len(relevant_ids)
    if relevant_ids else 0.0
)

answer = generator.generate(
    query=query,
    context=retrieved,
)

return {
    "recall_at_5": recall_at_5,
    "answer": answer,
    "retrieved_count": len(retrieved),
}

This is a simplified evaluation example. A production implementation also needs to handle multiple relevant documents, retrieval ranking, empty results, access permissions, and answer-quality grading.

The important principle is to measure the retrieval layer independently from the generation layer.

Otherwise, a single answer-quality score tells you that something failed without telling you where to investigate.

A Production RAG Pipeline Is More Than a Vector Database

A basic RAG implementation often looks like this:

Documents -> Embeddings -> Vector DB -> LLM

That can demonstrate the concept, but production retrieval typically requires additional components:

Document parsing and structure extraction

Chunking and metadata enrichment

Vector, lexical, or hybrid search

Query rewriting

Permission-aware filtering

Reranking

Context selection

Citation mapping

Retrieval and groundedness evaluation

Consider a multi-tenant enterprise application.

Retrieval must enforce the user's permissions before documents are passed into the model. Filtering the final answer afterward is not a substitute for preventing unauthorized context from entering the generation pipeline.

A simplified retrieval flow might look like this:

def answer_question(query, user):
candidates = search(
query=query,
workspace_id=user.workspace_id,
permissions=user.permissions,
top_k=30,
)

ranked = rerank(
    query=query,
    documents=candidates,
)

context = select_context(
    documents=ranked,
    max_documents=5,
)

return llm.generate(
    question=query,
    context=context,
    instructions=(
        "Answer using the provided evidence. "
        "Cite sources for factual claims. "
        "If evidence is insufficient, say so."
    ),
)

The functions are illustrative rather than tied to a specific framework. Authorization must also be enforced by a trusted application layer, not delegated to the model or a prompt instruction.

If the correct information is already available but retrieval is poor, improve the retrieval system before assuming that the model needs fine-tuning.

When Fine-Tuning Becomes Worth Evaluating

Fine-tuning is more relevant when the model receives adequate information but repeatedly fails to perform the task in the required way.

Typical signals include:

Output schemas are inconsistent despite clear instructions.

The same specialized classification task produces unstable results.

Domain terminology is repeatedly misunderstood.

Few-shot examples make the prompt excessively large.

A smaller model needs to reproduce behavior previously achieved with a larger one.

However, fine-tuning is not automatically the next step.

Before training, check whether the failure can be solved with clearer instructions, structured output constraints, better examples, or simpler application logic.

If fine-tuning is justified, keep training, validation, and final evaluation data separate.

from sklearn.model_selection import train_test_split

train_data, holdout_data = train_test_split(
examples,
test_size=0.20,
random_state=42,
)

train_data, validation_data = train_test_split(
train_data,
test_size=0.125,
random_state=42,
)

print("Training:", len(train_data))
print("Validation:", len(validation_data))
print("Holdout:", len(holdout_data))

This produces an approximate 70/10/20 split.

For production datasets, split by the appropriate unit, such as customer, document, time period, or source record, when random splitting could leak near-duplicate examples across datasets.

After training, evaluate both the target behavior and potential regressions on previously supported tasks.

A model that improves formatting but loses general capability may not be a worthwhile trade-off.

Compare Total System Cost, Not Just Model Cost

RAG and fine-tuning move engineering and operating costs to different places.

Factor

RAG

Fine-tuning

Initial engineering

Data ingestion and retrieval

Dataset preparation and training

Knowledge updates

Synchronize or re-index sources

May require another tuning cycle

Inference latency

Retrieval and reranking add steps

May use a simpler inference path

Prompt size

Retrieved context can be large

Learned behavior may reduce prompt examples

Main evaluation focus

Retrieval and groundedness

Task behavior and regression

Maintenance

Data freshness and retrieval quality

Training data and model versions

Source traceability

Supported through retrieved metadata

Not inherently provided by model weights

Neither approach is universally cheaper or faster.

RAG adds retrieval infrastructure and runtime work. Fine-tuning adds training, validation, artifact management, and model-version maintenance.

The right comparison is the total cost per successful business task, including retries, human review, infrastructure, and operational maintenance.

A lower inference cost per request does not necessarily translate into a lower cost per successful outcome.

When Both Techniques Make Sense

Some applications genuinely have both problems.

Consider an enterprise compliance assistant that must:

Retrieve the latest regulations and internal policies.

Compare relevant clauses.

Apply an organization-specific classification scheme.

Produce a structured review.

Cite supporting evidence.

RAG provides the current, traceable knowledge. Fine-tuning may help with the specialized output behavior if evaluation shows that prompting alone is insufficient.

The architecture could look like this:

The two techniques operate at different layers.

But combining them should be an evidence-based decision. Irrelevant retrieved context can introduce noise, even when the model has been fine-tuned successfully.

Test the baseline, RAG-only, fine-tuning-only where appropriate, and hybrid configuration against the same held-out evaluation set.

Keep the hybrid architecture only if the improvement justifies its additional complexity.

A Practical Decision Framework

Use this sequence when deciding what to build:

Start with the base model
|
v
Can prompting and output constraints
meet the evaluation target?
|
Yes | No
| |
v v
Ship Diagnose the failure
|
+------+------+
| |
v v
Missing or Inconsistent
stale knowledge behavior
| |
v v
RAG Evaluate fine-tuning
| |
+------+------+
|
v
Do both problems remain?
|
Yes | No
| |
v v
Evaluate Keep the simplest
hybrid working approach

A few practical rules follow:

If the model needs current, private, or source-backed information, start by evaluating RAG.

If the information is already available but the model consistently performs the task incorrectly, investigate behavior and prompting before considering fine-tuning.

If both knowledge access and specialized behavior are failing, evaluate the two interventions independently before combining them.

If the base model already meets the acceptance criteria, avoid adding infrastructure without a measurable reason.

Final Thoughts

RAG and fine-tuning are not competing ways to make an LLM smarter. They address different failure modes.

RAG changes the evidence available to the model. Fine-tuning changes the behavior learned by the model.

The engineering challenge is to identify which layer is failing and prove that the proposed intervention improves the result.

That requires more than selecting a model or a vector database. It requires representative evaluation data, clear metrics, reliable retrieval, controlled access, regression testing, and production monitoring.

At SotaTek, we treat these choices as part of a broader AI engineering process: start with the use case, establish a baseline, validate the architecture, and introduce model customization only when the evidence supports it.

For a broader view of how these decisions fit into enterprise AI delivery, see our AI Development Process guide.

The AI Development Lifecycle: From PoC to Production Without Guesswork

SotaTek | AI & Blockchain Innovation Partner — Mon, 12 Oct 2026 08:06:14 +0000

Getting an AI model to work in a demo is relatively easy.

Getting it to work reliably with real data, existing business systems, production traffic, security constraints, and a measurable budget is a different engineering problem.

A prototype can look impressive while hiding problems that only appear later: poor data coverage, unstable outputs, slow integrations, unpredictable inference costs, or evaluation metrics that don't reflect actual business value.

The solution isn't necessarily a better model. It's a development process that forces these issues to surface before they become expensive production failures.

At SotaTek, we approach AI development as a systems engineering problem, where model selection is only one decision in a much larger lifecycle.

Here's how I'd structure that lifecycle.

Start With a Measurable Problem, Not a Model

Before choosing an LLM, training a classifier, or building an agent, define the problem the system needs to solve.

Three things should be explicit:

KPI: What outcome should improve?

Baseline: How does the current process perform?

Acceptance threshold: What result justifies moving forward?

For example, an internal document assistant might have these initial targets:

Metric

Example target

Answer quality

At least 85% on a defined evaluation set

P95 response latency

Under 3 seconds

Cost per request

Within the approved budget

Unsupported claims

Below an agreed threshold

These numbers are illustrative, not universal benchmarks. The correct thresholds depend on the use case and the consequences of failure.

Define a kill criterion, too.

If the prototype cannot outperform the existing workflow within the agreed cost and quality constraints, the team should be able to stop or change direction.

This prevents a technically interesting experiment from becoming an indefinitely funded product.

Audit the Data Before Selecting the Architecture

Data readiness can change the entire technical approach.

A dataset may exist but still be unsuitable because it is incomplete, inconsistent, inaccessible, poorly labeled, or restricted by privacy requirements.

Before implementation, answer:

Where does the data come from?

Who owns it, and who can access it?

How frequently does it change?

Does it require labeling, cleaning, or deduplication?

Can it legally and securely be used for this purpose?

How will its quality be measured?

The last question matters because data quality is not just a preparation concern. It affects evaluation, production reliability, and ongoing maintenance.

For example, a computer vision system with inconsistent annotations may learn the wrong visual patterns. A retrieval-augmented generation (RAG) system with stale documents may return technically relevant but outdated answers.

Engineering decision: Don't commit to a model or architecture until you understand the data constraints well enough to estimate their impact.

Choose the Simplest Architecture That Meets the Requirements

Not every AI use case needs an agent, fine-tuning, or a complex orchestration layer.

Start by matching the problem to the simplest viable approach.

Requirement

Potential approach

Classification or forecasting

Traditional machine learning

Text generation or summarization

Foundation model API

Answers grounded in private or changing documents

RAG

Specialized behavior not adequately achieved through prompting

Fine-tuning, if justified

Image or video inspection

Computer vision

Multi-step workflows requiring tools

Agentic architecture, when necessary

Then evaluate the candidates against the same constraints:

Accuracy and failure tolerance

Latency and throughput

Cost per task

Data privacy and deployment requirements

Integration complexity

Operational overhead

Vendor dependency

A more sophisticated architecture isn't automatically a better one.

An agent that makes several model calls and invokes multiple tools may solve a task, but a deterministic workflow could achieve the same result with lower latency, lower cost, and more predictable behavior.

The decision should be based on measured requirements, not architectural novelty.

Make the PoC an Experiment, Not a Demo

A proof of concept should answer a specific question:

Does this approach work on representative data under realistic conditions?

Build the smallest useful prototype, but define the evaluation process before tuning the system.

For an LLM application, an evaluation dataset might contain:

Representative user inputs

Expected answers or grading criteria

Relevant source documents

Known failure cases

Cases where the system should refuse or request clarification

A simple evaluation harness could look like this:

def evaluate_system(cases, system, grader):
results = []

for case in cases:
    prediction = system.run(case["input"])

    score = grader(
        prediction=prediction,
        expected=case.get("expected"),
        context=case.get("context"),
    )

    results.append({
        "case_id": case["id"],
        "score": score,
        "latency_ms": prediction.latency_ms,
        "cost": prediction.cost,
    })

return results

This is a simplified example; the grading logic and result schema depend on the application.

The important part is consistency. You need to compare different prompts, models, retrieval strategies, or architectures against the same evaluation criteria.

Track more than answer quality:

Task success rate

Retrieval quality, when applicable

Hallucination or unsupported-claim rate

Latency, including P95

Cost per successful task

Failure rate on edge cases

Keep evaluation data separate from data used to tune prompts or train the model. Otherwise, the results may overstate how well the system generalizes.

A successful PoC earns the right to move into production engineering. It does not prove that the system is production-ready.

Treat Production Engineering as a Separate Stage

A working prototype usually proves that the core capability is possible. It rarely proves that the complete application is reliable.

Production engineering adds the surrounding system:

Client
|
API Gateway
|
Authentication / Authorization
|
Application Logic
|
AI Orchestration
|------------------|
| |
Model Inference Retrieval / Tools
| |
| Enterprise Systems
|------------------|
|
Output Validation
|
Response
|
Logs / Metrics / Traces

The actual architecture will vary, but several concerns should be addressed before release.

Integration: Can the system interact reliably with existing APIs, databases, CRMs, ERPs, or internal services?

Security: Are permissions enforced outside the model? Can retrieved documents or tool calls expose data the current user should not access?

Reliability: What happens when a model provider times out, a retrieval service becomes unavailable, or an upstream API returns an error?

Consistency: If a tool call times out after a transaction succeeds, can a retry accidentally create a duplicate operation?

For state-changing tools, use idempotency keys or equivalent safeguards where appropriate. Validate tool inputs and enforce authorization in the application layer.

The model may propose an action. The application must decide whether that action is permitted.

Deploy Against Real Constraints

Deployment architecture should follow the workload and operating environment.

Public cloud, private cloud, on-premise, edge, and hybrid deployments each introduce different trade-offs around latency, data residency, connectivity, scalability, and maintenance.

For example, an AI inspection system in a factory with no internet access cannot depend on a remote inference API during normal operation.

That constraint affects model selection, hardware requirements, update mechanisms, and monitoring from the beginning.

The same principle applies to enterprise LLM applications: data sensitivity, network boundaries, and response-time requirements should influence the design before the deployment stage.

A production release should also include:

Staged rollout where feasible

Health checks and readiness checks

Security and load testing

Versioned models and configuration

Rollback procedures

A defined human-review path for high-risk decisions

Deployment is not complete simply because the endpoint responds successfully.

Monitor the System After Launch

AI systems can degrade even when the application code hasn't changed.

Documents become outdated. User behavior shifts. Input distributions change. Model providers update their services. Traffic patterns alter latency and cost.

A useful monitoring plan should cover several layers:

Layer

What to monitor

Model

Output quality, refusal behavior, task success

Retrieval

Recall, relevance, stale or missing documents

Application

Errors, timeouts, tool failures

Performance

P50/P95 latency, throughput

Economics

Cost per request and cost per successful task

Data

Distribution shifts, missing fields, drift

User experience

Feedback, abandonment, correction rates

For systems using RAG, retrieval quality and answer quality should be monitored separately. A weak answer may result from poor retrieval rather than the model's generation capability.

Similarly, a rise in cost per request may come from longer prompts, more retrieved context, repeated tool calls, or routing too many requests to a large model.

Monitoring should help identify the source of degradation, not merely report that something went wrong.

Every metric needs an owner, an acceptable range, and a response plan.

Use Go/No-Go Gates to Control Risk

The lifecycle becomes more useful when each stage produces evidence for the next decision.

Stage

Required evidence

Decision

Discovery

KPI, baseline, acceptance criteria

Is the problem worth solving?

Data readiness

Data audit and access plan

Can the data support the use case?

Architecture

Evaluated approach and risk assessment

Does the design fit the constraints?

PoC

Results against the evaluation set

Does it beat the baseline?

Production engineering

Integration, security, and load-test results

Is the system ready to release?

Deployment

Rollback plan and operational checks

Can the release be operated safely?

Monitoring

Quality, latency, cost, and drift metrics

Is the system still meeting its targets?

The point is not to create more meetings or paperwork. It's to make technical and business decisions explicit while changing direction is still relatively inexpensive.

The Real Deliverable Is a Reliable System

The AI development lifecycle is not simply a sequence of model-building tasks.

It's a way to manage uncertainty across data, architecture, evaluation, integration, security, deployment, and ongoing operations.

A useful mental model is:

Production AI = Model + Data + Application + Integration + Evaluation + Security + Operations

Leaving out any of these layers can turn a promising prototype into a system that's expensive to maintain, difficult to trust, or impossible to scale reliably.

At SotaTek, this systems-level perspective guides the transition from AI feasibility and PoC validation to production engineering, integration, and MLOps.

The objective isn't just to make an AI model work. It's to build a system that continues to deliver measurable value after launch.

For a broader breakdown of the seven stages, their deliverables, and the go/no-go criteria that keep projects on track, see our AI Development Process guide.

Your AI System Is More Than the Model: What Production AI Architecture Actually Looks Like

SotaTek | AI & Blockchain Innovation Partner — Tue, 06 Oct 2026 10:50:10 +0000

A production AI system is rarely just:
User → API → LLM → Response

That architecture works well in a demo.
Production is different.
Once an AI system has to work with private data, enterprise systems, user permissions, unreliable model outputs, latency constraints, cost limits, and changing requirements, the model becomes only one component of a much larger system.
At SotaTek, we approach AI development from this broader systems perspective: the model is only one layer of the product, while data, application logic, integrations, security, evaluation, infrastructure, and observability determine whether that capability can actually work in production.
A more realistic architecture looks like this:
User / Business Workflow
↓
Application
↓
Authentication / Authorization
↓
AI Orchestration Layer
↙ ↘
Retrieval Tools
↓ ↓
Knowledge Enterprise
Sources Systems
\ /
\ /
Model
↓
Guardrails / Validation
↓
Response
↓
Logging / Evaluation
↓
Monitoring / Feedback

The interesting engineering problems are usually somewhere between those boxes.
**Start With the Workflow, Not the Model
**One of the easiest mistakes in AI development is starting with:
Which model should we use?

A better starting point is:
What changes in the business workflow if the AI system works exactly as intended?

Consider an internal support assistant.
A naive implementation might look like:
response = llm.generate(user_question)

But the real requirement may be:
User
↓
Ask question
↓
Check permissions
↓
Find relevant company information
↓
Generate answer
↓
Validate response
↓
Log interaction
↓
Return answer

The model is only responsible for part of that workflow.
This distinction becomes important as soon as the application has real users and real data.
**The Application Layer Owns the Business Logic
**A common anti-pattern is putting too much responsibility inside the prompt.
For example:
SYSTEM_PROMPT = """You are an enterprise assistant.Only access information the user is allowed to see.Never modify financial records.Never approve a transaction.Always follow company policy."""

That sounds reasonable, but prompts are not an authorization system.
Permissions should be enforced by application code.
async def get_customer_data(user, customer_id): if not user.can_access("customer", customer_id): raise PermissionError("Access denied") return await customer_repository.get(customer_id)

The LLM can decide what information it needs.
The application decides whether it is allowed to access that information.
That boundary matters.
LLM
│
"I need customer data"
↓
Tool / API Layer
↓
Authorization Check
↓
Enterprise API

This also makes the system easier to audit and test.
RAG Is an Application Architecture, Not Just a Vector Database
For enterprise knowledge systems, retrieval-augmented generation is useful when information changes frequently or is private to the organization.
A simplified pipeline looks like:
Document
↓
Chunking
↓
Embedding
↓
Vector Database
↓
User Query
↓
Query Embedding
↓
Similarity Search
↓
Retrieved Context
↓
LLM
↓
Answer

A minimal implementation might look like:
async def answer_question(question: str): query_vector = await embed(question) documents = await vector_db.search( vector=query_vector, top_k=5 ) context = "\n\n".join( document.content for document in documents ) return await llm.generate( system=SYSTEM_PROMPT, user=question, context=context )

But this is still missing an important part:
authorization-aware retrieval.
Suppose the vector database contains:
Public documents
Internal documents
Finance documents
HR documents
Executive documents

A semantic search returning the most relevant document does not mean the user should see it.
The retrieval layer may therefore need metadata filtering:
documents = await vector_db.search( vector=query_vector, top_k=5, filters={ "tenant_id": user.tenant_id, "allowed_roles": { "$in": user.roles } })

The retrieval system is now part of the security boundary.
AI Agents Add a Different Class of Engineering Problems
A chatbot mostly generates responses.
An agent can take actions.
For example:
User
↓
Agent
├── search_customer()
├── get_invoice()
├── create_ticket()
├── update_order()
└── escalate_to_human()

A simplified tool-calling loop might look like:
async def run_agent(user, request): response = await llm.generate( messages=[request], tools=AVAILABLE_TOOLS ) if not response.tool_calls: return response.text for call in response.tool_calls: tool = get_tool(call.name) if not user.can_execute(tool.permission): raise PermissionError( f"Not allowed: {call.name}" ) result = await tool.execute( **call.arguments ) await audit_log.write( user=user.id, tool=call.name, arguments=call.arguments ) return await llm.generate( messages=[request, result], tools=AVAILABLE_TOOLS )

Now the architecture needs more than an LLM.
It needs:

permissions
tool contracts
state management
audit logs
approval rules
retries
idempotency
human escalation
failure handling This is where an AI agent starts looking much more like a distributed application than a chatbot. Tool Calls Need Idempotency Consider an agent that can create an order. The model calls: { "tool": "create_order", "arguments": { "customer_id": "123", "amount": 500 } }

What happens if:

The API succeeds.
The network times out.
The model retries the tool call. Without idempotency, you might create two orders. A safer API design is: POST /orders Idempotency-Key: agent-run-8f32...

The backend can then ensure that repeated requests with the same key do not create duplicate side effects.
This is a good example of why AI engineering overlaps heavily with conventional backend engineering.
The model can decide what it wants to do.
The backend still has to guarantee what actually happens.
Model Selection Is a System Trade-off
There is rarely a universally correct model.
The architecture may use:
AI Request
↓
Routing Layer
↙ ↓ ↘
Small Large Vision
Model Model Model

A simple routing strategy could look like:
def select_model(task): if task.type == "classification": return SMALL_MODEL if task.requires_reasoning: return LARGE_MODEL if task.requires_vision: return VISION_MODEL return DEFAULT_MODEL

The decision should consider more than benchmark quality.
Typical variables include:
Accuracy
Latency
Cost
Context length
Privacy
Throughput
Availability
Deployment model
Vendor dependency
Maintenance complexity

For some workloads, a smaller model with predictable latency can be more practical than a larger model that produces slightly better answers but costs significantly more.
For others, additional reasoning capability may justify the cost.
The architecture should make this trade-off measurable rather than ideological.
Evaluation Is Part of the Product
One of the biggest differences between a demo and a production AI system is evaluation.
Traditional software often has deterministic tests:
assert calculate_total(100, 10) == 110

AI systems are more complicated.
A useful evaluation pipeline might look like:
Test Dataset
↓
Model
↓
Generated Output
↓
Evaluation
┌───┼───────────┐
↓ ↓ ↓
Quality Grounding Latency
↓ ↓ ↓
Evaluation Report

For a RAG system, you might track:
metrics = { "retrieval_precision": ..., "answer_groundedness": ..., "answer_relevance": ..., "hallucination_rate": ..., "latency_p95": ..., "cost_per_request": ...}

The important part is defining what “good enough” means before production.
Otherwise, teams can discover that the system technically works but nobody can agree whether it works well.
Observability Needs to Cover More Than API Errors
A normal backend might monitor:
HTTP 5xx
CPU
Memory
Latency
Request volume

An AI system needs additional signals.
For example:
Request
↓
Prompt
↓
Retrieval
↓
Model
↓
Tool Calls
↓
Response

Useful telemetry can include:
Model latency
Time to first token
Total tokens
Input tokens
Output tokens
Retrieval latency
Number of retrieved documents
Tool execution time
Tool failures
Guardrail violations
User feedback
Cost per request

A production trace might therefore look like:
request_id: 7f82...

API latency: 1.2s
retrieval latency: 180ms
LLM latency: 820ms
tokens: 2,431
tools called: 2
retrieved docs: 5
estimated cost: $0.014

Now you can investigate why an AI request became slow or expensive instead of treating the model as a black box.
Guardrails Should Sit Around the Model
Guardrails are often described as a single safety layer.
In production, they can exist at several points:
User Input
↓
Input Validation
↓
Authorization
↓
Retrieval
↓
LLM
↓
Output Validation
↓
Tool Authorization
↓
Final Response

For example:
if contains_sensitive_request(user_input): return "This request cannot be processed."response = await llm.generate(...)if not passes_output_policy(response): return "The generated response requires review."

For systems that can execute actions, the tool layer should also enforce permissions independently of the model.
The model should never be the final authority for security-sensitive operations.
Deployment Changes the Architecture
The same AI application can require very different infrastructure depending on the environment.
AI Application
↓
┌──────────┼──────────┐
↓ ↓ ↓
Cloud Private Edge
↓ ↓ ↓
Managed On-prem Local
APIs Models Models

The choice depends on factors such as:

latency
data sensitivity
connectivity
GPU availability
operational requirements
infrastructure cost
compliance requirements
expected traffic For example, an industrial computer vision system operating inside a factory may have very different requirements from a cloud-based enterprise chatbot. The model is only one part of the deployment decision. The Production Architecture Putting the pieces together: ┌──────────────────┐ │ Users │ └────────┬─────────┘ ↓ ┌──────────────────┐ │ Application/API │ └────────┬─────────┘ ↓ ┌────────────────────────┐ │ Authentication / AuthZ │ └────────────┬───────────┘ ↓ ┌────────────────────────┐ │ AI Orchestration │ └───────┬────────┬────────┘ ↓ ↓ Retrieval Tools ↓ ↓ Knowledge Enterprise Base Systems \ / \ / ↓ ↓ ┌───────────┐ │ Model │ └─────┬─────┘ ↓ ┌──────────────────┐ │ Guardrails / Eval│ └────────┬─────────┘ ↓ Final Output ↓ ┌────────────────────────┐ │ Logging / Monitoring │ │ Cost / Quality / SLOs │ └────────────────────────┘

This is why “adding an LLM” and “building an AI system” are two very different engineering tasks.
If you want the broader view of how these components fit into an AI development engagement, from use-case discovery and readiness assessment through PoC, production engineering, deployment, and ongoing optimization, see our AI Development Company guide.
A Practical AI Development Lifecycle
A production project can be reduced to a fairly simple sequence:
Discovery
↓
Feasibility
↓
Data / AI Readiness
↓
Architecture
↓
PoC
↓
Evaluation
↓
Production Engineering
↓
Integration
↓
Deployment
↓
Monitoring
↓
Continuous Optimization

The important part is not to jump directly from:
Idea → Production

without validating the intermediate assumptions.
A PoC should answer questions such as:
Can the data support the use case?

Is the model accurate enough?

Is retrieval good enough?

Is latency acceptable?

Is the cost acceptable?

Can the system integrate with existing workflows?

What security risks exist?

What happens when the model is wrong?

If those questions cannot be answered, scaling the infrastructure will not solve the underlying problem.
For a deeper look at how these components come together across the AI development lifecycle, from use-case discovery and PoC validation to production deployment and optimization, we’ve covered the broader process in our AI Development Company guide.

The Engineering Boundary That Matters Most
The most useful mental model is probably this:
AI Model
│
┌────────┴────────┐
│ │
What to generate What to do
│ │
↓ ↓
Application Tool Layer
Logic Permissions
RAG Validation
Context Audit Logs
Evaluation Transactions
│ │
└────────┬────────┘
↓
Production

The model provides intelligence.
The surrounding software provides reliability.
That distinction becomes increasingly important as AI systems move from demos into business-critical workflows.
Final Thoughts
The hardest part of AI development is often not getting a model to produce an impressive output.
It is turning that capability into a system that can operate reliably with real data, real users, real permissions, real infrastructure, and real business constraints.
That means treating AI development as a systems engineering problem:
Model
+
Data
+
Application
+
Integration
+
Security
+
Evaluation
+
Infrastructure
+

Observability

Production AI System

At SotaTek, this broader system perspective is particularly important when moving from PoC validation into production AI applications, enterprise integrations, and AI operations.
The interesting question is no longer:
Which AI model should we use?

It is:
What system needs to exist around the model for this capability to work reliably in production?

What Actually Happens When You Mint an NFT?

SotaTek | AI & Blockchain Innovation Partner — Mon, 28 Sep 2026 07:51:12 +0000

“Mint an NFT” sounds like a single operation.

From a user's perspective, it often looks like this:

Connect Wallet
↓
Click Mint
↓
Confirm Transaction
↓
NFT Appears in Wallet

Underneath that button, several systems have to agree on the same state.

The image is not necessarily stored on the blockchain. The metadata may live on IPFS or another storage layer. The smart contract owns the token ID and ownership state. The wallet signs the transaction. An indexer eventually makes the new asset visible to the application.

A simplified architecture looks like this:

                NFT Application
                      │
                      ▼
                 Mint UI
                      │
                      ▼
                   Wallet
                      │
                signed tx
                      ▼
              Smart Contract
                /          \
               /            \
              ▼              ▼
         Token State     Metadata URI
              │              │
              ▼              ▼
         Blockchain     IPFS / Storage
              │
              ▼
            Events
              │
              ▼
           Indexer
              │
              ▼
        Marketplace / UI

The interesting part is that the NFT itself is only one piece of the system.

Start With What the NFT Actually Represents

Before writing a contract, you need to define the asset.

An NFT could represent:

A unique collectible
A game character
A ticket
A membership credential
A digital certificate
A real-world asset
A composable digital asset

That decision affects the contract design, metadata structure, token standard, and transfer model.

For example, a collection of unique digital artworks has a different structure from a game inventory containing thousands of identical consumable items.

This is why token standard selection should happen before implementation.

ERC-721 vs ERC-1155

For a simple one-of-a-kind asset, ERC-721 is usually the easier mental model.

Each token has its own ID:

Collection
│
├── Token #1
├── Token #2
├── Token #3
└── Token #4

ERC-1155 takes a different approach.

A single contract can represent multiple token types and quantities:

Contract
│
├── Item #1001 → 5,000 copies
├── Item #1002 → 2,000 copies
└── Item #1003 → 1 copy

This makes ERC-1155 useful for applications such as gaming, where an inventory may contain both unique assets and high-volume items.

The choice is therefore not about which standard is “better”.

It depends on the asset model.

A useful rule is:

Unique asset
↓
ERC-721

Multiple / batch-oriented assets
↓
ERC-1155

NFTs that own other assets
↓
Composable design such as ERC-998

The source article also identifies ERC-721, ERC-1155, ERC-998 and TRC-721 as common options, with the choice depending on asset structure, blockchain and marketplace compatibility.

The Image Is Not the NFT

This is one of the most common misconceptions.

Suppose an NFT displays:

Golden Sword
Attack: 95
Rarity: Legendary
Image: sword.png

Those properties are generally represented through metadata.

A simplified metadata document could look like:

{
"name": "Golden Sword",
"description": "Legendary in-game weapon",
"image": "ipfs://...",
"attributes": [
{
"trait_type": "Rarity",
"value": "Legendary"
},
{
"trait_type": "Attack",
"value": 95
}
]
}

The smart contract does not necessarily store this entire JSON object.

Instead, the token commonly exposes a metadata URI:

NFT #1842
│
▼
tokenURI(1842)
│
▼
ipfs://metadata...

This keeps large assets and metadata outside the blockchain while allowing the token to reference them.

The source architecture similarly separates metadata from the token itself, with metadata commonly stored off-chain using systems such as IPFS or Arweave and referenced from the token.

Why Put Metadata Off-Chain?

Storing an image directly on-chain is possible, but it can be expensive and impractical for many collections.

A common architecture is:

                Blockchain
                    │
                    │ tokenURI
                    ▼
              Metadata URI
                    │
                    ▼
            Decentralized Storage
                    │
          ┌─────────┴─────────┐
          ▼                   ▼
       Metadata             Image
          │                   │
          └─────────┬─────────┘
                    ▼
               NFT Interface

The important distinction is:

The blockchain proves token ownership.

It does not automatically guarantee that every external asset referenced by the token will remain available forever.

That is why storage architecture is part of NFT engineering, not just a frontend concern.

The Smart Contract Defines Ownership

A minimal ERC-721 contract might look like:

contract GameAsset is ERC721 {
uint256 private nextTokenId;

function mint(address to)
    external
    returns (uint256)
{
    uint256 tokenId = nextTokenId++;
    _safeMint(to, tokenId);

    return tokenId;
}

}

The important operation here is not the image or metadata.

It is:

_mint(to, tokenId)

The blockchain now records that:

Token #1842
↓
Owner = 0xA91...

That ownership state can then be independently verified.

A marketplace does not need to trust your database to determine who owns the NFT.

It can query the contract or indexed blockchain data.

What Actually Happens During Minting?

Let's follow a mint transaction.

The application prepares the transaction

The frontend knows:

Contract address
Token ID / mint parameters
Recipient
Metadata configuration

It prepares a contract call.

mint(recipient)

The wallet signs it

The user confirms the transaction through their wallet.

The wallet signs the transaction with the user's private key.

The application does not receive the private key.

User
│
▼
Wallet
│
│ signed transaction
▼
Blockchain Network

The transaction reaches the smart contract

The blockchain executes the contract.

The contract checks whatever rules have been implemented:

Can this caller mint?
│
├── No → revert
│
└── Yes
↓
Create token
↓
Assign owner
↓
Emit event

Ownership is written to blockchain state

After successful execution:

Token #1842
│
├── Owner → 0xA91...
└── Metadata → ipfs://...

The transaction receipt and event logs provide evidence of the state transition.

Minting Is Also a Security Boundary

The simple contract above has a major problem:

Who is allowed to call mint()?

If anyone can call it, anyone can create unlimited tokens.

Production contracts therefore need access control.

Conceptually:

function mint(address to)
external
onlyRole(MINTER_ROLE)
{
...
}

Other controls may include:

Maximum supply
Per-wallet limits
Pausing
Signature-based mint authorization
Payment validation
Allow lists
Mint phases
Upgrade permissions

This is why smart contract development is one of the security-sensitive stages of NFT development. The source article specifically identifies smart contract security, access control, and transaction integrity as major risks.

The Event Is Just as Important as the State

Suppose the contract emits:

event NFTMinted(
address indexed owner,
uint256 indexed tokenId
);

The event can then be consumed by off-chain infrastructure:

Smart Contract
│
│ NFTMinted
▼
Blockchain Node
│
▼
Event Listener
│
▼
Indexer
│
▼
Application Database
│
▼
Marketplace / UI

This is how the application can discover that a new NFT has been minted without constantly scanning every transaction manually.

The blockchain remains the source of truth.

The indexer becomes the query layer.

That distinction matters.

Why an Indexer Is Necessary

Imagine a marketplace displaying:

Latest NFTs
Trending Collections
Owner History
Sales History
Floor Price
Trading Volume

Querying raw blockchain state for every page load quickly becomes impractical.

An indexer can transform blockchain events into application-friendly data:

Blockchain Events
│
▼
Indexer
│
├── NFT ownership
├── Transfers
├── Sales
├── Collections
└── Metadata
│
▼
Database
│
▼
Frontend

But indexing introduces its own engineering problems.

You need to handle:

Duplicate events
RPC failures
Delayed confirmations
Chain reorganizations
Reprocessing
Idempotency
Metadata synchronization

So the NFT does not become “visible everywhere” immediately after the user clicks Mint.

There is a state transition between transaction submitted and application synchronized.

The Marketplace Does Not Own the NFT

A marketplace typically facilitates trading.

The underlying NFT remains governed by its smart contract.

A simplified secondary sale looks like:

Seller
│
│ list NFT
▼
Marketplace
│
│ buyer purchases
▼
Smart Contract
│
├── transfer NFT
├── transfer payment
└── emit events
│
▼
Indexer
│
▼
Updated marketplace

This is an important architectural boundary.

The marketplace database should not become the authority for ownership.

The contract should enforce the actual asset transfer.

Royalties Are a Contract Design Problem

NFT projects often want creators to receive a percentage from secondary sales.

That sounds straightforward:

Sale = $1,000
Royalty = 5%
Creator = $50
Seller = $950

But royalty behavior is not uniformly enforced across every marketplace and trading environment.

This means royalty requirements need to be considered at both levels:

Smart Contract
+
Marketplace Integration

A technically correct royalty implementation does not guarantee identical behavior across every external marketplace.

This is one reason marketplace compatibility should be considered early rather than after the contract is deployed.

Immutable vs Upgradeable Contracts

Another architectural decision is whether the contract should be immutable or upgradeable.

An immutable contract provides a strong guarantee:

Deployed
↓
Logic stays fixed

An upgradeable architecture introduces:

Proxy
│
▼
Implementation
│
├── V1
├── V2
└── V3

Upgradeability can be useful when requirements are expected to evolve.

But it also introduces additional trust and security assumptions.

For example:

Who controls upgrades?
Can the administrator change ownership logic?
Can metadata behavior change?
Is the upgrade mechanism secured?
What happens if the upgrade key is compromised?

There is no universal answer.

The important thing is to make the trust model explicit before deployment.

Gas Is an Architecture Constraint

Every on-chain operation has a cost.

The cost can be affected by:

Blockchain network
Contract complexity
Storage operations
Minting model
Batch size
Current network demand

For large collections, this can influence whether you use:

One transaction per NFT

or a batch-oriented approach.

ERC-1155 can be particularly useful when many token types or quantities need to be managed efficiently.

This is why blockchain selection should happen before implementation rather than being treated as an infrastructure detail at the end.

The Architecture I Would Start With

For a typical NFT platform, I would separate responsibilities like this:

                     User
                      │
                      ▼
                Web / Mobile App
                      │
          ┌───────────┴───────────┐
          ▼                       ▼
       Wallet                  Backend
                                  │
                   ┌──────────────┼──────────────┐
                   ▼              ▼              ▼
               Metadata        Indexer       Marketplace
               Service           │
                   │             │
                   ▼             ▼
            IPFS / Storage   Application DB
                                  │
                                  │
                              Blockchain
                                  │
                       ┌──────────┴──────────┐
                       ▼                     ▼
                NFT Contract            Token Contract

The responsibilities stay clear:

Wallet → authorization
Frontend → user interaction
Backend → application logic
Smart contract → ownership + on-chain rules
Storage → metadata + assets
Indexer → blockchain read model
Marketplace → trading experience
Blockchain → settlement + ownership truth

This separation also makes it easier to replace individual components without redesigning the entire system.

The Hard Part Isn't Minting

Writing a basic NFT contract is not particularly difficult.

The difficult questions appear around the contract:

What exactly does the token represent?
Where does the metadata live?
Who can mint?
Can the contract be upgraded?
How is ownership indexed?
How are royalties handled?
What happens when the RPC provider fails?
How does the application reconcile pending transactions?
Which marketplaces support the required behavior?
What happens if metadata becomes unavailable?

In our blockchain work at SotaTek, these are often the questions that require more architectural consideration than the minting logic itself. The contract may only take a few functions to implement, but making the entire system reliable means thinking through storage, indexing, wallet flows, marketplace compatibility, and the boundary between on-chain and off-chain state.

These are architecture questions, not Solidity syntax questions.

That is why a production NFT implementation needs to consider smart contracts, metadata, storage, wallets, indexing, marketplaces, security, and blockchain infrastructure as one system.

Final Takeaway

An NFT is not an image stored on a blockchain.

It is better understood as a combination of:

Token Standard
+
Smart Contract
+
Ownership State
+
Metadata
+
Off-chain Storage
+
Wallet
+
Blockchain
+
Indexing

The blockchain provides verifiable ownership and transaction history.

The smart contract defines the rules.

The metadata describes the asset.

The wallet authorizes transactions.

The indexer makes blockchain state usable by applications.

And the marketplace connects that infrastructure to users.

Once you understand these boundaries, NFT development becomes less about “minting a token” and more about designing a system where on-chain truth and off-chain application state remain consistent.

For a broader overview of NFT token standards, development stages, use cases, and the cost factors involved in taking an NFT project from contract deployment to marketplace integration, this NFT token development guide provides additional context.

What Actually Happens When You Swap Tokens on a DEX?

SotaTek | AI & Blockchain Innovation Partner — Fri, 25 Sep 2026 09:10:29 +0000

A DEX can look deceptively simple from the frontend.

Select two tokens, enter an amount, click Swap, approve the transaction, and wait.

Underneath that button, however, several systems are working together:

User
│
▼
Wallet
│
▼
DEX Frontend
│
▼
Router / Smart Contract
│
├── Liquidity Pool
├── Token Contracts
└── Pricing Logic
│
▼
Blockchain
│
▼
Event Logs
│
▼
Indexer

Understanding this flow is useful because a DEX is not simply a UI connected to a smart contract.

It is a distributed trading system where pricing, liquidity, execution, settlement, and indexing all have different responsibilities.

Start With the Liquidity Pool

Consider a simple ETH/USDC pool.

The pool contains:

ETH → 10
USDC → 30,000

A trader wants to swap ETH for USDC.

In an AMM-based DEX, the trade does not need to find another trader willing to take the opposite side.

The trader interacts with the liquidity pool itself.

Liquidity providers supply the assets, and the AMM determines the exchange rate according to its pricing function.

A simplified constant-product model is:

x × y = k

Where:

x = reserve of token A
y = reserve of token B
k = invariant

Before the trade:

10 ETH × 30,000 USDC
= 300,000

Suppose the trader sends 1 ETH into the pool.

The new ETH reserve becomes:

x' = 11 ETH

The AMM needs to maintain the invariant:

11 × y' = 300,000

Therefore:

y' ≈ 27,272.73 USDC

The difference between the old and new reserves represents the amount of USDC that can be removed from the pool, before fees and other implementation details are applied.

This is the basic idea behind an AMM.

The important part is that the pool itself becomes the counterparty.

Price and Execution Price Are Not the Same

This is where things become more interesting.

The displayed price might look like:

1 ETH = 3,000 USDC

But that does not mean a trader can necessarily swap a large amount of ETH at exactly 3,000 USDC.

Why?

Because the trade changes the pool reserves.

A larger trade moves the pool further along its pricing curve.

This creates price impact.

There is also a difference between:

Market price
Quoted execution price
Price impact
Slippage tolerance

A production DEX needs to expose these clearly before the user signs the transaction.

For example:

Input: 1.0 ETH
Expected output: 2,970 USDC
Price impact: 0.8%
Minimum received: 2,940 USDC
Network fee: 0.002 ETH

These numbers are not just UI decoration.

They are part of the transaction safety model.

The Frontend Does Not Execute the Swap

The frontend calculates or retrieves a quote.

It does not ultimately control the token transfer.

The actual state transition happens through smart contracts.

A simplified flow is:

User
│
│ "Swap 1 ETH for USDC"
▼
Frontend
│
│ request quote
▼
Router
│
│ calculate route
▼
Smart Contract
│
│ execute swap
▼
Liquidity Pool
│
│ update reserves
▼
Blockchain State

The wallet signs the transaction.

The blockchain executes it.

The smart contract determines whether the requested operation is valid.

This distinction is important because the frontend should be treated as an untrusted interface.

Anyone can call the contract directly.

The contract itself must enforce the rules.

Token Approvals Add Another Transaction

For ERC-20 tokens, users typically need to authorize a contract to spend their tokens.

This creates an additional step:

User
│
▼
approve()
│
▼
Token Contract
│
▼
DEX Router
│
▼
swap()

So the first interaction with a token may require two transactions:

approve
swap

A production frontend needs to make this state understandable.

Otherwise users may see:

“Transaction successful”

and still wonder why the swap has not happened.

The frontend should distinguish between:

Approval confirmed
Swap pending
Swap confirmed
Swap failed

This is a small UX detail with a large operational impact.

The Router Is Where Things Get Interesting

A simple DEX might execute:

ETH → USDC

But users may not always get the best execution through a single pool.

A router can split or chain trades:

ETH
│
├── Pool A
│
▼
USDC
│
▼
Pool B
│
▼
DAI

Or:

ETH
│
├── 60% → Pool A
│
└── 40% → Pool B
│
▼
USDC

The router's job is to determine how the requested trade should be executed according to the available liquidity and routing logic.

This creates a trade-off.

More sophisticated routing can improve execution, but it also increases:

Gas consumption
Contract complexity
Failure modes
Simulation requirements
Security surface

The cheapest route computationally is not necessarily the route with the best execution price.

What Happens When the User Clicks "Swap"?

Let's follow the transaction.

Step 1: The frontend creates a transaction

The application prepares something conceptually similar to:

to:
DEX Router

method:
swapExactTokensForTokens()

parameters:
amountIn
amountOutMin
path
recipient
deadline
Step 2: The wallet asks for authorization

The user reviews the transaction and signs it.

The wallet produces a cryptographic signature proving that the account authorized the transaction.

Step 3: The transaction reaches the network

The transaction is broadcast to the blockchain network.

At this point it is not necessarily finalized.

It may be:

Pending
↓
Included in block
↓
Executed
↓
Confirmed / finalized

The frontend therefore needs to handle asynchronous transaction state rather than assuming that submission equals completion.

Step 4: The smart contract executes

The router calls the required contracts.

The transaction may involve:

Router
↓
Token A
↓
Pool
↓
Token B

Each contract call changes blockchain state.

If any required condition fails, the transaction reverts.

What Happens Inside the Pool?

The pool receives the input token.

Then the contract calculates how much output can be released while respecting its pricing rules.

Conceptually:

Before:

Token A reserve = 10
Token B reserve = 30,000

↓

Trader sends Token A

↓

AMM calculation

↓

After:

Token A reserve = 11
Token B reserve = ~27,272

The exact calculation depends on the AMM implementation.

Real protocols may also account for:

Trading fees
Concentrated liquidity
Multiple price ranges
Dynamic fees
Different invariant designs

So the simple x × y = k model is useful for understanding the concept, but it is not a complete representation of every modern AMM.

Where Do Liquidity Providers Fit?

The pool needs liquidity.

Liquidity providers deposit assets into the protocol and receive a claim representing their share of the pool.

Conceptually:

Liquidity Provider
│
├── Token A
└── Token B
│
▼
Liquidity Pool
│
▼
Traders

In return, LPs can receive a portion of trading fees according to the protocol's rules.

But providing liquidity is not risk-free.

LPs can be exposed to:

Impermanent loss
Smart contract risk
Asset volatility
Oracle risk
Protocol-specific risks

From an engineering perspective, liquidity is therefore not simply a feature.

It is part of the protocol's economic design.

The Blockchain Is the Source of Settlement Truth

After the transaction executes, the blockchain contains the resulting state.

For example:

Trader
↓
-1 ETH
+2,970 USDC

Pool
↓
+1 ETH
-2,970 USDC

The DEX frontend should not invent this state.

It should derive it from blockchain data.

That creates an important architecture:

Blockchain
│
├── Transactions
├── Events
└── Contract State
│
▼
Indexer
│
▼
Application DB
│
▼
DEX Frontend
Why You Need an Indexer

Reading raw blockchain data directly from the frontend becomes expensive and inconvenient as the application grows.

Consider a trading page that needs:

Historical trades
Token prices
Volume
Liquidity
User positions
Transaction history
Pool activity

You could query the blockchain repeatedly.

But that is not an efficient application architecture.

An indexer processes blockchain events and transforms them into application-friendly data.

For example:

Swap Event
│
▼
Event Listener
│
▼
Indexer
│
▼
Database
│
├── price history
├── volume
├── transactions
└── pool analytics

The blockchain remains the source of truth.

The indexed database becomes the query layer.

That distinction is important.

Events Are Part of the Integration Contract

Smart contracts can emit events such as:

event Swap(
address indexed sender,
uint256 amountIn,
uint256 amountOut
);

The event allows off-chain systems to observe state transitions without repeatedly reconstructing every operation from scratch.

But event processing needs to be designed carefully.

An indexer should account for:

Duplicate processing
Missed events
RPC failures
Chain reorganizations
Reprocessing
Idempotency

For example, processing the same Swap event twice should not create two trades in the database.

This is a distributed-systems problem hiding inside a DeFi application.

Slippage Is a Safety Mechanism

Suppose the frontend quotes:

1 ETH → 3,000 USDC

But market conditions change before the transaction is executed.

The user might receive:

1 ETH → 2,700 USDC

That may be unacceptable.

The transaction therefore includes a minimum acceptable output:

amountOutMin = 2,950 USDC

If the actual output falls below that threshold, the transaction reverts.

This is why slippage tolerance is more than a UI preference.

It becomes a parameter enforced by the smart contract.

The Mempool Creates Another Problem: MEV

There is a gap between:

User signs transaction

and:

Transaction is executed

During that period, the transaction may be visible to actors that can observe pending transactions.

This creates opportunities for Maximal Extractable Value (MEV).

One common example is a sandwich attack:

User's swap
│
▼
Attacker observes transaction
│
├── Buy before user
│
├── User executes at worse price
│
└── Sell after user

The result can be worse execution for the original trader.

DEX design therefore needs to consider:

Slippage limits
Transaction ordering
Private transaction mechanisms
Routing
Liquidity depth

MEV is not purely a smart-contract bug.

It is a consequence of how transaction ordering and public blockchains interact.

Gas Is Part of the Product

A technically correct swap can still provide a poor user experience if the transaction costs too much.

Gas usage depends on factors such as:

Number of contract calls
Storage operations
Routing complexity
Network conditions
Smart contract implementation

A simple swap may require relatively little computation, while a multi-hop or multi-contract transaction can be considerably more expensive.

This creates an important optimization question:

Is the better price worth the additional execution cost?

A routing algorithm that saves a user 5 USDC but costs an additional 8 USDC in gas is not actually improving execution.

The system needs to optimize for net user outcome, not just quoted token output.

Cross-Chain DEXs Add Another Trust Boundary

Supporting multiple blockchains sounds like a frontend feature.

It is not.

A cross-chain DEX may involve:

Chain A
│
▼
Bridge / Messaging Layer
│
▼
Chain B
│
▼
DEX / Liquidity

Now the system depends on additional components:

Bridges
Messaging protocols
Relayers
Multiple RPC providers
Multiple smart contract environments
Cross-chain liquidity

Every new dependency expands the attack surface.

Supporting ten chains is not simply ten times the configuration.

The security model becomes significantly more complex.

The Architecture I Would Start With

For a production-oriented AMM DEX, a reasonable architecture is:

                User
                  │
                  ▼
            Web / Mobile UI
                  │
        ┌─────────┴─────────┐
        ▼                   ▼
     Wallet              API Layer
                            │
                     ┌──────┴──────┐
                     ▼             ▼
                 Indexer       Analytics
                     │
                     ▼
                Application DB

                  Blockchain
                       │
         ┌─────────────┴─────────────┐
         ▼                           ▼
    Router Contract             Token Contracts
         │
         ▼
    Liquidity Pools

Each layer has a specific responsibility:

Frontend → interaction
Wallet → authorization
Smart contract → execution + settlement
Liquidity pool → available liquidity
Blockchain → state + finality
Indexer → queryable blockchain data
Database → application read model
Analytics → aggregated insights

Keeping these boundaries clear makes the system much easier to test, monitor, and evolve.

The Hard Part Isn't the Swap

Writing a basic swap contract is not the hardest part of building a DEX.

The difficult engineering problems appear around it:

How much liquidity is available?
How do we calculate a safe quote?
What happens when the transaction is delayed?
How do we handle failed transactions?
How do we prevent unauthorized actions?
How do we index millions of events?
How do we protect users against bad execution?
How do we manage MEV?
What happens when an RPC provider fails?
What changes when we add another chain?

The swap is only one state transition inside a much larger distributed system.

Final Takeaway

A DEX is best understood as a combination of:

Trading Logic
+
Liquidity
+
Smart Contracts
+
Wallets
+
Blockchain Infrastructure
+
Indexing
+
User Protection

The frontend makes the system look simple.

Underneath it, the protocol has to coordinate pricing, liquidity, authorization, execution, settlement, and off-chain data.

That is why DEX development is less about building a “swap page” and more about designing a reliable financial system around blockchain constraints.

The most important architectural question is not:

“How do we build a token swap?”

It is:

“Which parts of the trading system need to be trustless, which parts can remain off-chain, and how do we keep the two consistent?”

That decision shapes almost every other engineering choice.

For a broader overview of DEX architecture, trading models, development stages, and the infrastructure involved, see SotaTek's DEX Development guide.

Building an Enterprise AI Chatbot: What the Architecture Actually Looks Like

SotaTek | AI & Blockchain Innovation Partner — Thu, 24 Sep 2026 08:35:12 +0000

An enterprise AI chatbot is easy to demo.

Connect an LLM to a chat interface, add a system prompt, upload a few documents, and you have something that looks impressive in an afternoon.

Production is different.

The moment a chatbot needs to access private company data, respect user permissions, retrieve current information, call internal APIs, and operate reliably at scale, it stops being a simple LLM application.

It becomes a distributed system.

A practical architecture usually looks something like this:

                     User
                       │
                       ▼
                Chat Interface
                       │
                       ▼
                API / Gateway
                       │
                       ▼
             AI Orchestration Layer
                /      |       \
               /       |        \
              ▼        ▼         ▼
           RAG      Tools      Policies
            │         │           │
            ▼         ▼           ▼
      Knowledge DB  CRM/ERP   Access Control
            │         │
            └────┬────┘
                 ▼
                LLM
                 │
                 ▼
          Response / Action

The LLM is only one component.

The LLM Should Not Be Your Application Backend

A common first architecture looks like this:

User → LLM → Response

That works for general questions.

It breaks down as soon as the user asks:

“What is the status of my latest support ticket?”

The model does not inherently know the answer.

The application needs to:

Authenticate the user.
Determine what data the user is allowed to access.
Retrieve the relevant ticket.
Provide that context to the model.
Generate a response.
Return the result without exposing unauthorized data.

The architecture becomes:

User
│
▼
Authentication
│
▼
Authorization
│
▼
Application Backend
│
├── CRM / Ticketing API
├── Knowledge Base
└── AI Orchestrator
│
▼
LLM

This distinction is important:

The LLM generates language. The application owns the business rules.

Do not put authorization logic into a prompt and expect the model to enforce it.

RAG Is a Retrieval System First

Enterprise chatbots frequently use Retrieval-Augmented Generation (RAG) to answer questions from internal knowledge.

A simplified pipeline is:

Documents
│
▼
Ingestion
│
▼
Chunking
│
▼
Embeddings
│
▼
Vector Database

At query time:

User Query
│
▼
Embedding
│
▼
Retriever
│
▼
Relevant Documents
│
▼
Prompt + Context
│
▼
LLM
│
▼
Answer

The important engineering point is that RAG quality depends heavily on the retrieval layer.

If the wrong documents are retrieved, a more capable model does not automatically fix the problem.

That means production RAG needs to consider:

Chunking strategy
Metadata
Embedding model
Retrieval strategy
Top-K selection
Filtering
Document freshness
Source citations
Access permissions

A vector database is therefore not just a storage component. It is part of the answer-quality pipeline.

Authorization Must Happen Before Retrieval

This is one of the easiest mistakes to make in an enterprise RAG system.

Imagine a company has documents belonging to:

Finance
HR
Engineering
Sales

A user from Sales asks:

“Show me the latest compensation policy.”

If the retriever searches the entire vector database first and applies permissions afterward, sensitive HR content may already have entered the model context.

The safer flow is:

User
│
▼
Identity
│
▼
Permissions
│
▼
Filtered Retrieval
│
▼
Authorized Documents
│
▼
LLM

Access control should be part of retrieval itself.

For multi-tenant systems, this becomes even more important:

tenant_id = customer_123
user_role = manager
department = sales

These attributes should influence what the retrieval layer is allowed to return.

The model should never be responsible for deciding whether a user is authorized to see a document.

When RAG Is Not Enough

RAG works well when the chatbot needs to answer questions from relatively stable knowledge.

But consider:

“Create a support ticket for this issue.”

Retrieving documentation does not solve that problem.

The system needs to perform an action.

This is where tool calling or agentic workflows become useful.

User
│
▼
LLM
│
├── Search knowledge
├── Get customer
├── Create ticket
└── Check ticket status

The LLM decides which tool is relevant, but the tools themselves should expose controlled interfaces.

For example:

create_ticket(
customer_id,
category,
description
)

The model should not receive unrestricted database access.

Give it narrowly scoped capabilities.

This creates a useful principle:

Give the model tools, not infrastructure access.

Chatbot vs Agent

There is a meaningful architectural difference between answering and acting.

A traditional enterprise chatbot:

Question
↓
Retrieve
↓
Generate
↓
Answer

An agentic workflow:

Goal
↓
Plan
↓
Tool
↓
Observe
↓
Tool
↓
Observe
↓
Final Result

For example:

“Find the customer's last three orders, identify the delayed one, and open a support ticket.”

The system may need to:

Query CRM
Query order service
Compare delivery status
Generate ticket content
Create ticket
Return confirmation

That is no longer just a chatbot.

It is an orchestration system with an LLM as one of its decision-making components.

Keep the Tool Layer Deterministic

One of the most useful design principles for agentic systems is to keep tool execution deterministic.

For example:

LLM
│
│ create_ticket(...)
▼
Tool Gateway
│
├── Validate parameters
├── Check authorization
├── Apply business rules
├── Execute API call
└── Return structured result

Do not let the model directly execute arbitrary SQL or arbitrary HTTP requests.

Instead, expose explicit capabilities:

get_customer()
get_order()
search_policy()
create_ticket()
update_ticket()

This makes the system easier to secure, test, monitor, and audit.

Enterprise Data Is Usually the Hard Part

The LLM is often the easiest component to replace.

Enterprise data is not.

A real deployment may need to connect:

             AI Application
                   │
   ┌───────────────┼────────────────┐
   ▼               ▼                ▼
  CRM             ERP           Knowledge Base
   │               │                │
   ▼               ▼                ▼

Customer Data Transactions Documents

These systems often have different:

APIs
Authentication models
Data formats
Update frequencies
Failure modes
Rate limits

The AI layer therefore needs an integration boundary rather than a collection of ad-hoc API calls buried inside prompts.

Observability Is Part of the Architecture

A production chatbot should not only log:

user → response

You need to understand how the response was produced.

A useful trace might contain:

Request ID
User ID
Model
Prompt version
Retrieved documents
Tool calls
Latency
Token usage
Errors
Final response

For example:

Request
│
├── Retrieval: 180 ms
├── CRM API: 240 ms
├── LLM: 1.8 s
├── Tokens: 2,431
└── Total: 2.3 s

Without this information, debugging a bad answer becomes guesswork.

Observability also gives you the data needed to optimize cost and latency.

Evaluation Should Test the System, Not Just the Model

A model benchmark is not enough to determine whether an enterprise chatbot works.

You need to evaluate the complete pipeline:

Question
↓
Retrieval
↓
Context
↓
Model
↓
Tool Calls
↓
Response

Useful metrics include:

Retrieval relevance
Answer correctness
Citation accuracy
Hallucination rate
Tool-call accuracy
Task completion rate
Latency
Cost per request
Human escalation rate

A model can produce an excellent answer from the wrong document.

That is still a system failure.

A Production-Oriented Architecture

Putting the pieces together:

                     User
                       │
                       ▼
                ┌─────────────┐
                │ API Gateway │
                └──────┬──────┘
                       │
                Authentication
                       │
                       ▼
              ┌─────────────────┐
              │ AI Orchestrator │
              └───────┬─────────┘
                      /|\
                     / | \
                    /  |  \
                   ▼   ▼   ▼
                 RAG Tools Policy
                  │    │     │
                  ▼    ▼     ▼
               Vector CRM   AuthZ
               Store  ERP
                  │    │
                  └────┬┘
                       ▼
                      LLM
                       │
                       ▼
                Validation Layer
                       │
                       ▼
                    Response

Around the entire system, you also need:

Observability
Evaluation
Audit Logging
Rate Limiting
Secrets Management
Cost Controls

These are not optional production extras.

They are part of the system.

The Real Architecture Decision

The interesting question is not:

“Which LLM should we use?”

Models change quickly.

The more durable engineering decisions are:

Where does enterprise knowledge live?
How is it retrieved?
Where is authorization enforced?
Which actions can the model perform?
How are tool calls validated?
How do we handle failures?
How do we evaluate output quality?
How do we observe the complete request lifecycle?

Once these boundaries are clear, the underlying model becomes a replaceable component rather than the foundation of the entire architecture.

Final Takeaway

An enterprise AI chatbot is not an LLM with a chat UI.

It is an application architecture that combines:

LLM
+
RAG
+
Enterprise APIs
+
Access Control
+
Tool Calling
+
Observability
+
Evaluation

The LLM provides the language interface.

The surrounding system provides data, permissions, actions, and reliability.

That is the difference between a chatbot that looks impressive in a demo and one that can actually operate inside an enterprise environment.

If you're looking at the broader implementation lifecycle, including data preparation, architecture selection, enterprise integration, security, and deployment, this enterprise AI chatbot implementation guide provides additional context.

What Actually Happens When You Put an NFT Into a Game?

SotaTek | AI & Blockchain Innovation Partner — Thu, 24 Sep 2026 08:25:43 +0000

Putting an NFT into a game sounds simple:

Mint an NFT, connect a wallet, and let players trade it.

That is the easy part.

The difficult part is deciding what belongs on-chain, what stays off-chain, and how the two systems communicate without turning every gameplay action into a blockchain transaction.

A production NFT game is not a traditional game with a smart contract attached to it. It is a distributed system with two very different execution environments:

                NFT GAME
                   │
         ┌─────────┴─────────┐
         │                   │
     OFF-CHAIN             ON-CHAIN
         │                   │
    Game Engine         Smart Contracts
    Game Server         NFT Ownership
    Database            Token Balances
    Matchmaking         Asset Transfers
    Gameplay            Marketplace
         │                   │
         └─────────┬─────────┘
                   │
              Wallet / RPC

Once you look at it this way, many of the architecture decisions become much easier to reason about.

The Game Should Not Run on the Blockchain

The first mistake is trying to put gameplay logic on-chain.

Imagine a multiplayer game where every movement generates a blockchain transaction:

Player moves
↓
Transaction
↓
Validator
↓
State update
↓
Game server
↓
Other players

It would be slow, expensive, and completely unnecessary.

The blockchain is good at things that need shared, verifiable state.

A game engine is good at things that need fast, mutable state.

So the architecture should usually look more like this:

                 Game Client
                      │
          ┌───────────┴───────────┐
          │                       │
          ▼                       ▼
    Game Backend              Wallet
          │                       │
          ▼                       ▼
    Game Database            Blockchain
          │                       │
          │                ┌──────┴──────┐
          │                │             │
          │             NFT Contract  Token Contract
          │
          └─────── Asset State ──────────┘

The game server handles gameplay.

The blockchain handles ownership and other state that needs to be independently verifiable.

That boundary is probably the most important architectural decision in an NFT game.

What Actually Goes On-Chain?

A useful rule is:

Put the minimum amount of state on-chain that needs blockchain-level ownership, verification, or settlement.

For an NFT game, that might include:

Token ownership
NFT ID
Token metadata reference
Supply constraints
Transfer rules
Marketplace transactions
Royalty logic
In-game token balances

It usually should not include:

Player coordinates
Animation state
Matchmaking
Real-time combat
Chat
Temporary game state
Every player interaction

For example, a sword might exist as an NFT:

NFT #1842
│
├── Owner: 0xA91...
├── Token URI
├── Rarity
└── Asset ID

But the fact that the player currently has that sword equipped belongs in the game layer.

This gives you two states:

Blockchain:
"Wallet X owns Sword #1842"

Game server:
"Player 928 has Sword #1842 equipped"

The second state can change thousands of times without touching the blockchain.

The Smart Contract Is the Ownership Layer

The smart contract should be treated as the authoritative source for blockchain ownership.

A simplified NFT contract might look like:

contract GameItem is ERC721 {
uint256 private nextTokenId;

function mint(address player)
    external
    returns (uint256)
{
    uint256 tokenId = nextTokenId++;
    _safeMint(player, tokenId);
    return tokenId;
}

}

The important part is not the exact implementation.

It is the responsibility boundary.

The contract answers:

Who owns this asset?
Can it be transferred?
Can it be minted?
How many can exist?
What rules apply to the transfer?

The game server should not maintain a second independent truth about ownership.

If the database says:

Player A → Sword #1842

but the blockchain says:

Player B → Sword #1842

the system has a consistency problem.

For ownership, the blockchain should win.

What Happens When a Player Buys an NFT?

This is where the distributed architecture becomes interesting.

Suppose Player A buys an NFT from Player B.

A simplified flow is:

Player A
│
│ purchase
▼
Marketplace
│
│ transaction
▼
Blockchain
│
├── transfer NFT
├── transfer payment
└── emit event
│
▼
Indexer
│
▼
Game Backend
│
▼
Game Client

The blockchain transaction changes ownership.

The game backend then observes that change and updates its local representation.

This introduces an important concept:

Blockchain state and application state are eventually synchronized, not necessarily updated at exactly the same time.

That means the backend must handle:

Pending transactions
Failed transactions
Reorganizations
Duplicate events
Delayed confirmations
RPC failures

A production integration cannot simply assume:

sendTransaction()
↓
success = true
↓
updateDatabase()

The transaction lifecycle is asynchronous.

Events Are the Bridge

Smart contract events are useful for synchronizing blockchain activity with the game backend.

For example:

event ItemTransferred(
address indexed from,
address indexed to,
uint256 indexed tokenId
);

The backend can subscribe to blockchain events and update its internal state.

Conceptually:

Smart Contract
│
│ ItemTransferred
▼
Blockchain Node / RPC
│
▼
Event Listener
│
▼
Game Database
│
▼
Game API

This is much more scalable than having the game client repeatedly query the blockchain for every piece of state.

Wallets Are Not Just Login Buttons

Wallet integration is another place where traditional game architecture changes.

A wallet provides an address and, more importantly, control over the private key associated with that address.

The game might therefore use:

Game Account
│
├── player profile
├── progression
├── preferences
└── wallet address

The wallet address identifies the blockchain account, but it should not automatically become the entire identity system of the game.

For example:

Player ID: 92814
Wallet: 0xA91...

The backend can associate the two after a secure wallet-signature authentication flow.

This allows the game to maintain normal application functionality while using the wallet for blockchain ownership.

NFT Metadata Is Another Distributed-System Problem

The NFT itself may only contain a reference to metadata rather than storing every attribute directly on-chain.

Conceptually:

NFT
│
└── tokenURI
│
▼
Metadata
│
├── name
├── image
├── attributes
└── game asset reference

That creates another architectural question:

What happens if the metadata disappears or changes?

If the game depends on a centralized URL, the NFT may technically exist on-chain while the actual asset becomes unavailable.

For long-lived assets, the storage strategy therefore matters almost as much as the smart contract itself.

The blockchain can prove ownership.

It does not automatically guarantee that every piece of off-chain data associated with that ownership will remain available forever.

The Game Engine Is Still the Game Engine

Unity or Unreal Engine remains responsible for what it has always been good at:

Input
↓
Gameplay Logic
↓
Rendering
↓
Physics
↓
Audio
↓
Networking

Blockchain integration becomes another service boundary.

For example:

Unity / Unreal
│
▼
Blockchain SDK / Backend API
│
├── Wallet
├── NFT data
├── Marketplace
└── Smart contract calls

This separation is important.

You do not want blockchain-specific logic spread across hundreds of gameplay components.

Keep wallet operations, contract interactions, transaction state, and blockchain synchronization behind well-defined interfaces.

The Real Challenge Is Consistency

Once you have two state machines, consistency becomes the hard problem.

Consider this sequence:

Player buys NFT
Transaction submitted
Transaction pending
Game server receives request
Player closes the game
Transaction confirms
Backend misses the event
Player logs in again

What does the game show?

This is no longer simply a smart-contract problem.

It is a distributed-systems problem.

You need mechanisms for:

Event replay
Idempotent processing
Transaction status tracking
Confirmation handling
Reconciliation
Retry logic
RPC failover

A useful backend design is:

Blockchain
│
▼
Event Listener
│
▼
Message Queue
│
▼
Indexer
│
▼
Game Database
│
▼
Game API

The indexer becomes the bridge between blockchain state and application state.

Where the Economy Lives

NFT games often add another layer: fungible tokens.

You may have:

NFT
├── Characters
├── Weapons
├── Skins
└── Land

Token
├── Rewards
├── Purchases
└── Marketplace payments

This is where tokenomics becomes an engineering concern.

A reward mechanism that continuously creates tokens without corresponding demand can create an economic problem even if the smart contract is perfectly secure.

The technical architecture therefore has to support the economic model rather than treating tokenomics as a separate document.

Security Changes Everything

Traditional game security focuses heavily on the client and server.

Blockchain games add another security boundary:

Client
↓
Backend
↓
Smart Contract
↓
Blockchain

A vulnerability in a deployed contract can be fundamentally different from a server-side bug.

You cannot simply deploy a patch and assume the old state disappears.

Smart contracts handling NFTs, tokens, marketplace transactions, and royalties should therefore be treated as security-critical infrastructure.

At minimum, review:

Access control
Mint authorization
Transfer restrictions
Reentrancy
Integer handling
Signature validation
Replay protection
Upgradeability assumptions
Economic attack vectors

The blockchain layer should be audited independently from the game client.

The Architecture I Would Start With

For a typical NFT game, a reasonable starting architecture is:

                 ┌───────────────┐
                 │ Game Client   │
                 │ Unity/Unreal  │
                 └───────┬───────┘
                         │
                         ▼
                 ┌───────────────┐
                 │ Game Backend  │
                 └───────┬───────┘
                         │
           ┌─────────────┼─────────────┐
           ▼             ▼             ▼
      Game DB       Blockchain API   Marketplace
                         │
                         ▼
                     RPC Node
                         │
                         ▼
                 ┌───────────────┐
                 │ Smart Contract│
                 ├───────────────┤
                 │ NFT           │
                 │ Token         │
                 │ Marketplace   │
                 └───────────────┘

The important thing is not the number of components.

It is the ownership of responsibilities.

Game server → gameplay state
Database → application state
Blockchain → verifiable ownership and settlement
Smart contract → enforceable on-chain rules
Wallet → player-controlled blockchain identity
Indexer → synchronization

Once those boundaries are explicit, the system becomes much easier to scale and debug.

The Main Takeaway

An NFT game is not a game that happens to use NFTs.

It is a system where gameplay, blockchain state, wallets, smart contracts, and off-chain infrastructure have to agree on what is true.

The most important architectural decision is therefore not which blockchain to choose.

It is deciding:

What needs to be trustless, and what doesn't?

Put ownership and settlement where independent verification matters.

Keep high-frequency gameplay where low latency matters.

Use the backend and indexer to connect the two worlds.

That separation keeps the blockchain useful without forcing the entire game to behave like a blockchain.

And once you understand that boundary, NFT game development starts looking less like “adding Web3 to a game” and more like what it really is:

designing a distributed system with a game engine on one side and a blockchain on the other.

If you want to explore the broader NFT game development lifecycle, including asset design, tokenomics, smart contracts, wallet integration, and marketplace architecture, this NFT Game Development guide provides the wider context.

Zero-Knowledge Proofs Without the Magic: What the Prover and Verifier Actually Do

SotaTek | AI & Blockchain Innovation Partner — Mon, 14 Sep 2026 11:18:27 +0000

Zero-Knowledge Proofs Without the Magic: What the Prover and Verifier Actually Do

Zero-knowledge proofs are often described with a sentence that sounds almost impossible:

Prove that you know something without revealing what you know.

That description is correct, but it hides the part developers actually need to understand.

A zero-knowledge proof is not encryption. The prover does not simply hide some data and send it to the verifier.

Instead, the prover constructs a proof that a computation is valid, while revealing only the information that the protocol allows the verifier to see.

This distinction becomes important when ZK proofs are used in blockchain systems, where computation can be performed privately off-chain and verified cheaply on-chain.

Start With a Simple Problem

Suppose Alice knows a secret value x.

There is a public value derived from it:

y = hash(x)

Alice wants to prove:

“I know a value x such that hash(x) = y.”

But she does not want to reveal x.

A traditional solution would require Alice to reveal the secret:

Alice
  |
  | x
  v
Verifier
  |
  | hash(x) == y ?
  v
Valid

A zero-knowledge protocol changes the interaction:

             secret x
                |
                v
Alice       Prover
                |
                | proof
                v
           Verifier
                |
                v
        "The statement is valid"

The verifier learns that Alice knows a valid x, but does not learn x itself.

The interesting part is how the proof is constructed.

The Three Things You Need to Separate

When working with ZK systems, three concepts are easy to mix together:

1. The witness

The witness is the private information known by the prover.

In our example:

witness = x

The witness never needs to be exposed to the verifier.

2. The public inputs

These are values that the verifier is allowed to know.

public input = y

3. The statement

The statement defines what must be proven.

For example:

hash(x) == y

So the prover is effectively proving:

I know x
such that
hash(x) == y

without sending x.

That separation between witness, public inputs, and computation is one of the most useful mental models for understanding ZK systems.

A ZK Proof Is Really a Proof of Computation

This is where ZK becomes more interesting for blockchain developers.

Instead of thinking:

“I want to hide a value.”

Think:

“I want someone to verify that a computation was executed correctly without giving them all of the computation's private inputs.”

For example:

Private inputs
     |
     v
+-----------+
| Computation|
+-----------+
     |
     v
   Result
     |
     v
   Proof
     |
     v
+-----------+
| Verifier  |
+-----------+

The verifier does not need to reproduce the entire computation.

It only needs to verify the proof.

This is why ZK proofs are useful for blockchain scaling and privacy.

Where the Blockchain Fits

Blockchains are good at verification, but expensive as general-purpose computation environments.

Imagine a computation that requires millions of operations.

Executing all of them directly on-chain can be expensive.

A ZK-based architecture can move the expensive computation off-chain:

                 Off-chain
              ┌──────────────┐
              │   Prover     │
              │              │
Input ────────>│ Computation  │
              │              │
              │ Generate ZK  │
              │    Proof     │
              └──────┬───────┘
                     │
                     │ proof
                     v
              ┌──────────────┐
              │ Blockchain   │
              │              │
              │   Verifier   │
              └──────────────┘

The blockchain does not need to trust the prover.

It only needs to verify the proof.

This creates an important engineering trade-off:

Move computation off-chain, but preserve verifiability on-chain.

Why This Is Different From Encryption

A common misunderstanding is that ZK proofs are simply another form of encryption.

They solve different problems.

Encryption:

“Only authorized parties should be able to read this data.”

Zero-knowledge proof:

“You should be able to verify that this statement is true without learning my private information.”

You can also combine both techniques in the same system.

For example, sensitive application data can remain encrypted while a ZK proof demonstrates that the data satisfies a particular condition.

From Simple Examples to Real ZK Circuits

Real ZK systems don't usually express the computation as:

hash(x) == y

and stop there.

The computation is represented as a set of constraints.

Conceptually:

x ──> Constraint 1
 │
 ├──> Constraint 2
 │
 └──> Constraint 3
          |
          v
      Valid / Invalid

The proving system then transforms those constraints into a proof that can be verified without exposing the private witness.

Depending on the system, this can involve polynomial commitments, elliptic-curve operations, finite fields, and sophisticated proving algorithms.

You do not need to understand every mathematical detail to build a ZK application.

But you do need to understand the engineering boundary:

The circuit defines what is provable.

If the required business logic cannot be represented correctly in the circuit, the rest of the architecture does not matter.

The Cost Is Not Gone. It Has Moved.

This is one of the most important practical considerations.

ZK systems can reduce the amount of computation that needs to happen on-chain, but generating the proof can itself be computationally expensive.

A simplified cost model looks like:

                ZK Application
                      |
          +-----------+-----------+
          |                       |
          v                       v
   Proof Generation          Proof Verification
       expensive                 cheaper
      off-chain                  on-chain

This creates a trade-off between:

Prover compute
Proof generation time
Proof size
Verification cost
On-chain gas
Hardware requirements

The optimal design depends on the application.

A system that minimizes gas consumption may require significantly more off-chain computation.

A system optimized for proof-generation speed may have different hardware or circuit constraints.

There is no universal “ZK is cheaper” rule.

Where ZK Proofs Become Useful

The same architecture can support several classes of applications.

Private identity

A user could prove:

I satisfy eligibility condition X

without revealing every piece of information used to determine eligibility.

Private transactions

A system can prove that a transaction satisfies the required rules without exposing all transaction details publicly.

Scaling

A prover can execute a large amount of computation off-chain and submit a compact proof that the computation was performed correctly.

Verifiable computation

A service can perform computation for a user while providing cryptographic evidence that the result was generated according to a defined computation.

The common pattern is not simply privacy.

It is:

Compute privately or off-chain → generate proof → verify independently.

The Engineering Problems Are Different From Traditional Applications

ZK systems introduce constraints that are easy to underestimate.

Circuit complexity

The way you express an algorithm can have a major impact on proving cost.

An algorithm that is efficient in normal software may be expensive to represent as a ZK circuit.

Prover performance

Proof generation can require significant CPU, memory, or specialized hardware depending on the proving system and workload.

Data availability

In blockchain applications, proving that something is correct is not the same as making the underlying data available.

You still need to design how relevant data is stored, retrieved, and verified.

Smart contract integration

If proofs are verified on-chain, the verifier contract becomes part of the security-critical path.

Its interface, gas consumption, and failure handling need to be treated like any other production smart contract.

Key management

Some proving systems involve trusted setup assumptions or proving/verifying keys.

The security model of those components needs to be understood before deployment.

The Mental Model I Use

When evaluating a ZK architecture, I find it useful to reduce it to four questions:

1. What is private?
        ↓
2. What must be proven?
        ↓
3. Where is the computation executed?
        ↓
4. Where is the proof verified?

For example:

Private:
Customer eligibility data

        ↓

Prove:
Customer satisfies eligibility rules

        ↓

Compute:
Off-chain prover

        ↓

Verify:
Smart contract

If those four answers are clear, the rest of the architecture becomes much easier to reason about.

ZK Is Not a Magic Privacy Layer

Zero-knowledge proofs can provide powerful privacy and verification guarantees, but they do not automatically make an application private or secure.

The application still needs to handle:

Access control
Key management
Smart contract security
Data availability
Circuit correctness
Prover infrastructure
Client-side security
Protocol assumptions

A perfectly verified proof can still be part of a badly designed system.

The strongest ZK architectures are therefore not the ones with the most complicated cryptography.

They are the ones where the trust boundary is explicit.

Final Takeaway

The easiest way to understand zero-knowledge proofs is to stop thinking about them as a mechanism for “hiding data.”

Think of them as a way to establish:

“This computation was performed correctly, and I can prove it without revealing everything involved in that computation.”

That model explains why ZK proofs are useful for privacy, blockchain scaling, identity, and verifiable computation.

And it also explains the engineering trade-off: you are not eliminating computation—you are moving it to a place where it can be performed privately and then verified efficiently.

For a broader introduction to Zero-Knowledge Proofs, their privacy applications, and practical challenges, see SotaTek's Zero-Knowledge Proof in Blockchain guide.

AI Readiness Assessment for Developers: What to Check Before Building an AI System

SotaTek | AI & Blockchain Innovation Partner — Wed, 09 Sep 2026 10:52:58 +0000

Having access to an LLM API doesn't mean your application is ready for AI.

A team can have access to GPT, Claude, Gemini, or an open-source model and still fail to move beyond a proof of concept because of poor data quality, missing integrations, security gaps, unpredictable costs, or an architecture that cannot survive production workloads.

Before choosing a model, engineering teams should answer a more important question:

Is the system actually ready to support an AI workload?

An AI readiness assessment provides a structured way to evaluate that question before committing significant engineering resources.

Start With the Use Case, Not the Model

One of the most common mistakes is starting with model selection:

“Should we use GPT, Claude, or an open-source LLM?”

The better question is:

“What decision or workflow are we trying to improve?”

A well-defined AI use case should have:

A clear input and expected output
A measurable success criterion
A defined tolerance for errors
A known human fallback when necessary
A reason to use AI instead of deterministic logic

For example, “use AI for customer support” is too broad.

A more actionable definition is:

Generate a response draft using the customer's ticket history and product documentation, then require human approval before sending.

The second definition gives engineers something they can actually architect, test, and measure.

Evaluate Data Readiness

For most AI systems, data is a bigger constraint than model availability.

Before development, check:

Availability: Does the required data exist?
Quality: Is it accurate, consistent, and complete?
Accessibility: Can the application retrieve it reliably?
Freshness: How frequently does it change?
Structure: Is the data usable without extensive transformation?
Security: Can it legally and safely be exposed to the AI workflow?

For RAG-based systems, for example, simply having thousands of documents is not enough.

You also need a reliable ingestion pipeline, appropriate chunking, metadata, retrieval strategy, and access control.

A technically impressive RAG architecture built on unreliable source data will still produce unreliable answers.

Check Integration Readiness

AI rarely operates as an isolated component.

A production AI feature usually needs to interact with existing systems such as:

CRM or ERP platforms
Internal APIs
Databases
Authentication services
Document storage
Event queues
Third-party SaaS platforms

Evaluate whether these systems provide stable interfaces and sufficient access to the required data.

Pay particular attention to:

API rate limits
Authentication and authorization
Latency
Failure handling
Data synchronization
Legacy system constraints

If critical data is trapped inside an unreliable legacy system, the problem is not your LLM. The integration layer is the actual bottleneck.

Assess Infrastructure and Architecture

The infrastructure requirements depend heavily on the AI workload.

A simple API-based LLM feature may only require an application backend, while a more complex system could involve:

Client
↓
Application API
↓
AI Orchestrator
├── LLM
├── Vector Database
├── Business APIs
└── Tool / Function Calls
↓
Response + Observability

Before implementation, determine:

Where models will run
Where data will be stored
Whether GPUs are required
Expected request volume
Latency requirements
Scaling strategy
Availability requirements
Provider dependency and fallback options

Avoid over-engineering the first version.

A managed LLM API may be the right choice for an early production workload. Self-hosting becomes more attractive when requirements around cost, latency, data residency, model customization, or scale justify the additional operational complexity.

Treat Security as an Architecture Concern

AI introduces attack surfaces that traditional applications may not have.

An AI readiness assessment should consider:

PII and sensitive data handling
Model and API access control
Prompt injection
Data leakage
Secrets management
Tenant isolation
Audit logging
Output validation

Do not assume that an LLM understands your application's authorization model.

For example, if a user can only access documents belonging to their organization, the retrieval layer must enforce that constraint. It should not rely on the model to “remember” the rule.

Authorization belongs in the application architecture, not in the prompt.

Define Evaluation Before Development

A traditional application can often be tested against deterministic expected outputs.

AI systems are different.

The same input can produce multiple valid responses, and “looks good in a demo” is not a measurable quality standard.

Before building, define:

Evaluation datasets
Accuracy or relevance metrics
Hallucination criteria
Safety requirements
Latency targets
Acceptable failure rates
Human evaluation criteria

A simple evaluation pipeline might look like:

Input
↓
AI System
↓
Generated Output
↓
Automated Evaluation
↓
Human Evaluation (if required)
↓
Release / Reject

This becomes especially important when changing models, prompts, retrieval strategies, or system instructions.

Without a regression evaluation set, every AI change is partly a production experiment.

Plan for Production Operations

A successful proof of concept answers:

“Can we make it work?”

A production system needs to answer:

“Can we operate it reliably?”

At minimum, monitor:

Latency
Error rates
Token usage
Cost per request
Model failures
Retrieval quality
Output quality
User feedback

Version prompts, system instructions, model configurations, and evaluation datasets just as you would version application code.

Also design explicit fallback paths.

For example:

Primary LLM
↓
Failure / Timeout
↓
Fallback Model
↓
Human Escalation

The goal is not to eliminate every AI failure. The goal is to contain failures so they do not become system failures.

A Practical AI Readiness Checklist

Before starting implementation, engineering teams should be able to answer “yes” to most of these questions:

If several answers are “no,” building the AI feature immediately may create more technical debt than business value.

The engineering layer is only part of the equation; this AI Readiness Assessment looks at the organizational, data, and business factors that also determine whether an AI initiative is ready to move forward.

From Readiness Assessment to Production

AI readiness is not about achieving a perfect score.

It is about identifying the constraints that could prevent an AI system from delivering reliable value.

A practical path is:

Assess
↓
Identify Gaps
↓
Prioritize Use Case
↓
Design Architecture
↓
Build PoC
↓
Evaluate
↓
Harden
↓
Deploy
↓
Monitor & Iterate

The most important decision is often not which AI model to use, but whether the surrounding system is ready to use one effectively.

Good AI engineering starts before the first API call.