Standards: engineering expectations in a repository
Public policies, coding standards, reference configuration and workflow examples, including the SDLC and information security program discussed in the blog.
active
An engineering standard becomes more useful when it can travel with the work. The Standards repository makes expectations reviewable: policies explain decisions, coding rules give them stable identities, and configuration turns the applicable rules into executable checks.
CTO to Human: make expectations available before work begins
An expanding group of people and AI agents needs a shared account of what good delivery means. A standards repository gives them a reference they can inspect before making a change. It also gives the owner a place to record exceptions honestly, rather than allowing an undocumented shortcut to become the working standard.
The aim is consistency of judgment. The repository separates policy, implementation standards and enforcement so a reader can understand both the requirement and why it exists.
Engineer to Engineer: connect a rule to evidence
The public repository contains SDLC, security-program and AI-assisted-development policies; language profiles; formatter/linter configuration; reusable workflows; and adoption material. Rules have stable identifiers and requirement levels. Repository-local instructions and CI can reference those rules without duplicating the entire policy library.
The SDLC defines the delivery path: work, review, qualified artifacts and release decisions. The security program defines responsibilities around access, secrets, vulnerabilities and incidents. Neither document proves that a consuming project conforms. Evidence and explicit exceptions are necessary to describe the actual state.
The repository, SDLC policy and security program are concrete examples behind the site’s standards, SDLC and WISP articles. This project journal follows their adoption and enforcement as engineering work.