Compliance Brief · v1.0 · Planwright Inc.
How Planwright satisfies the 2026 AICPA Trust Services Criteria for AI-generated code.
Written for compliance teams, internal auditors, and the external SOC 2 firm reviewing your AI-assisted development workflow. This is a technical brief, not a sales page — what the audit primitives are, how they map to the framework, and what you can independently verify without trusting us.
The 2026 update
Why a kanban board is no longer enough.
The April 2026 revision of the AICPA Trust Services Criteria tightened the change-management and monitoring requirements when AI generates production code. CC6.1, CC7.2, and CC9.2 now expect an attributed, tamper-evident record of which agent produced which change, which human reviewed it, and which key signed off — preserved with cryptographic integrity for the retention period.
A traditional kanban tool records who clicked “Done.” A git history records the diff. Neither captures the full decision chain, and neither produces an artifact an auditor can verify without trusting the platform vendor. The 2026 criteria assume the evidence is hostile-environment-resistant: an admin should not be able to silently rewrite history.
Planwright was built for this requirement. The audit ledger is the first-class data model; the planning board is the UI on top of it.
The audit primitives
What an auditor actually receives.
Append-only ledger
Every audit record is written once and never updated or deleted. Corrections are new records that reference the prior subject. The objective table itself can be edited; the ledger about it cannot.
Per-workspace ECDSA P-256 key in AWS KMS
Each workspace mints its own signing key. Keys live in AWS KMS — the service holds a reference, never the private key bytes. KMS provides FIPS 140-2 Level 2 boundary and a tamper-evident usage log of its own.
Hash chain + ECDSA signature on every record
record_n.payload_hash = SHA-256(canonical_json(payload)). record_n.chain_hash = SHA-256(record_{n-1}.chain_hash || record_n.payload_hash). KMS signs chain_hash with ECDSA_SHA_256. Verifying the chain re-derives both hashes and asks KMS to verify the signature.
Nightly external verification
A scheduled task reads every workspace's chain end-to-end and writes a verification record back. Any drift is alerted. The same verification logic runs on demand from the public trust page.
Record schema
What every audit row contains.
Every audit record carries the same shape. The chain hash binds it to the prior record; the signature binds it to the workspace's KMS key.
{
"id": "uuid",
"workspace_id": "uuid",
"sequence": 42, // strictly monotonic per workspace
"actor_type": "human" | "agent",
"actor_id": "uuid (user) | string (agent kind)",
"event_type": "objective.created" |
"objective.lane_changed" |
"agent.run.started" |
"agent.run.diff_recorded" |
"objective.acceptance_requested" |
"objective.accepted" |
"phase.released" |
"...",
"subject_type": "objective" | "agent_run" | "phase" | ...,
"subject_id": "uuid",
"payload": { /* event-specific structured data, no free text */ },
"payload_hash": "sha256(canonical_json(payload))",
"prev_hash": "chain_hash of record N-1 (nullable for record 0)",
"chain_hash": "sha256(prev_hash || payload_hash)",
"signature": "ECDSA_SHA_256 over chain_hash, KMS key per workspace",
"kms_key_id": "arn:aws:kms:...",
"created_at": "RFC3339 timestamp"
}payload is structured JSON, never free text. An objective.lane_changed record carries { from, to }; an agent.run.diff_recorded record carries { files_changed, tests_passed, diff_s3_key }. Free-form notes go in a note field, hashed the same way as everything else.
Trust Services Criteria mapping
Each criterion, what we capture.
This mapping is informational. It does not replace your SOC 2 engagement, your auditor's judgment, or your own control documentation — but it gives you the raw evidence to map against your existing controls.
Independent verification
You don't have to trust us.
Each workspace has a public trust page at /trust/<workspace-slug> listing the chain length, the latest chain hash, the workspace's KMS key id, and the most recent automated verification result.
The verification logic is straightforward: re-derive each chain_hash from prev_hash and payload_hash, confirm it matches what's stored, then ask KMS Verify to check the signature against the workspace's public key. Any drift in any record is detected by the next pass.
The signed export bundle (JSON of every record + the public key + a verification README) is portable. Your auditor can verify it from their own laptop using the AWS CLI or any ECDSA library — no Planwright login required.
What this brief does NOT claim
Honest scope.
- ·Planwright is not your SOC 2 audit. The audit chain is evidence; you still need an engagement with a qualified firm and your own control narratives.
- ·Planwright is not a code-level scanner. We track decisions and approvals around the work; static analysis, SBOM generation, and dependency scanning belong in your CI.
- ·The audit chain captures attributed events, not source-of-truth code. The diff is referenced by S3 key and recorded in the chain; the chain's integrity proves the metadata wasn't altered, not that the code itself is correct or vulnerability-free.
- ·SOC 2 attestation letter availability follows our own audit cycle. Type I in late 2026, Type II planned for 2027. Until then, the cryptographic chain is the proof we offer.
See it on a real chain.
The Planwright workspace itself runs on the same audit ledger. Open our public trust page and verify the live chain in your browser.