Skip to content

lina767/chipsettle

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

23 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

ChipSettle

A navigator that helps semiconductor companies identify which policy instruments, funding programs, and legal requirements apply when establishing an additional design site in Europe — with a focus on Germany.

It closes a documented policy gap: no single point exists where a company can assemble the full picture of fiscal instruments, funding programs, visa pathways, and legal requirements across EU member states for semiconductor design settlement. The information exists but is scattered across national tax codes, EU regulations, and program websites that do not reference each other.

Core idea

A structured filter and decision engine, not a chatbot. Every answer comes from a verified database entry with a legal basis, a source link, and a verification date. No answer is generated by a language model — legal and fiscal information must be traceable to a source.

User flow

  1. Wizard (/wizard) — a 3-step company profile: basics (HQ, business model, size, revenue, sectors), goal, and target countries.
  2. Dashboard (/results) — the decision engine filters the instrument database to the profile, groups results by country, and shows a side-by-side comparison. Each instrument card carries eligibility status, key parameters, legal basis, source link, and verification date. Export to PDF via print.
  3. Comparison (/compare) — the killer feature: 2–4 countries side by side for the profile, with live country toggling.

Tech stack

  • Astro 5 with React 19 islands for the interactive components (wizard, dashboard, comparison).
  • Tailwind CSS 4 for styling (via @tailwindcss/vite).
  • Fully static output — deployable to Vercel or any static host.

The data layer (src/data/*.ts) is shaped 1:1 to the Payload CMS collection schema so it can be swapped from local TypeScript to the Payload REST API without touching the decision engine or the UI (see CMS migration below).

Project structure

src/
  data/            Seed data (1:1 with Payload collections)
    countries.ts     countries collection
    instruments.ts   instruments collection (16 seeded, verified 2026-07-03)
    ecosystems.ts    ecosystems collection
    legalSteps.ts    legal_steps collection
  lib/
    types.ts         Shared types mirroring the CMS schema
    engine.ts        The decision engine (pure, deterministic filter + scoring)
    labels.ts        Enum -> label maps, colour coding, date/staleness helpers
    profile.ts       CompanyProfile <-> URL query-string serialization
  components/        React islands + shared card/badge components
  pages/
    index.astro          Landing page
    wizard.astro         3-step wizard
    results.astro        Personalized dashboard
    compare.astro        Country comparison
    country/[slug].astro Country detail (all instruments, ecosystems, steps)
    instrument/[slug].astro  Instrument detail (full parameters + changelog)
    changelog.astro      Global changelog + upcoming changes
    methodology.astro    How the engine works, verification, coverage notes
    about.astro          Project context

The decision engine

src/lib/engine.ts is a pure function. It runs hard filters (status, country, HQ, business model, size, sector, goal), then assigns each surviving instrument an eligibility status (eligible / likely_eligible / conditional / not_eligible) and a transparent relevance score. Scoring weights rule-based entitlements over discretionary programs, active over proposed, and fiscal impact for the selected goal. Profile-specific notes (e.g. the €750M Pillar Two interaction with IP boxes) are generated from structured data, not inferred.

The full scoring rationale is documented on the /methodology page.

Data & verification

  • 16 instruments seeded for Germany, the Netherlands, Belgium, France, Spain, and the EU level, all verified as of 3 July 2026.
  • Every instrument carries last_verified, verification_source, next_review_date, and a changelog. Entries older than 6 months surface a staleness warning; recent changes surface a badge.
  • Entries marked needs_verification carry specific figures still to be confirmed against the primary source (surfaced as a badge in the UI).
  • Proposed instruments (EU Chips Act 2.0) are flagged as PROPOSED throughout.
  • is_absence entries (e.g. Germany has no IP box) are shown so comparisons stay honest, ranked below real instruments.

Development

npm install
npm run dev      # dev server at http://localhost:4321
npm run build    # static build to dist/
npm run preview  # preview the built site
npm run check    # astro + TypeScript type check

CMS migration (Payload)

The types in src/lib/types.ts mirror the intended Payload collections (countries, instruments, ecosystems, legal_steps) field for field. To move from local seed data to a self-hosted Payload backend:

  1. Create the Payload collections matching types.ts.
  2. Import the seed data from src/data/*.ts.
  3. Replace the static imports in src/data/*.ts with fetches to the Payload REST API. The engine and UI consume the same shapes, so nothing else changes.

The admin panel then becomes the maintenance interface: a non-technical editor can update parameters, add changelog entries, set review reminders, and refresh verification dates without code changes.

Disclaimer

This tool provides structured policy information for orientation purposes. It does not constitute legal, tax, or investment advice. All parameters are verified as of the dates shown and may have changed. Consult a qualified advisor before making decisions.

About

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

 
 
 

Contributors