What Sekura Noda Assurance Can Do

AI Summary: Sekura Noda Assurance connects engineering requirements and claims to specifications, exact implementation revisions, verification runs, and supporting evidence. Teams can define evidence coverage policies, track whether evidence is current or stale, seal confirmed records, preserve immutable project baselines, analyze the impact of changes, and export structured evidence. Noda records verification performed in a project’s own environment; it does not run compilers or verifiers, and it does not itself establish compliance or certification against standards such as IEC 61508, IEC 62443, ISO 26262, DO-178C, or DO-254.

For a complex engineering system, it is not enough to know that the code builds, tests pass, or individual checks return successful results.

Over time, a more difficult question appears:

Which exact requirement was checked, which version of the implementation satisfied it, how was it verified, and which evidence applies to that specific version?

Sekura Noda Assurance is designed to preserve and connect this evidence history. You can explore the platform at noda.sekura.world.

It links requirements, specifications, implementations, verification activities, and supporting artifacts into one traceable system.

The basic chain is:

Requirement → Specification → Implementation → Verification → Evidence

A specific state of the project can then be preserved as an immutable Baseline.

Requirements and Claims

Assurance starts by making explicit what must be true about the project.

This may be:

  • a functional requirement;
  • a safety requirement;
  • an architectural constraint;
  • a property of a software or hardware component;
  • a verifiable engineering claim.

In Sekura Noda, these can be represented as Claims or Requirements.

The important part is not only recording the requirement itself, but maintaining it as a structured project object with versions, status, relations, and supporting evidence.

A requirement therefore stops being just a line in a document. It becomes an object that can be connected to a specification, implementation, verification activity, and Evidence.

Connecting Specifications and Implementations

The next step is to define exactly what is being verified and which implementation the result applies to.

Assurance can keep references to exact versions of:

  • formal specifications;
  • source code;
  • RTL;
  • other engineering artifacts.

For formal verification in the Sekura stack, SJV can be used to describe properties that must be checked.

The key principle is version precision.

It is not enough to say:

This processor property was verified.

The system should be able to say:

This property was verified against this exact SJV, this exact implementation revision, and these exact input conditions.

Assurance preserves that connection.

Verification Runs

Sekura Noda does not run compilers, test suites, formal verifiers, or build systems on behalf of the project owner. Verification is performed in the project’s own local or controlled environment.

After a check is performed, Assurance records a Verification Run.

A Run may contain:

  • exact input revisions;
  • the tool that was used;
  • the tool version;
  • verification configuration;
  • verification scope;
  • the result;
  • related reports and artifacts.

This means Noda does not merely store the statement, “We verified this at some point.” It stores the record of a specific verification activity performed against specific inputs.

Four Evidence Profiles

Different engineering claims require different forms of support. Sekura Assurance therefore distinguishes several Evidence profiles.

FORMAL

FORMAL is used for the result of formal verification.

Such Evidence can be connected to:

  • a specific SJV;
  • a specific implementation revision;
  • a completed Verification Run;
  • a PASS result;
  • an SJP verification artifact.

FORMAL means that a formal verification result has been recorded for the specified inputs and scope. It does not automatically prove a broader claim about the entire system. The boundaries of the proof remain part of the Evidence.

TESTED

TESTED records the result of testing.

Assurance can preserve:

  • exact revisions;
  • the executed Run;
  • the test report;
  • the result.

This makes it possible to determine exactly which versions were tested and which requirement the result supports.

REPRODUCIBLE

REPRODUCIBLE is used for reproducibility.

A project can, for example, preserve:

  • source code;
  • toolchain;
  • build parameters;
  • the resulting output artifact;
  • its hash.

A repeated build with the same inputs can then be compared against the original output. This is important where it is necessary to control not only source code but also the process that produces the final software or hardware artifact.

REVIEWED

REVIEWED represents engineering review performed by a person.

It can preserve:

  • the revision that was reviewed;
  • the review scope;
  • the decision;
  • comments;
  • the reviewer identity.

This means engineering review can become part of the traceable evidence history instead of existing only in conversations or commit comments.

Coverage Policy

Not every requirement needs the same kind of verification.

For one requirement, TESTED may be sufficient. Another may require FORMAL. A third may require a combination such as:

TESTED + REPRODUCIBLE

Sekura Assurance allows the project to define such a coverage policy. The system can then determine the state of each Claim or Requirement.

