Maze-Guild

1 For the user lasting

2 For the thinker lasting

One continuous relation between worker, customer, work and learning. The test for every function: does it strengthen that relation, and does it stay within the law?

Where it comes from. The Guild is a spin-off of the Maze-Bank (the idea: value stays in the circle of people, short loops, cooperation at a human scale) and of SWARP Support (working parts: account, profile, occupation list, learning from cases). Work, craft and learning are a community's real float; intermediaries now take much of it.

Learning from failure. After Roger Schank: you learn when an expectation fails, and you remember the lesson as a story. Hence the cases (what did you expect, what happened, how did you solve it, what will you do differently), the ladder for a help request, and the failures from the trade.

People decide. The Guild proposes, counts and reports. Choosing, accepting, admitting, confirming and deciding a dispute are done by people, and every decision is in a hash-chained ledger that can be redacted under the GDPR.

Deliberately outside the Guild, and why: personality tests and automated CV screening (judging on traits; high-risk under the AI Act, Annex III point 4); emotion recognition (banned at work, AI Act Art. 5(1)(f)); biometrics such as face matching (special-category data); age as a matching criterion (Dutch WGBL Art. 3); harvesting profiles from other sites; paying wages itself (the operator does that outside the Guild).

Age. The only place age counts is a legal prohibition: work young people under 18 may not do. For that the Guild knows two states, 16–17 and 18 or older, in the private layer; no birth date. That way the Guild follows the rules for young workers without letting age weigh in.

The rules

Every refusal names the rule. These are all of them (the Dutch wording in the code is leading):

