Modules

How system capabilities are applied in context

Zebsoft uses Modules to apply system capabilities within a specific Domain, standard, or operational context.

Modules are not standalone tools and they are not new functionality.
They are configured applications of a Capability, aligned to a defined governance purpose.

This page explains what Modules are, how they work, and why they allow Zebsoft to scale without fragmentation.

How system capabilities are applied in context
The structural model

What a Module Is

A Module is a contextual application of a Capability.

It defines:

 

  • Where a Capability is being used
  • Why it is being applied
  • What rules, structure, and evidence apply

 

Modules answer the question:

“How does this capability work for this specific responsibility or requirement?”

They allow the same functional engine to behave appropriately in different governance contexts.

Why Modules Exist

Without Modules, systems tend to fragment:

  • Separate audits for each standard
  • Multiple risk registers for the same organisation
  • Duplicated documents and evidence
  • Inconsistent processes across departments

Modules prevent this by:

  • Reusing shared Capabilities
  • Applying context without duplication
  • Preserving a single source of truth
  • Maintaining consistent governance rules

This is what enables integrated management systems to function properly.

How Modules Work in Practice

Domains define areas of organisational responsibility.

Modules sit between Capabilities and Domains.

  • Capabilities define what work can be done
  • Domains define where responsibility sits
  • Modules define how that work is applied in context

A Module configures:

  • Structure (fields, logic, workflow)
  • Scope (what applies and what doesn’t)
  • Evidence requirements
  • Visibility and access rules

The underlying Capability remains the same.

Examples of Modules

Risk Modules

The Risk Capability can be applied through different Modules, such as:

  • Information Security Risk
  • Health & Safety Risk
  • Environmental Risk

Each Module applies different context, while sharing the same risk engine.

Audit Modules

The Audit Capability can be applied through Modules such as:

  • Internal Audit
  • Supplier Audit
  • Compliance or Standard-Specific Audit

Audit evidence can be reused across Domains without duplication.

Document Control Modules

The Document Control Capability can be applied through Modules such as:

  • Policy Management
  • Procedures and Work Instructions
  • External Document Registers

Approval, versioning, and visibility rules remain consistent.


Incident Modules

The Incident Capability can be applied through Modules such as:

  • Health & Safety Incidents
  • Information Security Incidents
  • Non-conformances and Near Misses

Each Module applies different classification and reporting logic.

Modules and Standards

Modules are not standards, but they support them.

A single Module can:

  • Support multiple clauses
  • Feed evidence into multiple certifications
  • Align to different regulatory frameworks

This allows organisations to manage compliance once, then demonstrate it many times.

Modules and Shield Levels

The number and complexity of active Modules depends on the Shield Level in use.

  • Foundation typically uses a smaller set of Modules
  • Growth introduces additional Modules and advanced logic
  • Enterprise applies Modules across internal and external Portals

The Module concept itself remains unchanged at every level.

Modules and Evidence Integrity

Because Modules reuse Capabilities:

  • Evidence is consistent
  • Audit trails are continuous
  • Data is not duplicated
  • Accountability is preserved

This ensures that growth never compromises control.

Where to Go Next

To explore how Modules are used across the platform:

 

  • Domains — how Modules support areas of responsibility
  • Capabilities — the functional engines behind each Module
  • System Structure — how Modules fit into the overall architecture