Single source of truth for website and AI readable

I’m a freelancer and created a website with AI (Lovable). I also told the AI to set everything up in a way that would make me discoverable when someone searches for me using AI.

I am totally new to SEO, but I have a tech background.

I changed some of the texts on my website again, and the content was no longer consistent everywhere. It bothered me that I constantly had to check which files contained which pieces of text.

So I let an AI create a Single Source of Truth containing my digital professional identity and had the AI create a script that automatically pulls the information only from this file. The file also serves as the basis for resumes.

On my website is not the full JSON file, just the specific data from it on each specific page.

Here is a fictional example. This is not me, this person is entirely fictional. I’m only giving you the example because I think it is extremely useful.

AI can read it very well. It is a JSON file based on Schema org.

So it also improves the machine readability of the website, and it is extremely practical for keeping the website up to date and for creating resumes. But remember I do not write it manually and the website is also updated via script.

You can just use any AI of your choice, give it your data or information and tell it to create a JSON based on Schema org.

Then you tell the AI that creates your website to make a script that pulls all revelant data from this JSON and put it into the specific pages.

I know this file is huge, but I just want to show you that you can use it for a resume, too. You can also link relevant blogs etc.:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Person",
      "@id": "https://eriklindstrom.dev/#person",
      "name": "Erik Lindström",
      "givenName": "Erik",
      "familyName": "Lindström",
      "url": "https://eriklindstrom.dev/about",
      "jobTitle": "Senior Data Engineer",
      "description": "Senior data engineer working on streaming, lakehouse architectures and data quality. Builds platforms that still make sense once the person who built them has left the room.",
      "email": "hello@eriklindstrom.dev",
      "image": "https://eriklindstrom.dev/portrait.jpg",
      "telephone": "+46 8 555 0187",
      "nationality": {
        "@type": "Country",
        "name": "Sweden"
      },
      "address": {
        "@type": "PostalAddress",
        "streetAddress": "Sankt Eriksgatan 44",
        "postalCode": "112 32",
        "addressLocality": "Stockholm",
        "addressCountry": "SE"
      },
      "knowsLanguage": [
        {
          "@type": "Language",
          "name": "Swedish",
          "alternateName": "sv"
        }
      ],
      "knowsAbout": [
        "Data Engineering",
        "Apache Kafka",
        "Apache Flink",
        "Apache Iceberg",
        "Change Data Capture",
        "dbt",
        "Airflow",
        "Snowflake",
        "DuckDB",
        "Python",
        "Go",
        "SQL",
        "Terraform",
        "Kubernetes",
        "Data Contracts",
        "Data Quality",
        "Cost Engineering",
        "GDPR-Compliant Deletion",
        "Dimensional Modeling",
        "Platform Engineering"
      ],
      "sameAs": [
        "https://www.linkedin.com/in/erik-lindstrom/",
        "https://github.com/elindstrom",
        "https://elindstrom.substack.com/",
        "https://mastodon.social/@elindstrom",
        "https://stackoverflow.com/users/4471902/elindstrom"
      ],
      "mainEntityOfPage": {
        "@id": "https://eriklindstrom.dev/#website"
      },
      "hasOccupation": {
        "@type": "Occupation",
        "name": "Senior Data Engineer",
        "occupationalCategory": "15-1243.00 Database Architects",
        "experienceRequirements": {
          "@type": "OccupationalExperienceRequirements",
          "monthsOfExperience": 172
        },
        "skills": "Streaming architectures on Kafka and Flink, lakehouse design on Iceberg and Delta, change data capture from OLTP sources, dbt modelling at four-digit model counts, cost control for cloud warehouses, data contracts and schema evolution, platform operations on Kubernetes",
        "estimatedSalary": {
          "@type": "MonetaryAmountDistribution",
          "name": "Target salary, permanent employment",
          "currency": "SEK",
          "duration": "P1Y",
          "median": 1250000
        }
      },
      "seeks": {
        "@type": "Demand",
        "@id": "https://eriklindstrom.dev/#seeks",
        "name": "Looking for a Staff Data Engineer or Data Platform Lead position",
        "description": "Open to permanent roles from Q4 2026. Prefers ownership of a platform or a product area over maintaining existing pipelines. Remote-first within Sweden and the Nordic region, with limited on-site work.",
        "availabilityStarts": "2026-11-01",
        "businessFunction": "https://purl.org/goodrelations/v1#ProvideService",
        "itemOffered": {
          "@type": "Occupation",
          "name": "Staff Data Engineer",
          "occupationalCategory": "15-1243.00 Database Architects",
          "alternateName": [
            "Data Platform Engineer",
            "Lead Data Engineer",
            "Principal Data Engineer"
          ]
        },
        "eligibleRegion": [
          {
            "@type": "Country",
            "name": "Sweden"
          },
          {
            "@type": "Country",
            "name": "Norway"
          },
          {
            "@type": "Country",
            "name": "Denmark"
          },
          {
            "@type": "Country",
            "name": "Finland"
          },
          {
            "@type": "Place",
            "name": "Nordic region, remote"
          }
        ]
      },
      "alumniOf": [
        {
          "@type": "CollegeOrUniversity",
          "@id": "https://eriklindstrom.dev/#org-kth",
          "name": "KTH Royal Institute of Technology",
          "description": "M.Sc. Computer Science, focus on distributed systems. Thesis on the consistency guarantees of log-based replication."
        }
      ],
      "hasCredential": [
        {
          "@type": "EducationalOccupationalCredential",
          "name": "M.Sc. Computer Science",
          "credentialCategory": "degree",
          "educationalLevel": "Master",
          "dateCreated": "2013-09",
          "recognizedBy": {
            "@id": "https://eriklindstrom.dev/#org-kth"
          }
        },
        {
          "@type": "EducationalOccupationalCredential",
          "name": "Certified Kubernetes Application Developer (CKAD)",
          "credentialCategory": "certificate",
          "dateCreated": "2021-05"
        }
      ],
      "award": [
        "Internal engineering award at Nordmark Analytics AB, 2023, for the Iceberg migration without downtime",
        "Community award at the Nordic Data Engineering Conference, 2024, for the open-source project backfill-guard"
      ],
      "worksFor": {
        "@id": "https://eriklindstrom.dev/#org-nordicshield"
      },
      "affiliation": [
        {
          "@type": "Role",
          "roleName": "Senior Data Engineer and Tech Lead, Data Platform",
          "startDate": "2024-06",
          "description": "Owns the claims data platform of a Nordic insurance group: change data capture from 14 policy systems, audit-proof historisation and a deletion process that carries GDPR requests verifiably through every layer.",
          "affiliation": {
            "@id": "https://eriklindstrom.dev/#org-nordicshield"
          }
        },
        {
          "@type": "Role",
          "roleName": "Staff Data Engineer",
          "startDate": "2022-09",
          "endDate": "2024-05",
          "description": "Migrated a grown Redshift warehouse to an Iceberg lakehouse in production, cutting warehouse cost by 38 percent while shortening load times.",
          "affiliation": {
            "@id": "https://eriklindstrom.dev/#org-nordmark"
          }
        },
        {
          "@type": "Role",
          "roleName": "Lead Data Engineer",
          "startDate": "2020-02",
          "endDate": "2022-08",
          "description": "Built a carsharing company's data platform from scratch, including data contracts between product teams and analytics and a self-service model for business departments.",
          "affiliation": {
            "@id": "https://eriklindstrom.dev/#org-fjall"
          }
        },
        {
          "@type": "Role",
          "roleName": "Senior Data Engineer",
          "startDate": "2017-07",
          "endDate": "2020-01",
          "description": "Real-time processing of telematics data from around 9,000 vehicles, from Kafka ingestion to arrival-time predictions inside the dispatching system.",
          "affiliation": {
            "@id": "https://eriklindstrom.dev/#org-nordicfreight"
          }
        },
        {
          "@type": "Role",
          "roleName": "Data Warehouse Engineer",
          "startDate": "2014-04",
          "endDate": "2017-06",
          "description": "Regulatory reporting and risk reporting at a regional bank, including the move from nightly Oracle batches to incremental processing.",
          "affiliation": {
            "@id": "https://eriklindstrom.dev/#org-sveabank"
          }
        },
        {
          "@type": "Role",
          "roleName": "Working Student and Junior BI Developer",
          "startDate": "2011-10",
          "endDate": "2014-03",
          "description": "First contact with production data pipelines: SSIS packages, sales reporting and an instructive collection of Excel exports.",
          "affiliation": {
            "@id": "https://eriklindstrom.dev/#org-skandiaretail"
          }
        }
      ],
      "subjectOf": [
        {
          "@id": "https://github.com/elindstrom/backfill-guard"
        },
        {
          "@id": "https://github.com/elindstrom/pg2iceberg"
        },
        {
          "@id": "https://github.com/elindstrom/dbt-costlens"
        },
        {
          "@id": "https://github.com/elindstrom/skewfinder"
        }
      ]
    },
    {
      "@type": "WebSite",
      "@id": "https://eriklindstrom.dev/#website",
      "url": "https://eriklindstrom.dev/",
      "name": "Erik Lindström – Senior Data Engineer",
      "description": "Pipelines that hold. Platforms you can understand. Costs somebody actually knows.",
      "inLanguage": "en-US",
      "author": {
        "@id": "https://eriklindstrom.dev/#person"
      },
      "publisher": {
        "@id": "https://eriklindstrom.dev/#person"
      }
    },
    {
      "@type": "Blog",
      "@id": "https://elindstrom.substack.com/#blog",
      "url": "https://elindstrom.substack.com/",
      "name": "Late Arriving Facts",
      "description": "Notes on data modelling, streaming and the cost of convenience. Roughly twice a month.",
      "inLanguage": "en-US",
      "author": {
        "@id": "https://eriklindstrom.dev/#person"
      }
    },
    {
      "@type": "SoftwareSourceCode",
      "@id": "https://github.com/elindstrom/backfill-guard",
      "name": "backfill-guard",
      "codeRepository": "https://github.com/elindstrom/backfill-guard",
      "programmingLanguage": "Python",
      "license": "https://spdx.org/licenses/Apache-2.0.html",
      "dateCreated": "2021-03-14",
      "dateModified": "2026-07-28",
      "description": "A guard rail for Airflow and Dagster backfills. Checks before writing whether a partition window has already been materialised, enforces watermarks and aborts duplicate writes instead of deduplicating them afterwards. Written after a backfill doubled three months of revenue figures.",
      "author": {
        "@id": "https://eriklindstrom.dev/#person"
      },
      "keywords": [
        "airflow",
        "dagster",
        "idempotency",
        "backfill",
        "data-quality"
      ]
    },
    {
      "@type": "SoftwareSourceCode",
      "@id": "https://github.com/elindstrom/pg2iceberg",
      "name": "pg2iceberg",
      "codeRepository": "https://github.com/elindstrom/pg2iceberg",
      "programmingLanguage": "Go",
      "license": "https://spdx.org/licenses/MIT.html",
      "dateCreated": "2022-11-02",
      "dateModified": "2026-08-05",
      "description": "A CDC connector that writes PostgreSQL logical replication straight into Apache Iceberg tables, with exactly-once commits through Iceberg snapshots and automatic schema evolution for additive changes. No Kafka layer required in between.",
      "author": {
        "@id": "https://eriklindstrom.dev/#person"
      },
      "keywords": [
        "cdc",
        "postgresql",
        "iceberg",
        "lakehouse",
        "golang"
      ]
    },
    {
      "@type": "SoftwareSourceCode",
      "@id": "https://github.com/elindstrom/dbt-costlens",
      "name": "dbt-costlens",
      "codeRepository": "https://github.com/elindstrom/dbt-costlens",
      "programmingLanguage": "Python",
      "license": "https://spdx.org/licenses/Apache-2.0.html",
      "dateCreated": "2023-06-19",
      "dateModified": "2026-06-11",
      "description": "Attributes Snowflake and BigQuery query cost to individual dbt models and surfaces it in the pull request. Configurable budgets per model folder, warnings when cost rises above a threshold, export as an OpenLineage facet.",
      "author": {
        "@id": "https://eriklindstrom.dev/#person"
      },
      "keywords": [
        "dbt",
        "finops",
        "snowflake",
        "bigquery",
        "ci"
      ]
    },
    {
      "@type": "SoftwareSourceCode",
      "@id": "https://github.com/elindstrom/skewfinder",
      "name": "skewfinder",
      "codeRepository": "https://github.com/elindstrom/skewfinder",
      "programmingLanguage": "Scala",
      "license": "https://spdx.org/licenses/MIT.html",
      "dateCreated": "2019-09-30",
      "dateModified": "2025-12-02",
      "description": "Reads Spark event logs and names the stages where a handful of tasks dominate runtime. Suggests a concrete remedy for each case, salting, broadcast join or repartitioning, together with the expected effect.",
      "author": {
        "@id": "https://eriklindstrom.dev/#person"
      },
      "keywords": [
        "spark",
        "performance",
        "data-skew",
        "observability"
      ]
    },
    {
      "@type": "Organization",
      "@id": "https://eriklindstrom.dev/#org-nordicshield",
      "name": "Nordic Shield Insurance AB",
      "description": "Property and casualty insurer with around 6,400 employees, headquartered in Stockholm."
    },
    {
      "@type": "Organization",
      "@id": "https://eriklindstrom.dev/#org-nordmark",
      "name": "Nordmark Analytics AB",
      "description": "B2B SaaS vendor for product analytics, around 400 employees, headquartered in Stockholm."
    },
    {
      "@type": "Organization",
      "@id": "https://eriklindstrom.dev/#org-fjall",
      "name": "Fjäll Mobility AB",
      "description": "Carsharing and micromobility operator in eleven Nordic and European cities."
    },
    {
      "@type": "Organization",
      "@id": "https://eriklindstrom.dev/#org-nordicfreight",
      "name": "Nordic Freight Systems AB",
      "description": "Freight forwarding and contract logistics company with its own telematics fleet."
    },
    {
      "@type": "Organization",
      "@id": "https://eriklindstrom.dev/#org-sveabank",
      "name": "Svea Bank Group AB",
      "description": "Regional bank with a corporate banking business in Sweden."
    },
    {
      "@type": "Organization",
      "@id": "https://eriklindstrom.dev/#org-skandiaretail",
      "name": "Skandia Retail Group AB",
      "description": "Grocery retailer operating around 900 stores across Sweden."
    }
  ],
  "x-meta": {
    "origin": "https://eriklindstrom.dev",
    "defaultLanguage": "en",
    "profileType": "person",
    "profileRole": "data-engineer",
    "jobSeeking": true,
    "portraitPath": "/portrait.jpg",
    "ogImagePath": "/og-image.jpg",
    "languages": [
      {
        "code": "en",
        "locale": "en_US",
        "schemaLocale": "en-US",
        "label": "English",
        "homePath": "/",
        "blogPath": "/blog"
      }
    ],
    "keywords": "data engineering, streaming, Apache Iceberg, Kafka, dbt, data contracts, lakehouse, Erik Lindström",
    "titles": {
      "en": "Senior Data Engineer – streaming, lakehouse, data quality"
    },
    "bios": {
      "en": "Erik Lindström builds data platforms for regulated, data-intensive environments. Focus: streaming, Iceberg lakehouses, data contracts and what a pipeline actually costs."
    },
    "slogans": {
      "en": "A pipeline is only finished when somebody else can fix it at three in the morning."
    },
    "longBio": {
      "en": "I came to data engineering through classic data warehousing, back when batches ran overnight and somebody checked the numbers in the morning to see whether they looked plausible. What I took from that is a healthy respect for data quality. What I have learned since is that most problems in data platforms are not technical problems at all, they are contract problems: nobody wrote down who delivers which data with which guarantee. So when I start on a new platform I begin with the interfaces between teams, not with the tooling. Technically I am happiest with Kafka, Flink, Iceberg, dbt and Python, but the tools are interchangeable. What is not interchangeable: idempotency, traceability, visible cost, and the ability to re-run a load without being afraid of it."
    },
    "blogNames": {
      "en": "Late Arriving Facts"
    },
    "social": {
      "linkedin": "https://www.linkedin.com/in/erik-lindstrom/",
      "github": "https://github.com/elindstrom",
      "substack": "https://elindstrom.substack.com/",
      "mastodon": "https://mastodon.social/@elindstrom"
    }
  },
  "x-availability": {
    "status": "open_to_offers",
    "earliestStart": "2026-11-01",
    "noticePeriodMonths": 3,
    "employmentTypes": [
      "FULL_TIME",
      "PART_TIME"
    ],
    "minimumWeeklyHours": 32,
    "workModel": "remote-first",
    "onsiteWillingness": "up to 5 days per month, preferably in one block",
    "willingToRelocate": false,
    "baseLocation": "Stockholm, SE",
    "targetRoles": [
      "Staff Data Engineer",
      "Data Platform Engineer",
      "Lead Data Engineer",
      "Principal Data Engineer"
    ],
    "salaryExpectationSEK": {
      "min": 1050000,
      "target": 1200000,
      "currency": "SEK",
      "period": "P1Y"
    },
    "preferredIndustries": [
      "Insurance",
      "Logistics",
      "Energy",
      "B2B SaaS",
      "Public sector"
    ],
    "dealbreakers": [
      "On-call rotation with no time left for structural improvement",
      "A data platform with no counterpart on the business side",
      "Full-time office attendance"
    ]
  },
  "x-github": {
    "handle": "elindstrom",
    "profileUrl": "https://github.com/elindstrom",
    "followers": 1840,
    "repositories": [
      {
        "name": "backfill-guard",
        "url": "https://github.com/elindstrom/backfill-guard",
        "language": "Python",
        "stars": 1247,
        "forks": 96,
        "openIssues": 14,
        "license": "Apache-2.0",
        "created": "2021-03-14",
        "lastCommit": "2026-07-28",
        "topics": [
          "airflow",
          "dagster",
          "idempotency",
          "backfill",
          "data-quality"
        ],
        "description": "Stops backfills from writing the same partition twice. Watermark registry, partition locks and a dry-run mode that shows which windows would be overwritten.",
        "highlights": [
          "Adapters for Airflow, Dagster and plain cron setups",
          "Locking through Postgres advisory locks or Redis, whichever the team already runs",
          "According to the issue tracker, in use at at least four companies with more than 1,000 DAGs"
        ]
      },
      {
        "name": "pg2iceberg",
        "url": "https://github.com/elindstrom/pg2iceberg",
        "language": "Go",
        "stars": 2903,
        "forks": 211,
        "openIssues": 37,
        "license": "MIT",
        "created": "2022-11-02",
        "lastCommit": "2026-08-05",
        "topics": [
          "cdc",
          "postgresql",
          "iceberg",
          "lakehouse",
          "golang"
        ],
        "description": "PostgreSQL logical replication straight into Apache Iceberg, no Kafka in between. Exactly-once through Iceberg snapshots, additive schema evolution, resume from the last LSN.",
        "highlights": [
          "Around 180,000 row changes per second on a mid-sized instance",
          "Survives a dropped replication slot without a full reload",
          "Configurable compaction so small files do not take over the table"
        ]
      },
      {
        "name": "dbt-costlens",
        "url": "https://github.com/elindstrom/dbt-costlens",
        "language": "Python",
        "stars": 764,
        "forks": 58,
        "openIssues": 9,
        "license": "Apache-2.0",
        "created": "2023-06-19",
        "lastCommit": "2026-06-11",
        "topics": [
          "dbt",
          "finops",
          "snowflake",
          "bigquery",
          "ci"
        ],
        "description": "Per-model cost transparency in the pull request, with budgets per folder and a comparison against the previous week.",
        "highlights": [
          "GitHub Action that posts a comment on the PR",
          "Adapters for Snowflake, BigQuery and Databricks SQL",
          "Exports an OpenLineage facet for downstream lineage tools"
        ]
      },
      {
        "name": "skewfinder",
        "url": "https://github.com/elindstrom/skewfinder",
        "language": "Scala",
        "stars": 411,
        "forks": 44,
        "openIssues": 6,
        "license": "MIT",
        "created": "2019-09-30",
        "lastCommit": "2025-12-02",
        "topics": [
          "spark",
          "performance",
          "data-skew",
          "observability"
        ],
        "description": "Analyses Spark event logs and shows which stages are waiting on individual tasks, with concrete remedies and an estimated effect.",
        "highlights": [
          "Detects skew without adding instrumentation to the job",
          "One HTML report per application",
          "Usually the first thing reached for when a performance ticket lands"
        ]
      },
      {
        "name": "duckhouse-notes",
        "url": "https://github.com/elindstrom/duckhouse-notes",
        "language": "Jupyter Notebook",
        "stars": 288,
        "forks": 31,
        "openIssues": 2,
        "license": "CC-BY-4.0",
        "created": "2024-02-08",
        "lastCommit": "2026-05-19",
        "topics": [
          "duckdb",
          "iceberg",
          "benchmark",
          "notes"
        ],
        "description": "Reproducible notebooks on the question of when a distributed warehouse beats DuckDB on one large machine. Scripts, raw data and the places where the answer is inconvenient."
      }
    ]
  },
  "x-cv": {
    "headings": {
      "en": "Roles and projects"
    },
    "intro": {
      "en": "Around 15 years of data work: nightly batches in retail, real-time telematics, and a lakehouse migration carried out in production. References for individual roles on request."
    },
    "presentLabel": {
      "en": "today"
    },
    "entries": [
      {
        "organization": [
          "Nordic Shield Insurance AB"
        ],
        "period": {
          "start": "2024-06",
          "end": null
        },
        "role": {
          "en": "Senior Data Engineer and Tech Lead, Data Platform"
        },
        "summary": {
          "en": "Built the claims data platform of an insurer: CDC from 14 policy systems, audit-proof historisation and a deletion process that carries GDPR requests verifiably through every layer."
        },
        "stack": [
          "Debezium",
          "Kafka",
          "Apache Iceberg",
          "Trino",
          "dbt",
          "Terraform",
          "AWS"
        ],
        "details": {
          "en": [
            "Replaced 41 nightly extraction jobs with change data capture from 14 policy and claims systems, bringing the availability of current claims data from T+1 down to under 15 minutes",
            "Designed a bitemporal historisation that separates business validity from technical load time, because claims get corrected retroactively and reporting still has to be reproducible",
            "Built the deletion process for data subject requests across the bronze, silver and gold layers, including an audit trail for the regulator and an automated check that deleted keys no longer appear in any materialisation",
            "Introduced data contracts between the policy system teams and the platform: schema, semantic changes and named owners are versioned, and a breaking change breaks the build rather than the reporting",
            "Cut Trino cost by 27 percent through a revised partitioning strategy, file compaction and switching off 60 materialisations that nobody had queried in over a year",
            "Technical leadership for four engineers without line management responsibility, with a weekly architecture review and a deliberately short decision log instead of lengthy concept documents"
          ]
        }
      },
      {
        "organization": [
          "Nordmark Analytics AB"
        ],
        "period": {
          "start": "2022-09",
          "end": "2024-05"
        },
        "role": {
          "en": "Staff Data Engineer"
        },
        "summary": {
          "en": "Migrated a grown Redshift warehouse to an Iceberg lakehouse without downtime while cutting platform cost by 38 percent."
        },
        "stack": [
          "Apache Iceberg",
          "Spark",
          "dbt",
          "Airflow",
          "Snowflake",
          "Python",
          "Kubernetes"
        ],
        "details": {
          "en": [
            "Migrated 2.1 petabytes of raw data and around 640 dbt models to Apache Iceberg, in waves per business domain rather than as one large cutover",
            "Ran both systems in parallel for seven months with automated result comparison: every migrated metric had to match the old system for 30 consecutive days before the old path was switched off",
            "Reduced platform cost by 38 percent, mainly by separating storage from compute, compacting small files and retiring models with no consumers",
            "Introduced dbt-costlens so that teams see the cost of their models in the pull request rather than in the platform's monthly bill",
            "Shortened the evening build on the critical path from 6 hours 20 minutes to 11 minutes, which made product reporting available before the working day started for the first time",
            "Built an onboarding path for new engineers: one week, one real model, one review, instead of four weeks of reading documentation"
          ]
        }
      },
      {
        "organization": [
          "Fjäll Mobility AB"
        ],
        "period": {
          "start": "2020-02",
          "end": "2022-08"
        },
        "role": {
          "en": "Lead Data Engineer"
        },
        "summary": {
          "en": "Built a carsharing company's data platform from scratch, including data contracts between product teams and analytics."
        },
        "stack": [
          "Kafka",
          "Flink",
          "BigQuery",
          "dbt",
          "Looker",
          "Terraform",
          "GCP"
        ],
        "details": {
          "en": [
            "Built the company's first data platform, moving from a collection of scripts running against production replicas to a platform with clear layers, tests and operational ownership",
            "Introduced data contracts between six product teams and analytics, with a schema registry, compatibility checks in the pipeline and a named owner for every event",
            "Built a real-time utilisation model per city district on Flink that drove vehicle redistribution and noticeably reduced empty approach trips",
            "Set up a self-service model in which business departments could contribute their own models in the analytics layer, reviewed by the platform team against binding naming and testing conventions",
            "Made data quality visible in a dashboard that did not show the number of passing tests but the number of affected decisions, which changed how much attention the business paid to it",
            "Grew two engineers from junior to mid level, including on-call duty with honest post-incident reviews rather than blame"
          ]
        }
      },
      {
        "organization": [
          "Nordic Freight Systems AB"
        ],
        "period": {
          "start": "2017-07",
          "end": "2020-01"
        },
        "role": {
          "en": "Senior Data Engineer"
        },
        "summary": {
          "en": "Real-time processing of telematics data from around 9,000 vehicles, from ingestion to arrival-time prediction in dispatching."
        },
        "stack": [
          "Kafka",
          "Kafka Streams",
          "Cassandra",
          "Spark",
          "Scala",
          "Grafana"
        ],
        "details": {
          "en": [
            "Ingested around 40,000 position and sensor events per second from roughly 9,000 vehicles, including handling coverage gaps and events arriving hours late",
            "Designed a processing path that places late events correctly instead of discarding them, because for a delivery what counts afterwards is when it actually happened",
            "Connected arrival-time prediction to the dispatching system, which let dispatchers see delays on average 40 minutes earlier",
            "Wrote skewfinder in response to recurring Spark jobs stuck on a few overloaded partitions, later released as open source",
            "Built monitoring that showed business gaps rather than system metrics: missing vehicles, implausible jumps, silent data sources"
          ]
        }
      },
      {
        "organization": [
          "Svea Bank Group AB"
        ],
        "period": {
          "start": "2014-04",
          "end": "2017-06"
        },
        "role": {
          "en": "Data Warehouse Engineer"
        },
        "summary": {
          "en": "Regulatory and risk reporting, moving from nightly full loads to incremental processing."
        },
        "stack": [
          "Oracle",
          "PL/SQL",
          "Informatica",
          "Python",
          "Hadoop",
          "Hive"
        ],
        "details": {
          "en": [
            "Owned the pipelines behind regulatory reporting, where traceability matters more than speed and every figure has to be explainable back to its source",
            "Converted core load paths from full loads to incremental processing with change detection, which shrank the nightly window from 7.5 hours to 2 hours",
            "Built a reconciliation layer between the core banking system and the warehouse that surfaced differences automatically instead of at quarter end",
            "Documented the business lineage of every reported figure, which was used as evidence in two audits",
            "First exposure to Hadoop and Hive for analyses that no longer ran at acceptable cost in the relational warehouse"
          ]
        }
      },
      {
        "organization": [
          "Skandia Retail Group AB"
        ],
        "period": {
          "start": "2011-10",
          "end": "2014-03"
        },
        "role": {
          "en": "Working Student and Junior BI Developer"
        },
        "summary": {
          "en": "First production pipelines in retail: SSIS, sales reporting and the realisation that Excel exports are an architecture topic."
        },
        "stack": [
          "SQL Server",
          "SSIS",
          "SSRS",
          "T-SQL",
          "VBA"
        ],
        "details": {
          "en": [
            "Developed and operated SSIS packages for sales and inventory reporting across around 900 stores",
            "Replaced 23 grown Excel analyses with standardised reports, after talking to the people who actually used them",
            "Built a simple plausibility check for store submissions that surfaced missing or duplicated daily closings before reporting ran",
            "Wrote a master's thesis on the consistency guarantees of log-based replication alongside the job"
          ]
        }
      }
    ],
    "detailsLabel": {
      "en": "Details"
    }
  }
}
reddit.com
u/According_Fan9094 — 3 days ago

