TrustSurface Framework Governance Framework for Digital Trust
v1.1 public draft
Home/Governance/Consultation and Contribution Guidance
Governance

Consultation and Contribution Guidance

How to give feedback and contribute to the framework.

TSF-CNS-1 Operational

1. Purpose

This document explains how to engage with the TrustSurface Framework - whether by providing feedback through consultation channels or by contributing proposed changes directly. Both modes are welcome and actively encouraged.

2. Consultation

TrustSurface is published openly to encourage shared vocabulary and practical improvement.

If you have feedback, use one of the following:

  • raise an issue in the repository (preferred for traceable discussion)
  • submit a pull request with proposed edits

Repository: https://github.com/Bchetcuti/trust-surface-framework

2.1 What feedback is most useful

  • unclear definitions (where terms are ambiguous)
  • missing trust signals (baseline set gaps)
  • governance failure modes you repeatedly see in practice
  • improvements to the one-page specification and worked examples

2.2 Guardrails

TrustSurface is intended to remain:

  • neutral (not product-led)
  • evidence-based
  • usable by boards and practitioners
  • implementable without proprietary tooling

3. Contributing

Thanks for taking the time to review the TrustSurface Framework (TSF).

This repository is published for consultation and improvement. Contributions are welcome, particularly from:

  • board and executive governance roles
  • risk and compliance professionals
  • cybersecurity and IT leadership
  • procurement / vendor governance
  • NFP and public-interest organisations

3.1 What feedback is most valuable

Please focus on practical, adoption-oriented critique:

  1. Board usability

    • Is it explainable in 3–5 minutes?
    • Would a board understand the reporting outputs?

  2. Signal quality

    • Are signals measurable and observable?
    • Are they too technical or too vague?

  3. Lifecycle practicality

    • Can organisations realistically implement this without a major program?

  4. Language and framing

    • Does “Trust Surface” land as intended?
    • Where does it risk being misunderstood as “attack surface rebranding”?

3.2 How to contribute

Create an Issue using one of these prefixes:

  • [Clarity] confusing wording, definitions, structure
  • [Signal] add/remove/refine trust signals
  • [Lifecycle] improvements to the lifecycle/adoption model
  • [Governance] board/reporting/risk integration changes
  • [Example] suggested use-case or scenario to include

Option B: Pull Requests

If you want to propose text changes directly:

  • Keep edits small and focused
  • Avoid introducing large new sections without discussion
  • Preserve the “board-readable” tone (minimal jargon)

3.3 Contribution principles

  • Prefer clarity over completeness
  • Prefer observable/measurable over theoretical
  • Prefer small additions over long lists
  • Avoid turning the framework into a compliance checklist

3.4 Scope boundaries

To keep v1.1 coherent, the following are out of scope unless explicitly planned:

  • formal certification programs
  • scoring that implies a definitive “safe/unsafe” label
  • vulnerability scanning guidance (this is not a pentest framework)

3.5 Code of Conduct

Be constructive and respectful. Assume good intent. Focus critique on the framework, not individuals.

  • TSF-CHG-1 - Public Changelog and Release Notes (where accepted normative changes are recorded)
  • TSF-LIC-1 - Licence (terms governing reuse and attribution)
  • TSF-CIT-1 - Citation Guidance
  • TSF-SEC-1 - Security and Vulnerability Disclosure
  • TSF-REG-1 - Framework Register

Summary statement

TSF-CNS-1 describes how to engage with the TrustSurface Framework through feedback, issue submission, or direct contribution. It establishes guardrails to keep the framework neutral, evidence-based, and board-usable across v1.1 development.