DEV Community: AppZ

How I Built a Developer Knowledge Base in Obsidian That I Actually Use

AppZ — Mon, 22 Jun 2026 00:05:23 +0000

Every developer I know has the same problem: knowledge scattered across five places at once.

Browser bookmarks they never re-read. Notion docs that become graveyards. Slack threads with critical context that disappear into the archive. README files that contradict each other. Stack Overflow answers bookmarked with zero recall of why.

I tried most of the "second brain" setups and none of them stuck until I figured out why they kept failing: generic productivity systems are not built for how developers actually think and work.

A developer's knowledge is fundamentally different from a writer's or a manager's. It is:

Code-linked (a note about a library is useless without the actual code it explains)
Decision-heavy (architecture decisions need context, rationale, and alternatives considered)
Debugging-intensive (solutions to bugs need the exact error message, environment, and what you tried)
Time-sensitive (that API migration note is only relevant for a 3-month window)

Here is the structure that actually worked.

The Core Structure

00-Inbox/
10-Projects/
20-Areas/
  - Language: Python/
  - Stack: AWS/
  - Domain: Auth/
30-Resources/
  - Libraries/
  - Tools/
  - Patterns/
40-Archive/

The key insight: Resources are evergreen, Projects are temporary, Areas are ongoing responsibilities.

A note about how JWT works lives in 30-Resources/Domain-Auth/. A note about implementing JWT for the current sprint lives in 10-Projects/Sprint-42-Auth-Revamp/. When the sprint is done, the project gets archived. The JWT fundamentals note stays forever.

The Templates That Made It Click

Architecture Decision Record (ADR)

# ADR-042: Use Postgres over DynamoDB for user sessions

Status: Accepted | Date: 2026-06-22

## Context
We need session storage that supports complex queries for the audit log feature.

## Decision
Postgres with connection pooling via PgBouncer.

## Alternatives Considered
- DynamoDB: rejected (query limitations for audit log requirements)
- Redis: rejected (not durable enough for compliance requirements)

## Consequences
- Positive: Full SQL query support for audit reporting
- Negative: Need to manage connection pool tuning

This template changed how our team makes decisions. When someone asks "why did we choose X six months ago?" the answer is one Cmd+O search away.

Debug Log

# Debug: [error message or symptom]

Date: 
Environment: 
Reproduction Steps:

## What I Tried
- Attempt 1: [result]
- Attempt 2: [result]

## Root Cause

## Fix

## Links

The discipline here: write the debug log BEFORE you fix it, not after. The moment you close the bug you lose 80% of the context. The notes you write mid-investigation are the ones that actually help future-you.

Code Snippet Vault

# [What this does in plain English]

Tags: #python #pandas #data-cleaning

## Use When
[Specific scenario this applies to]

## Code

python

the actual code


## Gotchas
- [Edge case 1]
- [Edge case 2]

## Source
[Link to SO answer, docs page, or colleague who showed you this]

datastudio

The "Use When" field is what separates useful snippets from ones you never re-find. If you cannot write one sentence about when to use it, you probably do not understand it well enough to save it.

The Dataview Queries That Make It Useful

Install the Dataview plugin and add these to your homepage:

Open architecture decisions (needing review):

TABLE status, date FROM "20-Areas"
WHERE contains(file.name, "ADR") AND status != "Accepted" AND status != "Superseded"
SORT date DESC

Notes tagged with a specific tech stack:

LIST FROM #aws AND #lambda
SORT file.mtime DESC
LIMIT 10

Recent debug logs (last 14 days):

TABLE file.mtime as "Date" FROM "10-Projects"
WHERE contains(file.name, "Debug")
WHERE date(file.mtime) > date(today) - dur(14 days)
SORT file.mtime DESC

What Actually Changed My Behaviour

The three things that made this stick where other systems did not:

1. The quick capture shortcut. I have a hotkey that opens a new note in 00-Inbox/ in under a second. If capturing requires more than one action, you stop capturing during flow state.

2. Weekly 20-minute inbox processing. Every Monday, everything in 00-Inbox/ gets filed, linked, or deleted. The inbox is not storage -- it is a queue.

3. The "what would make this note findable" principle. Before closing any note, I ask: if I search for this in 6 months with a vague memory of what it's about, what search term will I use? Then I make sure that term is in the title or first paragraph.

