How We Work

Last reviewed: November 8, 2026

This isn't a corporate QA handbook — it's just how two researchers actually turn a bad afternoon in a lab into a tutorial we're willing to put our names on.

Who writes here

Everything on this site grows out of hands-on work with Azure infrastructure and SAP BTP/HANA in our own lab environments.

How a tutorial gets made

  1. We pick topics where the docs actually fail us. Usually something we (or a labmate) got stuck on — and we only commit after searching the official sources and confirming the gap is real and still open.
  2. We read primary sources only. learn.microsoft.com, techcommunity.microsoft.com, SAP product documentation via developers.sap.com, and the A2A protocol spec at a2a-protocol.org plus its GitHub repository. We don't build a tutorial on someone else's blog screenshot.
  3. We run it ourselves where we can. If a procedure can work in our own subscriptions or lab, we run it end to end and write down what actually happens — including the errors and workarounds the docs skip.
  4. We cite every claim. Each factual sentence in a draft carries a link to a primary source. Anything we can't source gets cut, or is clearly marked as our own interpretation.
  5. Second-model fact-check, then a human decides. A separate AI model reads the finished draft against the source list and flags claims the citations don't actually support. Where the model and we disagree, we re-read the primary source ourselves — the model raises the flag, the human makes the call. Full disclosure: we use AI coding assistants for drafts and fact-checking; a human verifies every claim against primary sources before publish.
  6. SEO and readability pass. Last, we fix headings, titles, and sentences so the right people find the answer fast. Nothing new may be claimed in this pass — it only reshapes what already survived the fact-check.

What we can't promise

We cannot always run a full SAP landscape. Some tutorials cover configurations we verified only at component level, or that follow vendor guidance we couldn't reproduce end to end — those articles say so plainly. Cost figures come from the Azure Retail Prices API or published price pages and always carry an as-of date, because cloud pricing drifts and a dated number you can check beats an undated one you can't. And where anything we wrote conflicts with official product documentation, the official documentation is right — tell us and we'll fix it.

Updates and corrections

Every tutorial carries a "last reviewed" stamp. We re-check content on a quarterly cadence and re-stamp only when we actually re-checked the primary sources — we don't silently refresh dates to look current. If you catch a factual error, send us the page URL, the paragraph, and a link to the correct source at sapailab@outlook.com. When we're wrong we fix it and leave a dated correction note at the bottom of the article, so readers who saw the old version can find out what changed.