Editorial Standards

1. Editorial mission

Dev Utilities Pro exists to give developers the utility calculators they reach for daily, without a SaaS paywall and without hiding the underlying logic. Our editorial mission is verifiable trust: every formula is open-source on GitHub, every assumption is cited to an authoritative primary specification (IEEE, IETF RFC, POSIX, IANA, or Knuth), and every page is reviewed by a named human with public accountability. Developer audiences fact-check. That is not a constraint — it is the standard we build to.

2. How our calculators are built

Every calculator on Dev Utilities Pro goes through the same six-step process:

1. Spec identification. Before writing a line of code, we identify the authoritative primary specification for the subject — IEEE Std 1003.1 for POSIX cron syntax, RFC 3339 for internet timestamps, RFC 4648 for Base64, the IANA timezone database for timezone rules. If no primary spec exists for a claimed behavior, we document that uncertainty rather than invent one.
2. Algorithm derivation. We derive each algorithm directly from the spec, citing the specific section as a code comment at the call site. Anyone reading the source on GitHub can trace every constant and rule back to the authoritative document and section that defined it.
3. Test case generation. For every calculator we write automated tests against known-good examples — worked examples from the spec itself, platform-verified outputs, and regression cases for edge conditions (Y2K38 boundary, leap year February, DST transition hours, Base64 padding). Tests run on every commit.
4. Code review. Every implementation passes human review before publication. Byron Malone reviews all calculator logic. For specialized dialect behaviors (e.g., Quartz scheduler L/W/# characters, AWS EventBridge dom/dow mutual exclusion), we verify against platform documentation and, where possible, live environment outputs.
5. Methodology documentation. For each calculator category we publish a methodology page covering how the algorithms derive from primary specifications, edge cases handled, known limitations, and when the page was last reviewed. Those pages live at /methodology and the per-category routes beneath it.
6. Public release. The calculator goes live with a “View source on GitHub” link in the math accordion, full spec citations in the page copy, a named reviewer byline, and a last-reviewed date. Nothing ships without all four.

3. How AI is used (and where humans review)

Dev Utilities Pro is built natively on AI automation. We use AI for: drafting calculator copy and explanatory content, generating test cases, monitoring primary specifications for changes, and producing initial article drafts. Every AI-produced output passes through human editorial review before publication: every algorithm is verified by Byron Malone, every citation is checked against the primary spec, every published page has a named reviewer.

AI is amplification of editorial judgment, not replacement. Developer audiences deserve to know how the content they rely on is produced. If a piece of content was AI-drafted, it was human-reviewed before it shipped, and the human who reviewed it is named on the page.

4. How we vet sources

Every formula and assumption in a Dev Utilities Pro calculator traces to a primary source. For developer utility content, primary sources are:

• IEEE standards — IEEE Std 1003.1 (POSIX.1-2017) for cron and epoch definitions; IEEE 754-2019 for floating-point arithmetic and precision limits.
• IETF RFCs — RFC 3339 (internet timestamps), RFC 4648 (Base64), RFC 791 (IPv4 addressing). We cite the RFC number and section, not secondary summaries.
• Platform documentation — AWS EventBridge schedule expressions documentation, GitHub Actions schedule syntax documentation, Quartz scheduler 2.3.0 tutorials. We cite the specific document URL and last-accessed date.
• Canonical algorithm references — Knuth, The Art of Computer ProgrammingVol. 2 §4.4 for radix conversion algorithms (Horner's method, repeated division); Fliegel and Van Flandern (1968, Communications of the ACM) for the proleptic Gregorian calendar algorithm.
• IANA databases — IANA Time Zone Database (iana.org/time-zones) for timezone rules. Cited as a living database with a version tag where applicable.

We do not cite blog posts, content-marketing pages, or aggregator sites as primary sources. When a platform's behavior diverges from the spec it claims to implement, we document the discrepancy rather than picking one and hiding the conflict.

5. Update and correction policy

Specs and platform behaviors change. POSIX releases new versions. AWS EventBridge adds syntax support. RFC errata get published. A developer utility that does not update with its sources produces wrong answers. Dev Utilities Pro intelligence agents continuously monitor primary sources for changes affecting our calculators. When sources update, we evaluate and refresh affected calculators within 30 days, with named-reviewer signature on the update. Each calculator displays a “Last Reviewed” date.

When we publish a calculation with an error, we acknowledge it publicly on our corrections page, fix the error promptly, and document what was wrong, when it was identified, and who reviewed the fix. Transparent corrections strengthen trust more than silent fixes. If you've spotted an error, email info@bedrockatools.com with the calculator slug, the inputs you used, and the output you got. We respond within three business days.

6. Affiliate disclosure and editorial independence

Dev Utilities Pro earns revenue partly from affiliate partnerships with developer tools we recommend, and partly from display advertising. We disclose these relationships clearly on every page where they apply — see our affiliate disclosure for the full partner list.

Affiliate revenue does not influence which calculators we build, what specs we cite, or what our methodology says. Editorial decisions are made by Byron Malone and reviewed before publication. We select affiliate partners based on alignment with our standards: the product must be something Byron or a developer on the Bedrocka team has used in a real context and would recommend on the merits.

7. Author and contributor policy

Every Dev Utilities Pro page has a named human reviewer. We do not publish under “Editorial Staff” or “Bedrocka Team” bylines. Reviewers are identified by name with a link to a public author page that includes their background and contact information.

Currently, Byron Malone serves as the primary editor and technical reviewer for all developer utility content. Read the lead reviewer's full bio at /authors/byron-malone.

8. Named-expert citations

Where a named researcher's published work directly informs a calculator's methodology or framing, we cite them by name, publication, and year using the format: Per [Name], [Publication] ([year]): “[quote].” Quotes are reproduced verbatim. Every citation links to a verifiable public URL — no paywalled sources, no secondhand attributions. Dev Utilities Pro cites its primary algorithmic sources directly in methodology pages: Knuth (TAOCP Vol. 2), Fliegel & Van Flandern (1968), and the spec bodies that define the standards (IEEE, IETF, POSIX).

9. Contact and feedback

Spotted an error? Want to suggest a calculator we should build? Have feedback on our methodology? Email Byron Malone directly at info@bedrockatools.com or open an issue on our GitHub repository. We read every message.