Overview
This epic tracks the complete foundation roadmap for casehub-ledger's trust, accountability, and audit capabilities. All work here is domain-agnostic — every capability built serves any Quarkus application.
The motivating use case throughout is AI-assisted code review: agents reviewing PRs, delegating to specialists, building trust records from demonstrated performance. But implementations must contain no domain knowledge — that lives in casehub-assisteddev.
Standing practice (Platform Coherence Protocol Step 6): After shipping any new abstraction, immediately propagate it to existing consumers. Do not leave parallel implementations. One concept = one implementation.
Consolidation checks (read before starting any issue)
Six specific consolidation opportunities have been identified for this body of work. Each is attached as a comment on its issue. Read them before implementing:
| # |
Where |
What to check |
| 1 |
#67 (prerequisite) |
Extract LedgerTraceListener into pluggable enricher pipeline before #59 adds a second @PrePersist mechanism |
| 2 |
#68 (prerequisite) |
Refactor ActorTrustScore to score_type discriminator before #61/#62 add nullable columns |
| 3 |
#53 (comment) |
Check actorRole consistency across consumers at the same time as actorType — fix both in one pass |
| 4 |
#54 (comment) |
Grep consumers for existing ad-hoc trust score access before implementing TrustGateService — remove and replace |
| 5 |
#55 (comment) |
Extract DecayFunction as an SPI at the same time as adding the valence multiplier |
| 6 |
#58 (comment) |
Check LedgerProvExportService for shared export infrastructure before building LedgerComplianceReportService |
Prerequisite refactors (do first)
| Issue |
Prerequisite for |
Description |
| #67 |
#59 |
Unified LedgerEntry enrichment pipeline |
| #68 |
#61, #62 |
ActorTrustScore discriminator model |
Group A — Independent foundational improvements
Epic: #49
| Issue |
Size |
Description |
| #53 |
S |
ActorTypeResolver consumer updates — see comment for actorRole check |
| #54 |
S |
TrustGateService — see comment for consumer grep |
| #55 |
S |
Trust decay acceleration on FLAGGED — see comment for DecayFunction extraction |
| #56 |
S |
Ledger health checks — reconciliation + sequence gap detection |
| #57 |
S |
Multi-attestation aggregation — consensus verdict before TrustScoreJob |
| #58 |
M |
Compliance report query API — see comment for shared export infra check |
| #59 |
M |
@ProvenanceCapture enricher — requires #67 first |
Group B — Trust model extension
Epic: #50
| Issue |
Size |
Depends on |
Description |
| #60 |
S |
— |
B1: capabilityTag on LedgerAttestation |
| #61 |
M |
#68, #60 |
B2: Capability-scoped ActorTrustScore + TrustScoreJob — requires #68 first |
| #62 |
L |
#68 |
B3: Multi-dimensional trust — requires #68 first |
Group C — Trust federation
Epic: #51
| Issue |
Size |
Depends on |
Description |
| #63 |
M |
#61, #62 ideally |
C1: TrustExportService + canonical format |
| #64 |
S |
#63 |
C2: TrustImportService SPI + no-op default |
Group D — Trust bootstrapping
Epic: #52
| Issue |
Size |
Depends on |
Description |
| #65 |
M |
#64 |
D1: Seed Beta(α,β) from prior deployment |
Dependency graph
#67 (prereq) ──────────────────────────────────────────────→ #59
#68 (prereq) ────────────────────────────────────→ #61, #62
#53 #54 #55 #56 #57 #58 ← Group A (all independent)
#59 ←── #67
#60 → #61 ←── #68 ← Group B
#62 ←── #68
#61 + #62 → #63 → #64 ← Group C
↓
#65 ← Group D
#54 (TrustGateService) gains Phase 2 (capability queries) as soon as #68 ships.
Related
Overview
This epic tracks the complete foundation roadmap for casehub-ledger's trust, accountability, and audit capabilities. All work here is domain-agnostic — every capability built serves any Quarkus application.
The motivating use case throughout is AI-assisted code review: agents reviewing PRs, delegating to specialists, building trust records from demonstrated performance. But implementations must contain no domain knowledge — that lives in casehub-assisteddev.
Standing practice (Platform Coherence Protocol Step 6): After shipping any new abstraction, immediately propagate it to existing consumers. Do not leave parallel implementations. One concept = one implementation.
Consolidation checks (read before starting any issue)
Six specific consolidation opportunities have been identified for this body of work. Each is attached as a comment on its issue. Read them before implementing:
Prerequisite refactors (do first)
Group A — Independent foundational improvements
Epic: #49
@ProvenanceCaptureenricher — requires #67 firstGroup B — Trust model extension
Epic: #50
capabilityTagonLedgerAttestationActorTrustScore+ TrustScoreJob — requires #68 firstGroup C — Trust federation
Epic: #51
Group D — Trust bootstrapping
Epic: #52
Dependency graph
#54 (TrustGateService)gains Phase 2 (capability queries) as soon as #68 ships.Related