What is LinkedIn useful for or should I quit it?

I was never active in LinkedIn, but the last months I tried it seriuosly. I posted regularly, connected with people and so on.

My observations:

Connections:

There is a kind of pressure to have many contacts, so I added literally everyone who wanted to add me. I don't know these persons. I think it's pointless, because when I want to message someone I know I have to search for the name and sometimes I can't remember the name, I have a bad memory regarding names and so I scroll forever and ever in my connections...

I think it would be better to add only the contacts I want to talk to from time to time, but then I am lame, right? Because this would be max. 100 persons for me. Everyone with a only a few contacts is a loser in LinkedIn, right?

Followers:

I felt somehow impressed that there are really persons who want to follow me. And the funny thing is, they started following me for a random post of mine that was not even very interesting. This post went viral and I don't know why.

When I post now, the post is not distributed to my followers. So again I think it's pointless. People click on follow and then they do not see my post.

And it's the other way round, too. I do not see posts from people I follow.

Feed:

My feed is semi-interesting. Some things are quite useful, but most of the stuff is super boring, so I scroll for 1 minute and then I close the app.

Compared to Reddit:

When I search for a topic that I'm interested in in Reddit, I immediately find something really useful and also I'm entertained from time to time.

My question to you:

I'm thinking about quitting LinkedIn. When I'm searching for interesting content, I will find it in Reddit or elsewhere.

