Warning

The documentation is under active development and may be incomplete or inaccurate. Do not rely on it for integration, security, or compliance decisions until the 0.1.0 release.

This is the documentation home. It is organised around what you came to do. Pick a lane:

• Overview: what SolidSyslog is and how it helps with CRA and IEC 62443 compliance.
• Adopt it: get a syslog stack compiling and sending in your product.
• Port it to a new platform: fill a role for an OS, network stack, filesystem, or crypto library we don't ship yet.
• Compliance: IEC 62443, the RFCs, and the security posture.
• API reference: the public contracts, by audience.
• Maintaining the library: building, testing, and releasing SolidSyslog itself.

---

Overview

• Why SolidSyslog, and capability at a glance: the project README.
• Compliance in one page: the evaluator's one-screen orientation. What CRA and IEC 62443 ask of an audit-logging function, and how SolidSyslog helps.

Adopt

Everything you need to consume SolidSyslog in your product.

• Getting started: the integrator front door. The capability matrix, both consumption paths (CMake and non-CMake / IAR / Keil source integration), the worked embedded manifest, the tunables, and a "your first log" walkthrough.
• Choosing components by Security Level: which roles to fill for a good story at each SL, framed around your deployment's drivers, with worked starter combinations.
• Authoring custom structured data: attaching RFC 5424 SD-ELEMENTs.
• Error-event severity policy: installing an error handler and reading the event axes.
• Platform integration guides:
• lwIP (Raw API)
• Mbed TLS
• FreeRTOS-Plus-FAT
• Tunables: the compile-time limits, all #ifndef-guarded. See Getting started → Tunables and Core/Interface/SolidSyslogTunablesDefaults.h.

Port a new platform

Porting SolidSyslog is filling roles, not editing Core: omit an adapter and Core's Null object stands in.

• Porting guide: the role model, the anatomy of an adapter (instance shape, the no-malloc static pool, the error convention), the invariants every adapter must honour, and the twelve vtable role contracts, each with its Null fallback and shipped reference implementation (POSIX where available, otherwise a Core composition).
• The contracts themselves: the SolidSyslog*Definition.h vtables under Core/Interface/. Platform/Posix/ is the reference implementation to read alongside them.

Compliance

• Compliance in one page: start here.
• IEC 62443 compliance guide: component selection by Security Level (SL1–SL4), mapped control-by-control to IEC 62443-4-2 CRs and 62443-3-3 SRs.
• RFC compliance matrix: sender-side coverage of RFC 5424, 5426, 6587, and 5425.
• Security:
• Threat model
• At-rest cryptography
• Software Bill of Materials (SBOM)
• Vulnerability triage runbook
• Release verification guide
• Reporting a vulnerability: SECURITY.md

API reference

Application code only ever includes SolidSyslog.h (and SolidSyslogConfig.h at setup); everything else is wired once behind the config struct. The public headers are split by audience (Interface Segregation) under Core/Interface/ and each Platform/*/Interface/. The project README lists the headers by audience.

The generated reference is under API reference in the site navigation: Headers browses every public header grouped by directory (Core/Interface, then one folder per platform); Data structures lists the config and vtable structs.

Maintaining

For contributors and maintainers of SolidSyslog itself (not for consuming it, which is Adopt above).

• Building and testing: the CMake preset catalogue.
• Pre-PR local checks: the tiered pre-PR check budget.
• BDD testing: the Gherkin / target-binary test infrastructure.
• CI pipeline: the status checks behind branch protection.
• Container images: the dev-container and CI image reference.
• Naming conventions: the per-tier scheme satisfying MISRA C:2012 rules 5.1–5.9.
• MISRA C:2012 deviations: the recorded, deliberate deviations.
• Release process: release-please, Conventional Commits, and versioning.