Reference
·
Chapter 1b
Regulatory Traceability Matrix
Purpose: Map every functional requirement, design decision, and policy control in the youPersonic platform to the specific regulatory clauses that require it. This is the document a compliance officer or regulator requests first. It answers: "For each capability you built, show me exactly where the regulatory obligation comes from."
The seven capability layers in Chapter 1 were designed from regulatory requirements, not toward them. This matrix makes that origin explicit. Every row maps one platform requirement to its regulatory source, its capability layer, its technical implementation, and its current status.
Gap rows — requirements without a completed implementation — are included deliberately. A traceability matrix that only shows what is done is not a compliance document. It is a marketing document.
Req ID
Unique identifier for cross-referencing with design docs and ADRs.
Regulatory Source
Specific clause from MAS TRM, IMDA MGF, MindForge, or general finance regulation.
Capability Layer
Which of the seven layers satisfies this requirement.
Technical Control
What the platform must do — technology-agnostic capability description.
Status
Draft → Designed → Implemented. Gap = identified, not yet addressed.
Layers:
L1 Intent & Identity
L2 Policy
L3 Knowledge
L4 Planning
L5 Execution
L6 Validation
L7 Traceability
| Req ID | Requirement / Control | Regulatory Source | Layer | Technical Control | Status |
|---|---|---|---|---|---|
| Identity & Governance | |||||
| REG-001 | Every decision must be explainable to a regulator without ambiguity | MAS TRM §6.1 IMDA MGF §3.2 |
L5 ExecutionL7 Traceability | Source-to-decision lineageEvery output sentence linked to a retrieved source via citation token. Logic trace stored per reasoning step. | Designed |
| REG-002 | Policy rules must be versioned, approved with digital signature, and immutable | MAS TRM §5.3 IMDA §4.1 |
L2 PolicyL7 Traceability | Policy version pinningActive policy set version-locked at request time. Policy archive stored alongside decision record. Version hash in audit trail. | Designed |
| REG-003 | Human-in-the-loop for high-risk decisions (Tier 3) with non-repudiable approval | MAS §9.2 IMDA MGF §2.2.2 |
L4 PlanningL5 Execution | Significant checkpoint enforcementWorkflow pause before irreversible or high-stakes actions. Human identity, timestamp, and presented evidence captured in L7. | Designed |
| REG-004 | Agent must have its own unique identity; delegation chain must be recorded | IMDA MGF §2.1.2 MAS TRM §4.2 |
L1 Intent & Identity | Per-agent identity tokensEvery agent has a unique scoped identity. Delegation chain from human → orchestrator → specialist recorded with timestamps. | Gap — ADR-011 |
| REG-005 | Human cannot grant agent permissions greater than their own authorisation | IMDA MGF §2.1.2 |
L1 Intent & IdentityL2 Policy | Delegation ceiling enforcementAgent tool scope cannot exceed the authorised scope of the delegating human. Enforced at L2 policy evaluation. | Draft |
| Risk Assessment & Materiality | |||||
| REG-006 | Risk materiality must be classified before processing begins; tier determines oversight level | MAS TRM §5.1 IMDA MGF §2.1.1 MindForge DBS RDU |
L1 Intent & Identity | Upfront materiality assessmentRisk tier assigned at L1 before any data access. Tier 1 (low) → standard flow. Tier 3 (high) → mandatory HITL, enhanced logging, senior notification. | Designed |
| REG-007 | Agent autonomy must be bounded; process-driven tasks must follow defined SOPs | IMDA MGF §2.1.2 MAS TRM §6.2 |
L2 PolicyL4 Planning | SOP constraint enforcementAgent decomposes goals within a policy-approved SOP template. Steps outside template require explicit escalation, not autonomous deviation. | Designed |
| REG-008 | Prohibited use cases screened before development resources are committed | IMDA MGF §2.1.1 Julius Baer RAIC |
L1 Intent & IdentityL2 Policy | Pre-approval screeningIntent classification at L1 flags requests matching prohibited categories before they enter the processing pipeline. | Draft |
| Data Sovereignty & Knowledge Integrity | |||||
| REG-009 | Data used for decisions must be current; stale data must trigger alert or block | MAS FEAT — Fairness IMDA LLM Kit §3.2 |
L3 Knowledge | Freshness validationEvery retrieved document timestamped and validated against defined thresholds. Stale data alerts surfaced; high-materiality decisions blocked on stale data. | Designed |
| REG-010 | Customer PII must not cross sovereignty boundaries into compute environments | MAS TRM §7.2 IMDA MGF §2.1.2 |
L2 PolicyL3 Knowledge | Data sovereignty topologyData gravity region holds all persistent data. Compute region receives only sanitised, permissioned context. Boundary enforced by architecture, not policy. | Implemented |
| REG-011 | Agent must not access more data than the minimum required for the specific task | IMDA MGF §2.1.2 MAS TRM §8.1 |
L2 PolicyL5 Execution | Data minimisation + least-privilege toolsData scope constrained at L2. Tool access provisioned per step, not per session. Access revoked on step completion. | Designed |
| Technical Controls & Resilience | |||||
| REG-012 | Model risk management including hallucination monitoring and fallback | MAS TRM §8 Fed SR 11-7 IMDA LLM Kit §3.2 |
L4 PlanningL6 Validation | Citation-linked hallucination detection + deterministic fallbackEvery claim cross-referenced against L3 citation tokens. Uncited claims rejected. Fallback to deterministic logic when LLM confidence insufficient. | Designed |
| REG-013 | Bias and fairness testing across demographic and entity dimensions before and after deployment | MAS FEAT — Fairness IMDA LLM Kit §3.3 |
L6 ValidationL7 Traceability | Parity + perturbation testingBias analysis across entity types. Systematic unexplained differences flagged. Bias metrics monitored continuously post-deployment via L7. | Draft |
| REG-014 | System must survive failure mid-execution without losing state or requiring restart | MAS TRM §9 IMDA MGF §2.3.3 |
L4 Planning | Durable state checkpointingWorkflow state persisted at every completed step. Failure resumes from last checkpoint. Checkpoint records are part of the audit trail. | Designed |
| REG-015 | Tool calls must be idempotent; retries must not duplicate financial or audit actions | IMDA MGF §2.3.1 MAS TRM §10.1 |
L5 Execution | Idempotency keys on all tool callsEvery external API call issued with idempotency key. Second call on retry is a no-op. Prevents duplicate financial actions, audit entries, or regulatory filings. | Designed |
| REG-016 | Emergency policy override requires dual-control and automatic expiry | MAS TRM §10.3 |
L2 PolicyL5 Execution | Break-glass dual-control with TTLEmergency overrides require two authorised approvers. Override expires automatically after defined TTL. Every override recorded in L7. | Draft |
| REG-017 | Separation of duties: agent cannot disable its own logging or modify its own constraints | MAS TRM §4.2 IMDA MGF §2.3 |
L1 Intent & IdentityL7 Traceability | Immutable audit pipeline + constraint isolationL7 logging pipeline is write-only from agent perspective. Agent cannot read, modify, or disable its own audit records or policy constraints. | Draft |
| Audit Trail & Long-Term Governance | |||||
| REG-018 | Audit logs retained for minimum 7 years, immutable, and queryable | MAS TRM §7.4 IMDA MGF §5.1 |
L7 Traceability | Cryptographic append-only audit storeAll decision records cryptographically hashed and chained. Tampering breaks the chain. Queryable by regulators. Retention policy enforced by lifecycle rules. | Designed |
| REG-019 | Model and prompt versions must be archived; historical decisions reproducible against version active at the time | MAS TRM §8.3 MindForge DBS ALAN |
L7 Traceability | Model + prompt version registryEvery inference call records model version, prompt template version, and policy version. Historical decisions reproducible against exact technical state. | Draft |
| REG-020 | Continuous post-deployment monitoring for drift, bias increase, and accuracy degradation | IMDA MGF §2.3.3 MindForge Prudential |
L7 Traceability | Drift detection + recertification triggersAccumulated output signals monitored for performance degradation. Threshold breach triggers governance review. Periodic recertification for high-risk use cases. | Designed |
Open Gaps
The following requirements are identified but not yet implemented. They represent the honest state of the platform at the time this chapter was published. Each has an assigned ADR or action to close it.
REG-004
GAP-001
GAP-001
Per-Agent Identity Management
No per-agent unique identity system exists in the current POC stack. When Agent A delegates to Agent B, there is no technical mechanism to distinguish their actions in the audit trail. This directly violates IMDA §2.1.2.
→ ADR-011 required before next build weekend
REG-016
GAP-002
GAP-002
Break-Glass Dual-Control
Emergency policy override mechanism is not yet designed. In a regulated environment, break-glass access without dual-control and automatic expiry creates an uncontrolled override vector.
→ Design session required; policy-as-data store dependency
REG-019
GAP-003
GAP-003
Prompt Version Registry
Prompt CI/CD hooks are deferred. L7 integration points for prompt version recording must be designed now even if the pipeline is not yet built, or retrofitting will break the audit chain.
→ L7 integration contract to be defined in Chapter 2 (The Stack)
How a Regulator Uses This Matrix
Examination workflow
- Start with the requirement. A regulator examining accountability will go to REG-001, REG-003, REG-018. Each row shows exactly which regulatory clause created the requirement and which layer implements it.
- Trace to the layer. The layer column links to Chapter 1 (the capability definition) and will link to Chapter 2 (the component that implements it). A regulator can move from obligation → design → implementation in one path.
- Examine the gaps honestly. A platform with no open gaps in its traceability matrix has either not been examined thoroughly or is presenting a filtered view. The open gaps here are the honest state of a platform being built in public.
- Request the audit artefact for a specific decision. Using the Req ID, a regulator can request the L7 audit record for any decision and verify that the control described was actually applied — by examining the citation tokens, policy version record, and human approval record in that artefact.