Standards Policy

1. Purpose

This policy defines the operational standards that govern how Fidamen builds systems, publishes research, and delivers outputs. Every claim made on this site — including "decision-grade", "audit-ready", and "traceable" — maps to a specific standard documented below.

2. Decision-grade outputs

Claim: "Decision-grade outputs" — used on the homepage and systems pages.

Standard: An output qualifies as decision-grade when it satisfies all of the following criteria:

• Inputs are documented and versioned
• The computational model is inspectable — no opaque transformations
• Assumptions are explicitly declared in the output metadata
• Results are reproducible given the same inputs and model version
• Errors are detectable through automated validation gates

Relation to claims: See Decision Integrity for the formal six-dimension framework (Accuracy, Contextualization, Explainability, Auditability, Robustness, Governance).

3. Audit readiness

Claim: "Audit-ready delivery" — used in system and platform descriptions.

Standard: Audit readiness requires that every deliverable meets the following controls:

• Version control: All system logic, data schemas, and configuration are maintained under version control with commit-level traceability
• Input/output contracts: Each system component declares typed input and output contracts; no implicit data flows
• Change log: All material changes to logic or data sources are logged with date, author, and rationale
• Validation gates: Outputs pass through automated quality checks before publication or delivery
• Assumption disclosure: Published outputs include an explicit assumptions section identifying scope, limitations, and boundary conditions

Limitation: Fidamen does not hold external audit certifications (e.g. ISO 27001, SOC 2). "Audit-ready" refers to the structural traceability of outputs, not to third-party certification status. See Legal Notice §5 for the full security disclosure.

4. Release and versioning policy

Claim: "Release policy" — referenced on the Decision Integrity page.

Standard:

• MAJOR releases (logic-breaking changes): require formal review, documented rationale, and regression testing before deployment
• MINOR releases (additive changes): reviewed and tested; do not alter existing output contracts
• PATCH releases (corrections): logged, tested, and deployed with change notes

Publications follow a single-release model: each paper is published as a discrete release and updated only when material assumptions change. Working papers are explicitly marked as documents under active development.

5. Methodology standards

Claim: "Applied research that validates system architectures" — used on the homepage and about page.

Standard: All publications must meet the following criteria before publication:

• Classified by document type: Essay, White Paper, Technical Note, or Working Paper
• Explicit declaration of assumptions, scope, and limitations
• Traceable references to the system components they support
• Formal definitions where domain terminology is introduced
• Working papers clearly disclosed as in-progress documents

Relation to claims: See About — Methodology for classification details.

6. Governance controls

Claim: "Accountable stewardship" and "Governance" — used across the site.

Standard:

• Single accountability: All systems and publications have a named owner (currently: Ugo Candido, Principal)
• Methodological review: System designs and publications are reviewed against the Decision Integrity framework before release
• Controlled evolution: Data sources, model parameters, and logic rules are updated through a documented change process — no uncontrolled modifications
• Scope boundaries: Each system explicitly declares what it covers and what it does not

7. Methodological traceability

Claim: "System components are connected to published research with explicit references."

Standard: Every system in the systems atlas includes a "Methodology basis" section that links to the specific publications documenting its design rationale. No system component relies on undocumented design choices.

8. Claim-to-standard mapping

9. Contact

Questions about this policy: info@fidamen.com