Skill for neimo: Indonesia Risk Assessment

Today we're shipping a skill for Indonesia's PP Tunas — it takes your app, checks whether it's in scope, scores it against the regulator's actual instrument, and computes, with citations, where you land, plus a feature-by-feature plan for what to build. It's the most thorough starting point we know how to make for an assessment that, by law, you and your counsel own.

You don't have to fill in a form. Name the app, paste its App Store or Google Play link, or drop your website — the skill reads what your product does from there and drafts the self-assessment Komdigi now requires: it screens whether the product is in scope, scores all 58 statutory parameters against your actual features, computes the risk profile the way the regulation specifies, and — alongside the filing — maps every gap to the specific mechanism that closes it. Add detail if you want to; it'll ask if something material is missing.

The output is the official Kepmen 142 worksheet as an Excel workbook — the one your assessor and counsel actually file — plus a supplementary build plan your engineers can act on.

At a glance:

You can download it here and run it on your own product in minutes. Here's why we built it, what it does, and how to use it.

The problem it solves

Indonesia just moved the floor under everyone serving digital youth there — and it moved fast. Government Regulation No. 17 of 2025, PP Tunas, with its implementing Ministerial Regulation No. 9 of 2026, took effect on March 28, 2026. Every operator whose product can be reached by a child had until June 6, 2026 — four days ago — to file a risk self-assessment with the regulator. The assessment isn't a formality: a high-risk profile pulls in the regulation's most stringent obligations, and the regulator has been explicit that it is assessing real product infrastructure, not just policy.

The hard part isn't knowing the rule exists. It's that the rule isn't one number — it's a precise instrument. A later Ministerial Decree, Kepmen Komdigi No. 142 of 2026, defines it down to the cell: seven risk aspects, 58 coded parameters, each carrying a fixed weight set in law, scored present-or-absent against your actual product. The determination then follows by arithmetic — and a dense obligation surface layers on top:

• Per-feature age gates and threshold ages (chat, forums, profiling, links out)

• Restrictions on targeted advertising and precise location sharing

• Verifiable parental consent for everyone under 18 to be obtained

• Implement default-highest privacy settings, and the dark-pattern / covert-technique prohibition

• Overarching obligation to carry out age assurance

Reading the regulation tells you none of that maps cleanly to your build. And the law is explicit that the assessment can't be done from a single point of view — it requires a multidisciplinary team, because the risk surface spans content, contact, consumer, data, addiction, psychological, and physiological harm. Which is why the law puts the work in your hands, requires a real team behind it, and gives Komdigi the final call.

That leaves teams with two (not ideal) options: start the whole thing from a blank page and a PDF of the regulation, or wait on a bespoke assessment that lands at "you're high-risk" and leaves the engineering undefined. The skill is the third option. It renders the regulator's instrument faithfully — screens scope, scores all parameters against your product, computes the determination, and sources the obligation surface live — and then keeps going, because a starting point that stops at the verdict is half a deliverable. It finishes the job by laying out what to put in front of which feature, at what age, so the team that owns the decision starts from a structured, cited draft instead of nothing.

What it does, step by step

Point it at your product and the skill does seven things:

1. Reads your product from whatever you give it. A name, a store listing, a URL — it works out the social features you run (text, voice, video chat, forums, links out, recommendations), your identity and profile surfaces, your monetization (microtransactions, loot boxes, trading, subscriptions, ads), your data and profiling posture, and your engagement mechanics, and asks you only about what it can't see.

2. Screens whether you're even in scope. Kepmen 142's Appendix I gives five indicators — child-directed terms, a significant child user base (at least 25 child users), child-directed advertising, child-attracting design, or close similarity to a product proven to be used by children. Fulfilling any one puts you in scope. The skill records each with a note and renders the verdict.

3. Scores the seven aspects across all 58 parameters. For each parameter it marks the technical configuration present or absent against your actual features, attaches the supporting evidence the law requires (specs, model cards, UX research), and notes the specific mitigation where a control is in place. The fixed legal weights and the scoring rule do the rest — there's no severity guesswork to argue about. The seven aspects, and the kind of feature that drives each one:

4. Computes the determination — it doesn't guess it. This is arithmetic the law specifies: each parameter's weight counts toward its aspect; an aspect is high-risk when its weighted score exceeds 50%; and the product carries a HIGH-RISK profile if any single one of the seven aspects crosses that line. The driving aspects stay visible so a reviewer can interrogate them. The skill never overrides the computed score — and the Director General makes the final, binding determination after verification.

5. Convenes the multidisciplinary review the law requires. The skill stands up an Assessor panel keyed to the functions Kepmen 142 names, each owning the aspects in its lens:

Where a lens isn't held in-house, an external assessor must bring it — the law sets a minimum-expertise bar (child psychology, child physiology, IT, security and data protection, legal, and digital marketing). The worksheet carries a sign-off panel so each reviewer signs the aspects they own.

6. Builds the feature-by-age gating matrix — grounded live in neimo. The parameters and weights are fixed law, embedded in the skill. The obligation surface that attaches to your profile — age assurance, verifiable parental consent, monetization floors, the dark-pattern prohibition, notices, takedown duties — is pulled live from neimo., k-ID's regulatory knowledge base, with a verbatim citation on every line, and mapped to the specific k-ID mechanism that enforces it. This layer is supplementary to the filing: an engineering blueprint, not part of what you submit.

7. Writes the Excel worksheet. A multi-sheet workbook:

• Determination — per-aspect scores with the >50% flags, the computed HIGH/LOW profile, an incomplete-parameter warning, and the proviso

• Scope screening — the five Appendix I indicators and the in-scope verdict

• Seven aspect sheets (KK / KN / EK / DP / AD / GP / GF) — the worksheet proper: every parameter, its YES/NO status, the fixed weight, your justification, the evidence reference, and the per-aspect subtotal

• Assessor & sign-off — the required functions, the lens each owns, and the minimum-expertise note

• Supplementary tabs — remediation/gating matrix, the full obligation list, and sources, each clearly fenced off and labelled not part of the filing

It proposes; a qualified, multidisciplinary assessor and counsel review and file. Nothing is auto-filed for you.

What a finding looks like

Here's the shape of the output. Say your product is a social game with public chat, loot boxes, and self-declared age at sign-up.

The Determination sheet opens with the computed profile and the aspects that drove it, for example:

Then the supplementary gating matrix turns that into a per-feature build list:

Source for every supplementary row: neimo. → ID → PP Tunas / Permen 9/2026, tracing to Government Regulation No. 17/2025 and the relevant Komdigi instruments.

Three rows, three ages, three mechanisms, three gaps. The full obligation list runs to twenty-plus lines, each with an owner and a citation.

Where it's most valuable

The skill earns its keep wherever a product reachable by Indonesian minors has to turn a new, fast-moving regulation into a build plan. Where teams feel it most:

You haven't filed, or you filed and aren't sure the build matches. The deadline has passed and the regulator has been explicit that it's assessing real product infrastructure, not just policy. A sourced, feature-mapped worksheet is what your assessor walks into the filing with — counsel reviewing a structured document instead of starting from a blank page.

You need the review to hold up. The law requires a multidisciplinary team, not a single sign-off. The skill convenes that review by design — each aspect scored through the lens that owns it — so the assessment reflects child-development, security, and marketing perspectives, not just engineering's.

Social features are your risk concentration. Open chat, account discovery, and unconnected-user reach are exactly the parameters that push the contact aspect over 50%. The skill surfaces them on purpose, not after the fact.

You run a portfolio across markets. One assessment per game, per app multiplies fast. The skill runs the identical, deterministic instrument across all of them and produces a comparable worksheet each time.

Self-declaration is still load-bearing in your stack. PP Tunas treats it as a high-risk consent method and requires assurance "commensurate with the degree of risk" — for both the child and the consenting parent. The skill catches that before it bites.

How to run it

Install the skill, then just point it at your product:

• "Run a PP Tunas risk assessment on this: [App Store link]."

• "Draft our PP Tunas self-assessment so I can take it to counsel — where does the scoring land, and why?"

• "Here's our website — build the Indonesia gating matrix and tell me what to gate first."

Any of these gets it started: a name, a store link (App Store or Google Play), a website, or your own feature notes.

It works as a one-off scoping pass, or as a scheduled re-check — Indonesia's rules are young and still settling, so a worksheet should be re-baselined when the next implementing guidance lands. The skill version-pins the parameter catalog and checks neimo. for amendments on each run, so the watch keeps itself current.

You can download it here and run it on your own product today.

Where it fits

The skill sits on top of the same two pieces that power everything else we ship.

neimo. is the part of k-ID that knows the rules — the structured, sourced record of what's required in 200-plus markets, including the Indonesia obligation surface this skill reads on every run to ground the build plan.

The k-ID mechanisms it maps each gap to — the age gate, AgeKit+ age assurance, verifiable parental consent, session permissions, threshold verification — are the same ones in the CDK that powers more than 45 million users every day.

The skill is the bridge: it renders the regulator's instrument faithfully, then turns the obligations that attach to your result into which control sits in front of which feature, at what age, age-aware in real time.

That's what we're shipping: a way to take a brand-new Indonesian law and hand it back to your engineers as a list of things to build — so the protection for an Indonesian kid is real in the product, not just stated in a filing.

Download it here and assess your own product today.

-- Kieran

Buildable 04 — A k-ID series on making AI buildable for digital youth, and for the teams shipping to them