The people that I like - I can also communicate with them via WhatsApp.

For finding jobs and clients - I do not see that this will happen in LinkedIn.

Do I see it too pessimistic? Are there still people that make good experiences with LinkedIn regarding jobs, clients or interesting content?

reddit.com
u/According_Fan9094 — 4 days ago

Codyfied version of yourself and your business - am I the only one seeing this??

The more I work with AI agents, the more I think that at some point, humans will no longer read websites or google things themselves. Instead, they’ll just send out their AI agent to research something. This means that if I'm a business, no matter which size, I absolutely have to be readable for AI agents. I have a website myself, and things can get out of hand incredibly fast.

That’s why I think that ultimately, any person or company looking to connect with others needs a kind of codified version of themselves- like a personal data model. I’ve actually just created something using Schema org that aggregates all my digital identities, my company, and my services in one central place.

And now I’m wondering: am I the only person doing this? In my LinkedIn and Substack bubble, nobody seems to care, and I’m starting to wonder if my line of thinking is a fallacy or if it’s actually highly relevant.

I feel like it needs to go even further than just a JSON file; the entire meaning behind it needs to be codified somehow.

If there are dozens of insurances, what does one insurance distinguish it from the other, when AI agents read your offer and no human watches your advertising videos?

Because if there are hundreds of companies offering the exact same service, which company or service do I choose? There has to be some kind of differentiator.