• R-koppelenA worker is proposed only if admitted and active, at least at the required level for every required skill, holding a valid certificate where the work legally needs one, living within their own travel distance, and available.
• R-duoAn apprentice is proposed only if the customer has 'apprentice welcome' on and the apprentice wants to learn a required skill not yet at level 3. The experienced worker remains responsible. Where the work legally needs a certificate, the apprentice needs it too (provisional, cautious choice).
• R-gatIf nobody meets R-koppelen, the tool reports a gap with the step where it failed. The tool never invents a match.
• R-kiezenA match exists only when the customer chose a proposal and the worker (and in a pair the apprentice) accepted. Whoever declines is not proposed again for that work.
• R-niveauThree levels per skill: 1 observed, 2 done under supervision, 3 done independently. Only an experienced worker with level 3 in that skill confirms an apprentice's level, on work where they are the responsible worker.
• R-erkenningWork that legally needs a certificate goes only to workers with a recorded certificate that is valid on the day of matching.
• R-casesA case is a contribution, not a stain: visible to workers and apprentices, never to customers. The profile only shows the count.
• R-leeftijdBirth date and age are not stored. A worker or apprentice gives only an age group at sign-up: 16–17 or 18 and older (under 16 cannot sign up). It sits in the private layer and counts in one place: work marked 'not under 18' (legally forbidden for young people) does not go to someone aged 16–17. Not in the ranking, never visible to customers, not on the profile or in the export.
• R-privacyReal people are admitted only once a DPIA, a processing agreement and a privacy statement are recorded.
• R-avgEveryone sees everything recorded about them and can delete it. In the ledger the fields about the person are wiped; the chain stays verifiable. Lessons and cases remain without maker. A customer's work remains without customer; for a private person description, photos and postcode are wiped.
• R-bewarenLogin links 1 day, outgoing mail 1 day, expired sessions at once, lapsed or declined proposals 90 days, resolved gaps 2 years; completed work older than 2 years loses description, photos and customer comment; deactivated accounts are deleted after 2 years; cases remain as anonymous contribution; messages 2 years after the work ends; the log of who viewed a profile 2 years; delivered webhooks 90 days; time slots 1 year.
• R-mensAdmitting, certifying, choosing, accepting, matching and confirming are acts of people and are in the ledger with who, when and why.
• R-geschilAt review the customer confirms the hours. Fewer hours or 'not done' is a dispute: nothing is booked in the circle until the administrator decides. A customer below the credit limit can always review; the payment then stays open.
• R-contractAt acceptance the worker decides whether to be paid: exchange between members (seeds in the circle), volunteer (no reward), or in euros (employment, payroll, pension-age employee, self-employed). The customer does not choose. An apprentice in a pair always works in employment or work-based training.
• R-loonHours in employment are booked at the edge in euros, never in seeds.
• R-vergunningWork for which the operator has no valid licence cannot be posted (labour-provision licence for payroll, recognised training company for apprentices, certificate per work type).
• R-vogWork in a home, in care or at a school goes only to workers and apprentices with a valid certificate of conduct (VOG).
• R-kredietA member may not go below the circle's credit limit.
• R-nulEvery entry in the circle balances: the sum is zero.
• R-randIn the circle only seeds are booked. Euros belong at the edge and are a registration, not a payment or exchange.
• R-borgA training on guarantee starts only with the agreed number of guarantors; a guarantee is only in seeds. When behind, the guarantors hear first, the administrator a cycle later.
• R-kringThe members set issue, decay and the order per cycle; the administrator executes. No interest, no exchange.
• R-videoA lesson or case may carry at most two own videos of at most two minutes each (mp4 or mov, up to 60 MB). Workers, apprentices and the administrator see them, customers do not. Nothing is converted or analysed. If the maker deletes their data, their videos are wiped; the lesson or case remains. A video that belongs nowhere after a day is cleaned up.
• R-vakEvery work type has an occupation from the Swarp Support occupation list (O*NET). Workers, apprentices and the administrator see the failures of that occupation from Support, each with its provenance: source (body and link), invented example, or cannot be verified. An invented example never carries the name of a body. Customers do not see them. If Support cannot be reached, the Guild says so.
• R-beeldLive video goes directly between the phones and is not analysed. A snapshot is kept only if asker and master both consented.
• R-berichtMessages belong to one piece of work. Customer (and members of the organisation), worker and apprentice write; the administrator reads along. Recipients get a notification, and an email if they have that on. Kept until 2 years after the work ends; whoever deletes their data leaves '(deleted)'.
• R-vraagWorkers, apprentices and the administrator can ask and answer questions on a lesson or case. Customers do not see them. The maker of the item gets a notification.
• R-toelichtingWhoever confirms a level may add a short note. Only the apprentice and the confirmer see it: not on the profile, not in the export, not for customers. No grade and no ranking.
• R-exportThe export of demonstrated work carries a verification code. With the code the Guild gives, without login, the date, the name and the hash of the export; the recipient recomputes the hash. If the person deletes their data, their codes lapse.
• R-2faIn the live environment the administrator and organisations log in with a second factor (a code from an app). Until it is set up, they can only set it up. Logging in via an organisation's identity provider (OpenID Connect) works only for an existing account with the same verified email address.
• R-apiAn organisation or administrator creates a read-only API key (shown once, stored as a hash) and webhooks to an https address. A webhook names only the kind of event, ids and the time, never names, and carries a signature.
• R-afspraakThe work agreement is a pdf from a fixed template. Customer and worker sign in the tool: the hash of the pdf, who and when are recorded. That is a simple electronic signature; a qualified one needs a contract with a signing service.
• R-idThe administrator records that an identity check or a check at the source took place: service, date and outcome. No document image, no face, no document number.
• R-afwezigA worker reports a period of absence without a reason. During that period they are not proposed; the customer of their ongoing work gets a notification and can request a replacement.
• R-verlengenOngoing work ends after its duration. Two weeks before, customer and worker get a notification. An extension happens when the customer proposes it and the worker accepts.
• R-roosterFor ongoing work, customer and worker agree which half-days are worked: one proposes, the other confirms. The number equals the half-days per week.
• R-samenvoegenTwo accounts of the same person are merged only if the second account has no work, proposal, circle, help or ledger entry as decision-maker yet. Levels, certificates and organisations move over.
• R-toegangWhoever views another person's profile or practice hours is logged. The person sees in their data overview who viewed them and when. Kept 2 years.
• R-ladderThe tool answers only with the literal text of an own case or lesson, with the source. Without a source the question goes to a master: first the own master, then another with level 3 in that skill.