Getting Started Without Building From Scratch

The hardest part is the initial structure and templates. You can build everything above yourself in a few hours, or use a pre-built Developer KB OS with the ADR, debug log, snippet vault, and Dataview queries already wired up.

I put one together and it's available at zarchitectstudio.gumroad.com/l/rncjp -- but everything in this post is enough to build your own if you prefer starting from scratch.

The setup matters less than the habit. Pick a structure, commit to it for 30 days, and adjust from there.

How I built an AU small business AI advisor with Gemini 2.0 Flash (and why Australian context changes everything)

AppZ — Thu, 18 Jun 2026 06:33:07 +0000

Most AI tools give Australian small businesses American advice. An Aussie tradie running Xero does not need to hear about QuickBooks. A cafe owner with three casual staff has Fair Work Act obligations that no generic "automate your business" tool will surface.

I built AppZ AU Business Advisor to fix this -- a free tool powered by Gemini 2.0 Flash that generates personalised automation blueprints with real Australian business context. This post covers the technical decisions, the prompt engineering approach, and why the AU-specific scaffold makes all the difference.

The Problem with Generic AI Business Advice

When you ask a general AI "how should I automate my business?", the training data skews heavily American. You get advice about QuickBooks, not Xero. About W-9 forms, not BAS lodgement. About 401k, not superannuation.

For an Australian sole trader approaching the $75k GST registration threshold, this is not just unhelpful -- it is actively misleading. The compliance obligations are different. The software ecosystem is different. The pain points are different.

The Prompt Scaffold Approach

Instead of injecting "you are talking to an Australian business" as a keyword, I built a reasoning scaffold -- a structured context block the model uses as a knowledge foundation:

AUSTRALIAN BUSINESS CONTEXT:
- GST: 10%, mandatory registration at $75k annual turnover
- BAS: lodged quarterly (or monthly for large businesses) to the ATO
- Superannuation: 11.5% employer contribution, paid per payroll from July 2026
- ATO tools: STP Phase 2 mandatory for all employers
- Dominant accounting platforms: Xero, MYOB, Reckon (not QuickBooks)
- Fair Work Act: award rates, leave entitlements, payslip requirements
- Key software by vertical: ServiceM8 (trades), Deputy (hospitality), Cliniko (health)

This is not a keyword list -- it is a reasoning foundation. When a tradesperson mentions "invoicing problems", the model now reasons about Xero integrations, GST-inclusive invoicing, and BAS categorisation, not generic invoice templates.

Gemini 2.0 Flash Structured Output

The key technical decision was using Gemini's structured JSON output mode. Instead of asking for "a recommendation in JSON format" (which requires a parsing fallback), I use responseMimeType: "application/json" with a defined schema:

const result = await model.generateContent({
  contents: [{ role: 'user', parts: [{ text: prompt }] }],
  generationConfig: {
    responseMimeType: 'application/json',
  },
});

This returns clean, schema-conforming JSON directly -- no markdown code fences to strip, no parsing errors to handle. The React components can render it immediately.

The output schema I defined:

type AdvisorOutput = {
  summary: string;          // 2-3 sentences, AU-specific
  auContext: string;        // Key AU compliance note for this business type  
  recommendations: Array<{
    product: Product;
    reason: string;
    expectedImpact: string;
    priority: 'high' | 'medium' | 'low';
  }>;
  implementationPlan: string;  // 30-day steps with AU context
  estimatedTimeSaved: string;
  dollarsPerWeekSaved: string; // Calculated from optional hourly rate input
  nextStep: string;
};

ROI Calculation

One addition that makes the output tangible: an optional hourly rate input. When provided, the model calculates dollar value of time saved rather than just "8-12 hours/week":

dollarsPerWeekSaved: "calculate: hours saved x $150/hr = $1,200-$1,800/week in recovered capacity"

This is much more compelling for a business owner than an abstract hours figure.

Stack and Deployment

Next.js 15 App Router with TypeScript
Google AI SDK (@google/generative-ai) for Gemini calls
Vercel for deployment (two serverless routes: /api/advisor and /api/email-capture)
Fully stateless -- no database, no auth, no data retained

The app is live at gemini-xprize.vercel.app and the full source is on GitHub. It is a submission to the Gemini XPRIZE (Small Business Services category) but I built it as a real, useful tool first.

