* Shaping: MEDDIC qualification, ROM estimate, SoW draft

* Mobilisation: Charter, RACI, governance, kickoff

* Planning: Plan, capacity, budget baseline, estimate challenge

* Execution: Weekly status, RAID, standup digests, blocker triage

* Governance: Steering packs, exec summaries, stakeholder updates, escalation memos

* Risk and change: Risk deep-dives, change requests, mitigation, escalations

* Technical-quality oversight: SDLC, QA, systems engineering, secure-SDLC health checks

* Commercial: Budget tracking, margin analysis, change orders, invoice backup

* People: Team health, attrition risk, ramp plans, one-to-one prep

* Closure: Checklist, retrospective, lessons, case study, handover

Outputs are audit-ready markdown, each linked back to its charter revision, source documents, model, and prompt hash.

The engagement charter is a 'living constitution' that every artifact reconciles to.

Anything leaving your machine (steering decks, exec memos, change orders, SoWs) passes through an adversarial red-team gate first.

Local-first, and engagement data never leaves your disk.

npx @systima/project-delivery-framework

https://github.com/systima-ai/project-delivery-framework

We built this because the "AI for project management" space is almost entirely tooling for product management.

The framework is for the person running the multi-month, multi-stakeholder engagement (budget, the client, the team, and the contract, etc).

Comments URL: https://news.ycombinator.com/item?id=48271766

Points: 2

# Comments: 0

I recall the Beeper Mini debacle not so long ago, and fear that this may be a house built on sand.

The engineering-focused findings have been covered extensively (fake tool injection, Undercover Mode, KAIROS, etc).

This piece focuses on what these findings mean if you're using Claude Code to build AI systems subject to the EU AI Act.

TL;DR / spoiler:

Claude Code isn't a high-risk AI system in and of itself.

The EU AI Act regulates your deployed system and your process, not your tool vendor's internal engineering practices.

What caused the switch was that we're building AI solutions for sometimes price-conscious customers, so I was already familiar with the pattern of "Use a superior model for setting a standard, then fine-tuning a cheaper one to do that same work".

So I brought that into my own workflows (kind of) by using Opus 4.6 to do detailed planning and one 'exemplar' execution (with 'over documentation' of the choices), then after that, use Opus 4.6 only for planning, then "throw a load of MiniMax M2.5s at the problem".

They tend to do 90% of the job well, then I sometimes do a final pass with Opus 4.6 again to mop up any issues, this saves me a lot of tokens/money.

This pattern wasn't possible with Claude Code, thus my move to Open Code.

Hugely grateful for what they do.

In my experience, this correlates more with soft skills and “one man band” founder/maker companies that tend to sell training products or (if they do exist in a company environment at all) invariably work in DevRel and aren’t pushing code.

I think it’s more about setting a norm and precedent that “Age verification is not our responsibility; the App Store layer does that and it’s an established truth now”.

Which itself conveniently helps as a defence in lawsuits when a teenager kills themselves over harmful content etc.

`npx @systima/comply scan` analyses your repository to detect AI framework usage, traces how AI outputs flow through the program, and flags patterns that may trigger regulatory obligations.

It runs in CI and posts findings on pull requests (no API keys required).

Under the hood it performs AST-based import detection using the TypeScript Compiler API and web-tree-sitter WASM across 37+ AI frameworks. It then traces AI return values through assignments and destructuring to identify four patterns:

1. conditional branching on AI output

2. persistence of AI output to a database

3. rendering AI output in a UI without disclosure

4. sending AI output to downstream APIs

Findings are severity-adjusted by system domain. You declare what your system does (customer support, credit scoring, legal research, etc) and the scanner adjusts accordingly.

Example:

- a chatbot routing tool using AI output in an `if` statement produces an informational note

- a credit scoring system doing the same produces a critical finding

We tested it against Vercel’s 20k-star AI chatbot repository; the scan took about 8 seconds. Example PR comment with full results: https://github.com/systima-ai/chatbot-comply-test/pull/1

Comply ships as an npm package, a GitHub Action (systima-ai/comply@v1), and a TypeScript API. It can also generate PDF reports and template compliance documentation.

Repo and explanation: https://systima.ai/blog/systima-comply-eu-ai-act-compliance-...

Feedback welcome on the call-chain tracing approach and whether the domain-based severity model makes sense.

Comments URL: https://news.ycombinator.com/item?id=47376869

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=47267341

Points: 3

# Comments: 2

It would definitely work (and when dealing with petabyte levels of data the simplicity of only having to delete the key is convenient).

We’re leaning toward the dual-layer separation I described though (metadata separate to content) mainly because crypto-shredding means every read (including regulatory reconstruction) depends on a key store.

In my view that’s a significant dependency for an audit log whose whole purpose is reliable reconstructability, whereas dual-layer lets the chain stand on its own.

Your point about developer mistakes is fair. It applies to dual layer as you say with your example, but I’d say crypto shredding isn’t immune to mistakes because (for example) deleting the key only works if the key and plaintext never leaked elsewhere accidentally in logs / backups etc.

voxic11 is right that the AI Act creates a legal obligation that provides a lawful basis for processing under GDPR Article 6(1)(c).

To add to that, Article 17(3)(b) specifically carves out an exemption to the right to erasure where retention is necessary to comply with a legal obligation.

(So the defence works at both levels; you have a lawful basis to retain, and erasure requests don’t override it during the mandatory retention period).

That said, GDPR data minimisation (Article 5(1)(c)) still constrains what you log.

The library addresses this at write-time today, in that the pii config lets you SHA-256 hash inputs/outputs before they hit the log and apply regex redaction patterns, so personal data need never enter the chain in the first place.

This enables the pattern of “Hash by default, only log raw where necessary for Article 12”.

For cases where raw content must be logged (eg, full decision reconstruction for a regulator), we’re planning a dual-layer storage approach. The hash chain would cover a structural envelope (timestamps, decision ID, model ID, parameters, latency, hash pointers) while the actual PII-bearing content (input prompts, output text) would live in a separate referenced object.

Erasure would then mean deleting the content object, and the chain would stay intact because it never hashed the raw content directly.

The regulator would also therefore see a complete, tamper-evident chain of system activity.