3 For the builder moves with the code

A standalone Node application (Node 20, one dependency: pg). One server is one environment (GUILD_OMGEVING=demo|echt) with its own Postgres database.

• src/server.mjs — HTTP, sessions, the second factor, API keys, routes; every route carries a key from src/rechten.mjs.
• src/guild.mjs — the core: posting, matching (with absence and 'not under 18'), choosing, delivering, levels, lessons, cases, GDPR, retention, the demo.
• src/dienst.mjs — the v8 service layer: messages, questions, verification code, overviews, hours export, actions, daily task, work agreement and signing, checks, Chamber of Commerce, time slots, schedule, absence, extension, invitation links, duplicates, API keys, shortage analysis.
• src/grootboek.mjs (hash chain, a commitment per field, redactable), src/kring.mjs (the circle), src/hulp.mjs (the ladder and live video), src/video.mjs, src/support.mjs (Swarp Support), src/mail.mjs, src/totp.mjs, src/oidc.mjs, src/webhook.mjs, src/pdf.mjs (own pdf writer).
• public/ — the page (NL/EN) and controleer.html; docs/ — plans (each hashed before the code), test report, specification and this manual (scripts/handleiding.mjs).
• scripts/backup.mjs and scripts/terugzet-toets.mjs — encrypted backup (AES-256-GCM, 35 days) and a restore test that checks the ledger chain.

Settings: DATABASE_URL, GUILD_OMGEVING, GUILD_SLEUTEL (required live), GUILD_URL, BREVO_API_KEY and MAIL_FROM, OPENAI_API_KEY, SUPPORT_URL and SUPPORT_GEHEIM, GUILD_OIDC_ISSUER/_CLIENT_ID/_SECRET, KVK_API_KEY, GUILD_BACKUP_SLEUTEL, GUILD_ACHTER_PROXY, GUILD_DAGTAAK=uit (tests only).

Hosting: in the EU (Render, Frankfurt region), behind https (the server then sets HSTS). Data at rest is encrypted by the host's database; backups are encrypted by the Guild itself. A third-party security test belongs before the first real users.

Tests: node toets/toets.mjs runs all acceptance tests against two empty test databases, with a simulated Swarp Support, a simulated identity provider, a webhook receiver and a simulated Chamber of Commerce. Test DR checks that this manual names every route and every rule.

4 For the connector moves with the code

Logging in for systems. An organisation or the administrator creates an API key under Integrations. Use: Authorization: Bearer gld_…. A key is read-only, and only for: overzicht, export.uren, werk.mijn, organisatie.overzicht, acties. GET /api/beschrijving returns all routes with their rights as JSON.

Webhooks. Events: werk.gemeld, voorstel.gekozen, werk.gekoppeld, oplevering.gemeld, oplevering.beoordeeld, niveau.bevestigd. The body is { soort, werk, …ids, op }, without names. Check the header x-guild-handtekening:

const ok = header === "sha256=" + crypto.createHmac("sha256", secret).update(rawBody).digest("hex");

A receiver that does not answer 2xx gets the event twice more, with increasing pauses.

Logging in via the organisation (SSO). OpenID Connect with PKCE; redirect address <GUILD_URL>/api/oidc/terug; scopes openid email profile; RS256 only. SAML is not supported.

Swarp Support. The Guild reads occupations and failures with the shared secret (x-swarp-secret) via /api/beroepen/namens and /api/failures/namens.

Signing with a service. The Guild signs itself with a simple electronic signature (hash of the pdf). A qualified signature needs a contract with a service; the field ondertekening.dienst is reserved for that.

Verification code. GET /api/controleer?code=GLD-… returns name, date and hash. The hash is sha256 of the export without the field controle, as JSON without spaces in the order of the file.

All routes

Method, path, rights key, who may, and what it does. On top of these rights, object rights apply (a customer sees only own work, a worker only work they are matched to).