What I Would Do Differently

The main shortcut for speed-to-competition: the product recommendations come from a hardcoded catalog rather than a live API. A production version would pull from Xero's App Marketplace API or MYOB's partner directory to give genuinely current recommendations. The Gemini side would stay the same -- the AU context scaffold is the core value.

If you are building something similar, the key lesson is: domain-specific reasoning scaffolds outperform keyword injection. Telling Gemini "you are talking to an Australian business" is much weaker than giving it a structured knowledge foundation about what that actually means operationally.

Happy to discuss the prompt structure or the structured output approach in the comments.

3 patterns that make n8n workflows actually production-ready (and why most tutorials skip them)

AppZ — Thu, 18 Jun 2026 04:43:02 +0000

I recently finished building 33 industry-specific n8n automation packs -- one per business vertical (HR, Marketing, Finance, Healthcare, Real Estate, Legal, and so on). Each pack has 10 importable JSON workflows.

Building at that scale forced me to get strict about patterns that make workflows actually hold up in production. Here are the three I now use on every single workflow.

1. Every trigger needs an error capture

Tutorial workflows almost always skip error handling. The "happy path" works, you see it fire once, and you call it done.

In production, the trigger fires hundreds of times. The third-party API goes down. The webhook payload has a null field you did not expect. A rate limit hits at 2am.

The fix is simple: wire a catch block after every trigger node, even if all it does is post a message to a Slack channel. Silent failures are the thing that kills automation programs. A workflow that fails loudly is fixable. A workflow that fails silently runs for three months before anyone notices the data is wrong.

[Trigger] --> [Normalise Input] --> [Core Logic]
    |                                    |
[Error Capture] <-----------------------+
    |
[Slack Alert: "Workflow X failed -- {error.message}"]

2. Data normalisation happens at the entry point

This one sounds obvious until you see a workflow where normalisation is scattered through six different nodes.

The rule: all data cleaning, type coercion, null checks, and field renaming happens in the first node after the trigger. Everything downstream receives clean, predictable data.

Why this matters:

When the input format changes (and it will), you change one node instead of hunting through ten
Debugging becomes dramatically faster because you can inspect the normalised payload and know exactly what every subsequent node receives
Workflows become readable to other people without you explaining the data shape at every step

In the Finance pack workflows, for example, every trigger that receives transaction data immediately passes through a normalisation function that converts amounts to cents (integer), standardises date formats to ISO 8601, and maps vendor names to a canonical form. Nothing downstream touches raw input.

3. Retry logic on every external API call

Most API failures are transient. A timeout, a momentary rate limit, a brief service hiccup. If you do not build in retries, transient failures look the same as real failures and get escalated unnecessarily.

The pattern I use:

Retry up to 3 times
Exponential backoff: 1s, 4s, 16s
After 3 failures, route to the error capture (not a crash)

n8n has built-in retry settings on HTTP Request nodes. Use them. Set it and forget it.

The workflows that do not have this eventually produce a Monday morning support ticket that reads "the automation broke" when what actually happened was a 30-second API outage at 3am that would have resolved itself on the second attempt.

Why most tutorials skip all of this

Because error handling, normalisation, and retry logic make the tutorial longer and harder to follow, and they do not change whether the demo fires successfully.

But they are the difference between a workflow that works once and a workflow that runs reliably for months.

I packaged these patterns into 33 ready-to-import packs across different business verticals. Each workflow has error capture, normalised entry points, and retry logic already wired. The store is at https://zarchitectstudio.gumroad.com if you want to skip the build time for any of the industries listed.

Happy to dig into any of the specific patterns in the comments.

GDPR Tells You to Delete. The EU AI Act Tells You to Archive. Here Is How to Resolve It.

AppZ — Fri, 24 Apr 2026 04:47:42 +0000

If you are building or deploying AI systems in the EU, you are probably already managing GDPR obligations. Now the EU AI Act is layered on top.

The two regulations appear to conflict directly on one of the most sensitive data questions: how long do you keep training data?

GDPR says you delete it when it is no longer necessary. The EU AI Act says you keep it to prove your system is compliant.

Here is how you resolve it.

Why the Tension Exists

GDPR's storage limitation principle under Article 5(1)(e) requires that personal data is kept in a form that permits identification of data subjects for no longer than is necessary for the purposes for which the data was collected.

