MyZubster Is Not Trying to Build Another App — We’re Exploring a Verifiable Digital Ecosystem

MyZubster Is Not Trying to Build Another App — We’re Exploring a Verifiable Digital Ecosystem MyZubster 并非旨在开发另一款应用程序，我们正在探索一个可验证的数字生态系统。

For years, software development has largely followed the same pattern: User → Application → Database → Service. AI changed part of that equation. IoT changed another part. Blockchain introduced new models for provenance and ownership. But there is still a difficult problem connecting all of them: How can a digital system verify what actually happened in the real world? This is one of the questions driving the development of MyZubster. 多年来，软件开发基本遵循着相同的模式：用户 → 应用程序 → 数据库 → 服务。人工智能改变了这一等式的一部分，物联网改变了另一部分，区块链则引入了关于溯源和所有权的新模型。但将它们连接起来仍存在一个难题：数字系统如何验证现实世界中实际发生的事情？这正是推动 MyZubster 开发的问题之一。

MyZubster is an Italian open-source digital ecosystem currently under development. It hasn’t reached its final public form yet. And that’s important. Because we’re not presenting a finished platform. We’re documenting how the architecture evolves. MyZubster 是一个目前正在开发中的意大利开源数字生态系统。它尚未达到最终的公开形态，这一点很重要。因为我们展示的不是一个成品平台，而是在记录其架构的演进过程。

From application to ecosystem

从应用程序到生态系统

Calling MyZubster simply an “app” increasingly feels incomplete. The architecture we’re exploring connects several layers: 仅仅将 MyZubster 称为“应用程序”已显得不够全面。我们正在探索的架构连接了多个层面：

(Diagram omitted for brevity) (此处省略图表)

The goal isn’t to put every technology imaginable into one application. The interesting part is the connection between these layers. 我们的目标不是将所有能想到的技术都塞进一个应用程序里，真正有趣的部分在于这些层面之间的连接。

AI needs evidence

人工智能需要证据

Generative AI can produce extraordinary outputs. But generation and verification are fundamentally different operations. An AI system can say: “This intervention reduced water consumption by 30%.” But where did that number come from? What sensor produced the original measurement? What period was compared? What methodology was used? Was the dataset modified? Can somebody reproduce the calculation? 生成式人工智能可以产生非凡的输出，但生成与验证是本质上不同的操作。人工智能系统可能会说：“这项干预措施将用水量减少了 30%。”但这个数字从何而来？是哪个传感器产生了原始测量值？对比的是哪个时期？使用了什么方法论？数据集是否被修改过？有人能复现这个计算过程吗？

This leads to a principle we’re increasingly using when thinking about MyZubster: AI ≠ Source of Truth. Instead: Evidence ↓ AI ↓ Interpretation ↓ Verification ↓ Decision. AI becomes a tool operating on evidence, rather than a machine expected to manufacture truth. 这引出了我们在思考 MyZubster 时日益遵循的一项原则：人工智能 ≠ 真理来源。相反，应该是：证据 ↓ 人工智能 ↓ 解读 ↓ 验证 ↓ 决策。人工智能应成为处理证据的工具，而不是被期望用来制造真理的机器。

Connecting software to physical reality

将软件与物理现实连接

This becomes particularly interesting with IoT. Imagine an environmental pilot containing: soil sensors, water meters, weather data, field observations, images, timestamps, GPS/context information. Collecting those values isn’t enough. We need provenance. A measurement should ideally answer: WHAT was measured? WHERE? WHEN? BY WHICH DEVICE? USING WHICH METHOD? WHO/WHAT processed it? WHAT transformation occurred? CAN IT BE REPRODUCED? Only then can we begin transforming raw measurements into meaningful digital evidence. 这一点在物联网领域尤为引人注目。想象一个包含土壤传感器、水表、气象数据、实地观测、图像、时间戳、GPS/环境信息的环境试点项目。仅仅收集这些数值是不够的，我们需要溯源。理想情况下，一次测量应该回答：测量了什么？在哪里？何时？由哪个设备？使用什么方法？由谁/什么处理？发生了什么转换？可以复现吗？只有这样，我们才能开始将原始测量值转化为有意义的数字证据。

Why we’re exploring MRV

为什么我们正在探索 MRV

