Validated examples¶
Every root configuration in this catalogue is loaded with the exact Octoform patch pinned by the documentation build before publication. Owners and repositories are intentionally fictitious.
Start with a plan
Replace the placeholder owner, provide an appropriately scoped token, and
run octoform plan before considering apply.
Organization¶
Govern the account itself — profile, member policies, custom properties and organization rulesets — in the same reviewed plan as its repositories.
Teams and access¶
Declare teams and their nesting, who is on each one, who holds an organization role, and what each of them may reach.
Multi-owner¶
Govern an organization and a personal account from one document, with the shared policy written once.
Reviewed plan¶
Separate approving a change from carrying it out, using a saved plan that refuses to drift between the two.
Minimal policy¶
Manage one merge setting across every selected repository. This is the smallest configuration that produces a mutable plan.
Audit only¶
Report missing public metadata without declaring desired repository settings or making mutation possible.
Personal account¶
Classify repositories from local evidence and use repository rulesets without depending on organization custom properties.
Branch patterns¶
Compare the default-branch token, exact branches, glob patterns, and a fixed set of maintained branches.
Scheduled audit¶
Use a policy that stays observational even if someone invokes apply against
the same file.
Shared presets¶
Compose owner-neutral project and security policies from organization or personal-account root configurations.
What validation proves¶
The documentation build parses every root file, resolves its imports, and rejects invalid configuration. Validation proves compatibility with the documented Octoform release; it does not prove that the placeholder policy is appropriate for a particular repository, token, or GitHub plan.
It proves less than usual for the two organization examples, and the difference
is worth knowing. Loading a file establishes that every key is spelled the way
the release accepts. It cannot establish what a base_permission or a ~ALL
condition would reach in your organization — only a plan against that
organization can, which is why both examples say to run one first.