The EU AI Act under Article 10(5) allows high-risk AI systems to retain special categories of personal data, where strictly necessary, for the purpose of detecting and correcting biases.

Article 12 of the EU AI Act requires logging capabilities that retain records sufficient to enable post-hoc review of system outputs. For systems used in high-stakes decisions, these logs include input data linked to specific decisions affecting identifiable individuals.

A pure GDPR application would say: delete when the purpose expires. A pure EU AI Act application would say: retain to demonstrate conformity. Neither regulation explicitly defers to the other.

The Reconciliation Framework

The resolution lies in purpose specification and proportionality, the same principles that underpin GDPR compliance generally.

The key is to separate training data retention from operational log retention, and to apply different retention rules to each.

For training data, the GDPR purpose limitation principle requires a clear, documented legal basis for extended retention. Under Article 6(1)(f), legitimate interests or under Article 9(2)(g) for special category data in the substantial public interest, you can justify retaining training data beyond its original collection purpose if you document the necessity for bias detection, can demonstrate no less privacy-invasive alternative exists, and have completed a legitimate interests assessment.

This is not a blanket exemption. It requires active documentation and regular review.

For operational logs under Article 12 of the EU AI Act, the retention period must be proportionate to the risk profile of the system. A general-purpose AI tool used internally has a different risk profile from a high-risk system used in employment screening under Annex III. The former may justify 30-day log retention. The latter may require two years or more.

What Your Documentation Must Show

The practical resolution requires you to produce documentation that serves both regulatory frameworks simultaneously.

Your data governance record must show the original collection purpose, the EU AI Act compliance purpose that justifies extended retention, the legal basis under GDPR Article 6 or Article 9 for that extended retention, a defined retention period tied to the EU AI Act conformity assessment cycle, and a deletion schedule activated at the end of that period.

This documentation should sit alongside your EU AI Act technical documentation under Annex IV and your GDPR Records of Processing Activities. In practice, many organisations are creating a unified data governance layer that feeds both.

The Special Category Problem

The conflict sharpens with special category data. GDPR restricts processing under Article 9 to specific grounds. The EU AI Act under Article 10(5) permits retention of such data for bias detection but only where strictly necessary and where appropriate safeguards are in place.

Strictly necessary is a high bar. You cannot retain sensitive demographic data because it might be useful. You need to demonstrate that the bias detection objective cannot be achieved using anonymised or aggregated data.

In most cases, pseudonymisation provides a workable middle path. You retain the data structure necessary for bias analysis while reducing the re-identification risk that makes GDPR Article 9 processing so constrained.

Pseudonymisation does not eliminate GDPR obligations. The data remains personal data for regulatory purposes. But it reduces the risk profile and strengthens the proportionality case.

Practical Steps

First, classify your AI systems by risk tier. High-risk systems under Annex III have active retention obligations that justify more extensive GDPR carve-outs. Limited risk systems have a weaker case for extended retention.

Second, map your data flows. Know which data feeds your training pipeline, which data populates your operational logs, and which data supports your post-market monitoring obligations under Article 72.

Third, draft retention schedules that are regulation-specific. Your training data retention policy and your operational log policy should reference both GDPR and EU AI Act obligations explicitly, with legal bases cited for each.

Fourth, build deletion into your conformity process. When a conformity assessment cycle ends, your deletion triggers should activate. Retention that outlasts its regulatory purpose becomes a GDPR liability.

The organisations that handle this well are the ones treating data governance as infrastructure, not paperwork. The conflict between these two regulations is real, but it is navigable with deliberate documentation and proportionate retention design.

What EU AI Act Compliance Actually Costs and Where the Money Goes

AppZ — Fri, 24 Apr 2026 04:45:39 +0000

Every conversation I have with a founder building AI products in Europe eventually comes around to the same question: what is this actually going to cost us?

The EU AI Act is not a fine-on-paper regulation. It has teeth. And the compliance costs are real, spread across people, processes, and infrastructure that most startups have not budgeted for.

Here is a breakdown of where the money actually goes.

The Legal Bill Comes First

Before you can comply, you need to understand what applies to you. That means legal counsel who actually knows the EU AI Act, not just GDPR specialists who have skimmed the summary.