This is also why we’re increasingly interested in MRV: Measurement, Reporting and Verification. A simplified pipeline might look like: REAL EVENT ↓ MEASUREMENT ↓ RAW DATA ↓ PROVENANCE ↓ PROCESSING ↓ KPI ↓ REPORT ↓ VERIFICATION. This model is useful far beyond environmental projects. It could eventually matter for: sustainability, circular economy, agriculture, digital identity, decentralized systems, IoT, supply chains, community contributions, public-interest infrastructure. 这也是我们对 MRV（测量、报告和验证）越来越感兴趣的原因。一个简化的流程可能如下：真实事件 ↓ 测量 ↓ 原始数据 ↓ 溯源 ↓ 处理 ↓ KPI ↓ 报告 ↓ 验证。该模型在环境项目之外也大有可为，它最终可能应用于：可持续发展、循环经济、农业、数字身份、去中心化系统、物联网、供应链、社区贡献以及公共利益基础设施。

The LIFE 2027 direction

LIFE 2027 的方向

We’re currently exploring whether a focused part of this architecture could eventually support a future LIFE 2027 proposal. The important word is exploring. This is not an announcement of EU funding or a finalized consortium. The work happening now is about understanding what could realistically be measured and validated. We’re beginning conversations around areas such as environmental data, agronomic information, circular water, irrigation reuse, scientific methodology, KPI/MRV and data governance. 我们目前正在探索该架构的某个重点部分是否最终能支持未来的 LIFE 2027 提案。“探索”一词至关重要。这并非欧盟资金的公告，也不是最终确定的财团。目前的工作重点是了解哪些内容可以被切实地测量和验证。我们正围绕环境数据、农学信息、循环水、灌溉回用、科学方法论、KPI/MRV 以及数据治理等领域展开对话。

The question isn’t: How do we fit MyZubster into a European project? The better question is: Is there a measurable environmental problem where this architecture can demonstrate something useful? That’s a much harder question. And therefore a much more interesting engineering problem. 问题不在于：我们如何将 MyZubster 塞进一个欧洲项目中？更好的问题是：是否存在一个可测量的环境问题，能够通过该架构展示出有用的成果？这是一个更难的问题，因此也是一个更有趣的工程挑战。

Open source becomes part of verification

开源成为验证的一部分

Open source normally means that people can inspect the code. But imagine extending that principle. Developers inspect the implementation. Researchers inspect the methodology. Machines inspect structured evidence. Communities inspect results. Independent contributors attempt reproduction. CODE + DATA + METHODOLOGY + EVIDENCE + REPRODUCIBILITY = TRUST. Not absolute trust. Inspectable trust. That distinction matters. 开源通常意味着人们可以检查代码。但试想一下扩展这一原则：开发者检查实现，研究人员检查方法论，机器检查结构化证据，社区检查结果，独立贡献者尝试复现。代码 + 数据 + 方法论 + 证据 + 可复现性 = 信任。不是绝对的信任，而是可审查的信任。这种区别至关重要。

GitHub isn’t just where the code lives

GitHub 不仅仅是存放代码的地方

In this architecture, repositories can become part of the project’s historical record. Commits document changes. Pull requests document discussion. Issues document problems. CI documents whether assumptions survive automated tests. Releases document specific states of the system. This doesn’t make GitHub a source of real-world truth. But it can provide something extremely valuable: software provenance. And software provenance can be connected to data provenance. 在这种架构中，代码仓库可以成为项目历史记录的一部分。提交记录变更，拉取请求记录讨论，问题记录故障，持续集成（CI）记录假设是否经受住了自动化测试，发布版本记录系统的特定状态。这并不会让 GitHub 成为现实世界的真理来源，但它能提供极其宝贵的东西：软件溯源。而软件溯源可以与数据溯源相连接。

Failure needs to remain visible

失败需要保持可见

There’s another principle we’re trying to preserve. If everything always appears successful, the evidence isn’t very useful. Tests must be allowed to fail. Experiments must be allowed to produce negative results. AI conclusions must be challengeable. Scientific hypotheses must be falsifiable. Open-source contributors must be able to say: “This doesn’t work.” A trustworthy system isn’t one where failure disappears. It’s one where failure becomes observable information. 我们还试图坚持另一项原则：如果一切看起来总是成功的，那么证据就没有多大用处。测试必须允许失败，实验必须允许产生负面结果，人工智能的结论必须可以被质疑，科学假设必须是可证伪的。开源贡献者必须能够说：“这行不通。”一个值得信赖的系统不是让失败消失的系统，而是让失败成为可观察信息的系统。

What exists today?

目前有哪些成果？

MyZubster remains under active development. There is code. There are repositories. There are experimental components. There are prototypes. There are architectural proposals. And there are ideas that still need to survive contact with reality. Those categories shouldn’t be confused. We don’t want to call a roadmap feature “production.” MyZubster 仍处于积极开发中。我们有代码、有仓库、有实验性组件、有原型、有架构提案，还有一些仍需经受现实考验的想法。这些类别不应混淆。我们不想将路线图中的功能称为“生产环境”。