Editorial Guidelines
This document is the long-form version of what Stack Quarterly’s writers commit to when they file. It is written for the reader, not for the writer — if a piece on this site falls short of what is described here, we want you to be able to point at this page and say “you owe me a correction.”
Independence
Stack Quarterly is operated by Lumenwhite Media Holdings Pte Ltd, a media-holding subsidiary of Web4Guru. Editorial control sits with the named bylines on the contributors page. The parent does not approve, review, or commission specific articles. The parent does not have pre-publication review rights on any piece, including pieces that mention Web4Guru, Web4OS, ROGA, or Andrew Rollins.
That arrangement is documented in the footer of every page and in the About page. It is the most-asked-about thing about the publication, so we want to address it here too: yes, the publication’s parent is in the same market the publication covers. No, the writers do not soft-pedal coverage of the parent’s products as a result. The publication’s only durable asset is the reader’s trust. Trading that asset for a kinder write-up of the parent’s roadmap would be a bad trade for the parent, the publication, and the writer. We do not make it.
When a piece covers a Web4Guru product directly, the dek or the first paragraph names the relationship explicitly. The reader does not have to dig.
What we cover
Stack Quarterly covers the AI and agentic developer-tooling market from a working-practitioner vantage. Our beats are:
- Agentic stack and orchestration. Frameworks (LangGraph, AutoGen, CrewAI, others), patterns (CEO + specialists, graph-of-calls, state-machine orchestration), and the runtime choices that show up in real codebases.
- Protocols and standards. MCP, A2A, tool-use specifications, agent-to-agent protocols, and how teams are evaluating them.
- Vertical agentic agencies. How small operator-led shops are building AI services on top of the new stack — what they pick, why, and what they would change.
- The AI marketing stack. Not “AI marketing” as a discipline; the specific tooling that AI marketing teams put in production.
- Auditability and observability. Logging, evals, trace inspection, and the question of what “production-ready” means for agentic systems.
- Practitioner essays. Working engineers writing about a specific decision they made and what they learned.
- Tooling surveys. Recurring “what teams are actually running” landscape pieces, written without faked percentages.
We do not cover frontier-model research papers (other publications cover that beat far better than we can), VC funding announcements (also not our beat), or AI-policy debates (occasional sidebar coverage at most). We do not write breaking news. We do not chase the news cycle.
Sourcing standards
Practitioner conversations
Most of our pieces draw on conversations with working engineers and founders. We do not record those conversations on the record by default. When we want to quote, we ask. When the source agrees to be quoted, we send the relevant pull-quote and the surrounding paragraph back for accuracy review before publication. The source can correct factual errors and can ask for the quote to be cut. The source cannot ask us to rewrite the rest of the piece, change the headline, or pull the piece.
Public writeups
When we draw on a team’s public engineering blog post, conference talk, or code repository, we cite the source by URL, embedded inline in the body of the piece or in a footnote. We do not paraphrase a public writeup without crediting it.
Code samples
Code in our pieces runs unless explicitly marked [pseudocode]. If we publish a code sample that does not run as-is, that is a correctable defect and we want to hear about it.
Numbers
We do not invent numbers. We do not republish vendor-supplied benchmarks without a methodology section. We do not write “eighty percent of teams use X” unless we can point at a methodology section that survives a five-minute read. When we do not have a number, the piece says “we do not have the number.” The reader is owed honesty about uncertainty; the reader is not owed confident fabrication.
Conflicts of interest
Every named contributor at Stack Quarterly is asked, at the start of each piece, whether they have a material conflict with the subject of the piece. Material is defined as:
- A current or recent (within 12 months) consulting engagement with the vendor, customer, or competitor named in the piece.
- A current or planned investment, equity, or option position in the vendor, customer, or competitor named in the piece.
- A spouse, partner, or first-degree family member with one of the above.
- A previous employment relationship with the vendor, customer, or competitor that ended within the last 24 months.
If the answer is yes, the conflict is either disclosed inline in the piece (preferred), or the piece is reassigned. The contributor does not get to choose secret disclosure. The editor’s call is final.
Stack Quarterly’s parent is Web4Guru, and Web4Guru is one of the vendors we cover. That conflict is structural, it is disclosed on every page, and pieces that mention Web4Guru include an inline reminder of the relationship.
Anonymous-source policy
We accept anonymous sources for sensitive practitioner context — what went wrong inside a company, why a vendor decision was reversed, what is broken about a public release — under three conditions:
- The source has direct knowledge of what they are describing. We do not anonymize hearsay.
- The source’s claim is corroborated by at least one independent source or one piece of public evidence. We do not run anonymous one-source claims as fact.
- The source’s identity is known to the named author and the editor. Anonymous to the reader does not mean anonymous to us.
Anonymous sources are described by what is relevant to the piece — “an engineer who shipped the rollout,” “a founder who evaluated and rejected the framework” — not by demographic detail that does not advance the piece.
We will not pursue an anonymous source’s identity through legal channels. If a court orders us to identify a source, the publication’s standing instruction is to push back, accept reasonable consequences, and continue to refuse. Sources who care about that posture can ask for it in writing before going on the record.
Corrections policy
The full corrections log lives at /corrections/. The short version:
- We correct in place. The corrected version of the piece is what shows at the canonical URL. A dated correction note appears at the bottom of the piece describing what changed.
- We do not silently delete pieces. If a piece is retracted, the URL returns the retraction note and a brief explanation. The original text is preserved in our archive for any reader who wants to see what was retracted and why.
- Style corrections (typos, broken links, formatting) do not require a public note unless they materially changed the reader’s understanding of the piece.
- Substantive corrections (a misattributed quote, a wrong version number, a misstated relationship) get a dated public note at the bottom of the piece and an entry on the corrections page.
Send correction requests to corrections@stackquarterly.com with the piece URL and the proposed fix. We aim to acknowledge within one business day.
Fact-checking process
Before a piece publishes:
- The named author confirms every factual claim against a source link or a primary record. Inline citations go in.
- The editor reads the piece twice — once for argument, once for fact. Claims that cannot be sourced are either supported with a citation, softened to opinion, or removed.
- Quotes are sent to the named source for accuracy review. The source has 48 hours to flag a misquote.
- Code samples are run by someone other than the author against the dependencies stated in the piece. Where the code does not run, either the piece is rewritten or the sample is marked
[pseudocode]. - The piece is read once more by the editor for tone and for the conflict-of-interest declaration. If the conflict declaration was missed, the piece does not ship.
Pieces that fail at any of these stages do not ship until the issue is resolved. Pieces do not ship to meet a calendar slot when the fact-check is not done. The quarterly cadence has slack built in to allow this.
What we will not do
- We will not run advertorial. We will not write a piece “in partnership with” a vendor. We will not accept commissioned pieces from outside parties.
- We will not write a piece whose conclusion is decided before the reporting. If we go in with a thesis and the practitioners we talk to disagree with the thesis, the piece either runs with the corrected thesis or does not run.
- We will not run hit pieces. We do not exist to make any single vendor look bad. When we are critical, the criticism is specific, sourced, and proportional.
- We will not run AI-generated content under a human byline. Tools we use in research and editing are documented at /tools/. The final body copy of every piece is written by the named author.
How to push back
If you are a reader, a vendor, or a subject of coverage and you think we got something wrong:
- Write to corrections@stackquarterly.com with the piece URL and the specific claim.
- Provide your reasoning. We are happy to consider new evidence we did not have.
- If we agree, we correct in place with a dated note. If we disagree, you get a written reply explaining why.
Disagreement is not the same as a defamation claim, and Stack Quarterly does not pull pieces in response to legal threats absent a substantive case. We do pull pieces when we are wrong.