For a startup deploying a high-risk AI system under Annex III, expect to spend between 15,000 and 50,000 euros on initial legal scoping alone. That covers classification analysis, reviewing your data governance arrangements, and mapping your obligations across Articles 9 through 17.

If you are a provider placing a system on the EU market and also acting as a deployer, that cost doubles because you are subject to two overlapping obligation sets.

Conformity Assessment Is Not Free

Article 43 requires a conformity assessment before a high-risk system goes live. For most categories, you can do this internally. But internally does not mean cheaply.

You will need to produce technical documentation under Annex IV. That means logging your training data sources, validation methodology, accuracy metrics across demographic groups, and a full description of the system purpose and logic. A consultant with AI technical audit experience charges between 10,000 and 30,000 euros per engagement for this work.

If your system falls under Annex III categories that require third-party notified body review, such as biometric categorisation or certain critical infrastructure applications, add another 20,000 to 80,000 euros for the external audit.

The Human Capital Cost Is Underestimated

The Act requires a natural person overseeing automated decision-making in high-risk contexts. That oversight has to be real, documented, and defensible.

That means hiring or retraining staff. A qualified AI compliance officer in the EU earns between 70,000 and 120,000 euros annually. If you do not have one, you will either hire one or rely on expensive external consultants for each review cycle.

Technical staff also need upskilling. Your engineers need to understand prohibited practice boundaries, data minimisation requirements under Article 10, and logging obligations under Article 12. Training programmes for a team of 20 typically run 5,000 to 15,000 euros.

Infrastructure Adjustments Are Unavoidable

Article 12 mandates automatic logging of events during the operation of high-risk AI systems. If your current infrastructure does not capture decision-level logs with timestamps, input parameters, and output records, you need to build that capability.

For most SaaS products, this means engineering work. Expect one to three months of developer time depending on complexity. At European contractor rates, that is 20,000 to 60,000 euros.

You also need to ensure your training and validation data meets the requirements of Article 10. Data from sources that cannot demonstrate relevance, representativeness, and freedom from prohibited biases will need to be replaced or supplemented. Data procurement and cleaning at scale is a real cost that organisations routinely underestimate.

The Registration and Ongoing Obligations

Once you are compliant, you have ongoing obligations. High-risk systems must be registered in the EU database. That process requires accurate technical documentation and is not a one-time submission.

Post-market monitoring under Article 72 requires a structured process for collecting and reviewing real-world performance data. If you discover a substantial modification to the system, the conformity assessment process restarts.

Annual compliance maintenance, including documentation updates, monitoring reviews, and retraining on regulatory changes, typically runs 15,000 to 40,000 euros per year for a mid-size organisation.

What This Adds Up To

For a startup deploying a single high-risk AI system in the EU, realistic first-year compliance costs range from 80,000 to 250,000 euros when you add legal, conformity, staffing, and infrastructure together. For an enterprise with multiple deployments across Annex III categories, total costs can exceed one million euros.

These are not worst-case figures. They reflect what I am seeing in practice.

The organisations that will control these costs are the ones that build compliance infrastructure once and reuse it across products, that document as they build rather than retrospectively, and that treat the technical documentation requirement as an engineering discipline rather than a legal afterthought.

Compliance is expensive. But getting it wrong is more expensive. The fines under Article 99 reach 30 million euros or 6 percent of global annual turnover. That math makes a robust compliance programme look cheap.

What Your DPO Needs to Know About the EU AI Act Before August 2026

AppZ — Tue, 21 Apr 2026 02:26:53 +0000

The EU AI Act is often talked about as a technology problem. It isn't. It's a documentation and governance problem — and that lands squarely on your Data Protection Officer.

Here's what DPOs and compliance leads need to understand before the August 2026 enforcement deadline.

You are now responsible for AI systems, not just data

Under the EU AI Act, high-risk AI systems require a designated person accountable for compliance. If your organisation already has a DPO structure, you're likely the closest thing to that person. That means understanding risk classification, maintaining technical documentation, and being able to demonstrate conformity to regulators on demand.

Risk classification is the first hurdle — and it's harder than it sounds

The Act defines eight categories of high-risk AI (Annex III). Systems used in recruitment, credit scoring, education, critical infrastructure, law enforcement, biometric identification, and certain medical contexts are automatically high-risk. But the classification isn't always obvious. A tool your company uses for "internal HR" might qualify. A scoring model built into your CRM might qualify.