I’d love to hear from pros like you: am I completely on the wrong track here?

reddit.com
u/According_Fan9094 — 24 days ago

Wer hat eine estnische OÜ?

Hi zusammen, wer hat eine estnische OÜ mit deutscher Betriebsstätte, deutschem Gewerbe und deutscher Umsatzsteuer-ID, also alles legal angemeldet hier? Ich hätte eine Frage per Direktnachricht.

Es geht bei der Frage NICHT um Steuern sparen.

reddit.com
u/According_Fan9094 — 2 months ago

business use case for agentic ai needed!

I'm urgently looking for an exemplary use case that I could build myself at home. It should be realistic enough that it could actually happen in a regulated industry, but it should also be researchable, because I want to build it myself. I want to test something specific and I'm missing a business use case. Thank you very much for your help!

reddit.com
u/According_Fan9094 — 3 months ago

different approach for agentic AI for regulated industry - questions

Last time I learned how to use a graph as a workflow for AI agents. This time I learned something different from a friend.

I think it's brilliant, but I'm looking for other opinions. What do you think about this?

This is a summary of an article that I wrote for my own learning.

The article is free available and contains code examples. The use case is for the finance industry (Europe, strict laws).

I do not sell anything. You can read it. I do not track visitors at all.

I just want to learn it. What do you think about this?