The main outcomes are:

  • COVERED — the required Evidence exists and satisfies the configured policy;
  • GAP — the required support is incomplete;
  • UNSUPPORTED — the current Evidence configuration cannot satisfy the selected policy.

This turns the evidence base from a collection of files into something that can be analyzed systematically.

Evidence Freshness

A successful verification result should not be treated as valid forever.

Source code changes. Specifications change. Tests, compilers, toolchains, and build parameters change.

Sekura Assurance therefore tracks the freshness of Evidence relative to the current project context.

Evidence can be:

  • CURRENT — its pinned inputs still match the current project context;
  • STALE — relevant inputs have changed;
  • UNKNOWN — there is not enough information to determine freshness.

This makes it possible to distinguish between:

This property was verified at some point.

and:

This property is supported for the current version of the system.

Traceability

One of the central purposes of Assurance is traceability.

For a significant system property, it should be possible to follow the chain:

Requirement → Specification → Implementation → Verification → Result → Evidence

And also in the opposite direction:

Evidence → Run → Implementation Revision → Specification → Requirement

This becomes especially important in projects where the exact engineering history may need to be reconstructed months or years later.

Without traceability, tests, reports, formal proofs, and source revisions gradually become separate artifacts whose relationships must be reconstructed manually. Sekura Noda preserves those relationships as part of normal development.

Evidence Confirmation and Sealing

Before Evidence becomes final, it can be explicitly confirmed.

The project can define which principals are allowed to provide those confirmations. Once the required confirmations exist, Evidence can be sealed.

During sealing, Assurance checks the required relations and profile-specific conditions. For FORMAL Evidence, for example, the system checks for a successful Run, the exact input revisions, and the corresponding SJP.

After sealing, the Evidence record becomes immutable.

If the system later changes, the old Evidence is not rewritten. It may instead become STALE, while new Evidence is created for the new version.

Baselines

Individual Evidence records support specific requirements or verification results. Serious engineering projects often need to preserve the state of the entire evidence base.

Sekura Assurance does this through Baselines.

A Baseline is an immutable snapshot of a project that can include:

  • requirements;
  • revisions;
  • Evidence;
  • coverage policy;
  • coverage outcomes.

Baselines can be compared. This makes it possible to see:

  • which requirements changed;
  • which implementation revisions changed;
  • which Evidence was added;
  • which previously supported properties may have been affected.

A Baseline turns the evidence base into a versioned history of the project.

Impact Analysis and Gap Detection

When a requirement, specification, or implementation changes, it is important to understand which supporting Evidence may be affected.

Sekura Assurance supports graph-based traceability and impact analysis. Instead of manually reviewing many separate documents, a project can identify:

  • which Evidence is connected to a changed object;
  • which verification results refer to old revisions;
  • where new GAPs have appeared;
  • which properties require verification again.

This becomes increasingly important as the number of requirements and verification activities grows beyond what can be tracked manually.

Exporting the Evidence Base

Assurance data can be exported.

A Baseline or the current state of a project can be represented in a machine-readable form together with version and relationship information. This makes Noda usable not only as an internal database, but also as a source of structured engineering evidence.

Exported artifacts can also be checked using file size and SHA-256.

Why We Are Building Assurance

Sekura Assurance is not intended to make the statement:

Our product is certified.

Its purpose is different. We want the evidence history to be created at the same time as the system itself.

Instead of:

Build the product first → reconstruct requirements and evidence later

the development process becomes:

Requirement → Implementation → Verification → Evidence

as part of normal engineering work.

This creates a foundation for projects that may later need stronger assurance, safety, or security engineering processes.

Sekura Noda Assurance can help create a structured evidence base for such processes, but it does not by itself mean compliance with IEC 61508, IEC 62443, ISO 26262, DO-178C, DO-254, or other standards, and it does not replace industry-specific assessment or certification.

From Knowledge to Evidence

A traditional knowledge base answers:

What do we believe to be correct?

Sekura Noda Assurance adds another question:

Why do we consider this claim supported for this specific version of the system?

The evolution of Noda can therefore be represented as one chain:

Knowledge → Requirement → Specification → Implementation → Verification → Evidence

For a small project, the first parts may be sufficient. For a complex engineering system, the full chain, its versions, freshness, and traceability become increasingly important.

That is what Sekura Noda Assurance is designed to provide. Learn more at noda.sekura.world.