If you can't classify your AI systems, you can't know what obligations apply to you.

What high-risk classification actually requires

If a system is classified as high-risk, your obligations include:

A conformity assessment
Technical documentation (Article 11)
A risk management system (Article 9)
Data governance requirements (Article 10)
Logging and auditability (Article 12)
Transparency requirements for users (Article 13)
Human oversight mechanisms (Article 14)

This is not a checkbox exercise. Regulators will expect you to demonstrate these in practice.

The documentation gap is where most organisations will fail

In practice, most companies have no centralised record of which AI systems they operate, let alone documentation that meets Article 11 requirements. DPOs who've built GDPR record-of-processing-activities (RoPA) frameworks will recognise this problem — the EU AI Act requires a similar inventory exercise, but for AI systems rather than data.

Start with an AI system inventory. Map every tool, model, or automated decision system your organisation uses or provides. Then apply the risk classification criteria.

Practical starting point

ActComply (getactcomply.com) automates the classification step and generates draft Article 11 documentation. Free to try, no account required.

The August 2026 deadline is not a soft launch. Enforcement powers are live from that date. DPOs who start now have time to do this properly. Those who wait until Q2 2026 won't.

Zac is the founder of ActComply, an EU AI Act compliance tool for technical teams and compliance professionals.

What Developers Need to Know About the EU AI Act Before August 2026

AppZ — Mon, 20 Apr 2026 21:52:44 +0000

If you're building AI systems that touch European users, the EU AI Act is no longer a future problem. Enforcement starts August 2, 2026, and the fines are serious — up to €35 million or 7% of global annual turnover, whichever is higher.

Most developers are either ignoring it or assuming their legal team has it covered. Neither is a safe bet.

Here's what you actually need to know.

What the EU AI Act actually is

The EU AI Act is a product safety regulation, not an ethics framework. Think of it like CE marking for software. If your AI system is deemed "high-risk," you need to document it, test it, monitor it post-deployment, and register it in an EU database before you can deploy it.

It's not about whether your AI is "good" or "fair." It's about whether you can prove it is.

How risk tiers work

The Act splits AI systems into four buckets:

Prohibited — banned outright. Real-time biometric surveillance in public spaces, social scoring systems, subliminal manipulation. If you're building these, stop.

High-risk — this is where most developers get caught out. Systems used in hiring, credit scoring, education, healthcare triage, law enforcement, critical infrastructure, and border control all fall here. If your product touches these sectors, you're likely high-risk.

Limited risk — chatbots and deepfake generators. You mostly just need to tell users they're interacting with AI.

Minimal risk — spam filters, AI in games. No specific obligations, just general good practice.

What high-risk actually requires from your team

If you're classified as high-risk, here's the technical checklist:

Risk management system — documented throughout the development lifecycle, not just at launch
Data governance — training data must be relevant, representative, and free from errors that could cause bias
Technical documentation — detailed enough for a regulator to assess conformity
Logging and audit trails — automatic logs of operation so incidents can be reconstructed
Transparency — users must know they're interacting with AI and what it can and can't do
Human oversight — the system must be designed so humans can intervene, override, or shut it down
Accuracy and robustness — performance must be validated against adversarial inputs and edge cases
EU database registration — before deployment, high-risk systems must be registered in the EU's public AI database

The timeline most teams are underestimating

August 2026 sounds far away until you realise the documentation work for a high-risk system typically takes 3 to 6 months. If you haven't started, you're already behind.

How to figure out if your system is high-risk

The classification logic in the Act is genuinely complex — it involves cross-referencing Annex III use cases with deployment context and the degree of human oversight. Most teams don't have in-house legal expertise to do this correctly.

We built ActComply to automate this. You describe your AI system, who it affects, and what sector it operates in, and it classifies you under the Act with exact article references in under 5 minutes. It then generates a compliance checklist and documentation templates specific to your risk tier.

It won't replace a compliance lawyer for edge cases, but it'll tell you immediately whether you need one — and give you a solid starting point either way.

TL;DR

EU AI Act enforcement is August 2, 2026
High-risk AI systems have serious documentation and monitoring requirements
Classification is non-trivial and getting it wrong is expensive
Start your compliance assessment now — the documentation pipeline is longer than you think
Free tool to classify your system: getactcomply.com

Happy to answer questions in the comments about specific use cases or sectors.