Link to full article in the comment.

Here is the summary:

  1. Action Space: Open Discovery vs. Closed-World
  • AI Agents usually: The agent acts autonomously, dynamically searching for its capabilities (tools) at runtime and deciding freely how to solve a task. This often leads to unpredictable behavior or the agent accessing unauthorized tools.
  • This Approach: The agent operates within a pre-defined, strictly limited decision space. It can only perform actions explicitly listed on a "guest list" (declarative permission). While it can plan within this frame, it can never "invent" new capabilities.
  1. The Role of the LLM: Generalist vs. Pure Copywriter
  • AI Agents usually: The Large Language Model (LLM) handles everything: it manages the process, performs calculations, makes decisions, and writes the final text.
  • This Approach: The LLM sits at the very end of the chain and formulates prose only. It has no decision-making or mathematical authority. Before the LLM is even called, the data passes through a strict ontology-like pack (validity check) and a deterministic rule engine (calculation).
  1. Handling Numbers: Hallucination Risk vs. Physical Impossibility (sealed facts)
  • AI Agents usually: The LLM generates the report including the numbers. There is always a risk that the model will hallucinate or slightly alter figures.
  • This Approach: The LLM does not write a single number. A deterministic rule engine calculates the values and seals them with a cryptographic fingerprint. The model only provides text with placeholders (e.g., "The loss was {loss_percent}%"). Standard code then injects the sealed numbers into the placeholders. Numerical hallucination is therefore physically impossible.
  1. Evaluations (Evals): AI-Judge vs. Deterministic fail-closed
  • AI Agents usually: To find errors, a second AI is often used (LLM-as-a-Judge) to read, interpret, and score the output of the first AI. Or Evals are implemented that test the output after the fact.
  • This Approach: There is no second AI judging the text. The check (fail-closed) is pure code. It compares the generated text against hard rules. If the check fails, the text is discarded and regenerated with stricter constraints.
  1. Auditability & Traceability (Compliance)
  • AI Agents usually: The decision-making process is a black box. For regulators (like BaFin), it is extremely difficult to trace why the AI chose a specific threshold or reached a certain conclusion.
  • This Approach: The architecture is cleanly separated into three auditable layers:
    • Ontology-like: Defines vocabulary and validity (readable by business units).
    • Decision Space: Defines permissions (without calculation logic).
    • Rule Engine: Classic code for calculations.

An auditor can test and sign off on these layers individually, ensuring that AI-generated prose and hard mathematics never get blurred.

In summary: While traditional agentic approaches try to maximize intelligence and autonomy (catching errors afterward via AI Evals), this approach sets hard, deterministic boundaries upfront.

The AI is not an independent actor but a tightly constrained tool within a pre-approved system, which is very helpful in highly regulated sectors like finance.

reddit.com
u/According_Fan9094 — 3 months ago

Why I deliberately chose NOT to use autonomous AI agents in a regulated industry

I am currently learning how to design agentic AI systems. This post is a brainstorm. I would love to hear your perspective: What would you do differently?

The use case is just a random idea:

An investment firm publishes factsheets, quarterly reports, monthly letters, sustainability reports, disclosures, and more. Every publication goes through the same process: pulling data, writing text, compliance review, approval, translation. Portfolio managers spend days on every publication. During a sharp market decline, transparent communication to investors must go out within hours, exactly when the team is most constrained.

The goal: an agentic AI system that pulls the correct figures from four data sources, drafts text in the firm's tone, checks regulatory compliance (SFDR, BaFin, FNG), and delivers a reviewed report the portfolio manager can judge from the outside.

After studying the Anthropic AI agents and workflow patterns, I designed this one:

  • Prompt Chaining as the main pattern. The sequence of the process is fixed: first get numbers, then formulate text, then translate if necessary, then check compliance, then approve. Step 4 logically cannot come before Step 2. Each step is simpler than the overall task.
  • Deterministic Guardian instead of LLM-Evaluator. An LLM as an evaluator would not be reproducible. The same input could produce different results in two calls. This would be difficult for a regulatory (e.g., BaFin) audit. The Guardian should always reach the same verdict with identical input. Therefore, the Guardian is not an LLM; it is rule-based routing: a fixed rule set per publication type.
  • Parallelization in the DataAgent. The DataAgent calls four independent data sources in parallel: Performance, ESG, Composition, and Risk. This is sectioning within a node. The graph remains linear.
  • No Orchestrator-Worker, no Autonomous Agent. Orchestrator-Worker is used when sub-tasks are unpredictable. Here, all sub-tasks are known. An Autonomous Agent would be counterproductive. Freedom of decision in a regulated environment is what you want to avoid.

I look forward to your thoughts. What would you do differently?

The full breakdown including graphics is on my Substack.

reddit.com
u/According_Fan9094 — 3 months ago