Egidigbi25/ReguGuard · Regulatory Compliance / Document Lifecycle · February 21, 2026
ReguGuard is a regulatory document summarization and impact analysis system. It implements a document lifecycle (submit → summarize → review → approve/reject/dispute) with role-based access control for AI agents and human auditors. It also includes on-chain complexity analysis and predictive regulatory impact scoring.
This is a non-financial contract — no tokens are transferred, no value is at stake. The risks are centered on data integrity and governance centralization.
Submitted (u0) → Summarized (u1) → Reviewed (u2*) → Approved (u3)
→ Rejected (u4) → back to Summarized
→ Disputed (u5) → Approved or Rejected
* status-reviewed (u2) is defined but never usedAll admin functions
The contract-owner is set to tx-sender at deployment and is immutable. No ownership transfer, no multisig, no timelock. If the deployer key is compromised, an attacker controls the entire system: whitelisting/removing agents and auditors, resolving all disputes unilaterally.
Impact: Complete system takeover via single key compromise.
Fix: Add a two-step ownership transfer function. Consider multisig or DAO-based admin for dispute resolution.
dispute-prediction
The function does not check the current document status before setting it to status-disputed. An auditor can dispute a document that is status-submitted (before any summary exists), status-rejected, or already status-disputed.
;; No status check — disputes allowed at any stage
(define-public (dispute-prediction (doc-id uint) (reason-hash (buff 32)))
(begin
(asserts! (is-authorized-auditor tx-sender) err-unauthorized-auditor)
(asserts! (is-some (map-get? documents doc-id)) err-not-found)
;; Missing: (asserts! (or (is-eq status status-summarized)
;; (is-eq status status-approved)) ...)
(map-set disputes doc-id { ... })
(update-doc-status doc-id status-disputed)
(ok true)))Impact: Document status can be forced to "disputed" at any stage, blocking normal workflow or overwriting valid approvals.
Fix: Restrict disputes to documents with status-summarized or status-approved status.
review-summary
The function checks that a summary map entry exists but doesn't verify the document is in status-summarized state. If a document was rejected and re-submitted, the old summary entry persists — an auditor can approve based on the outdated summary.
;; Only checks existence, not current status
(asserts! (is-some (map-get? summaries doc-id)) err-not-found)
;; Missing: (asserts! (is-eq (get-doc-status doc-id) status-summarized) ...)Impact: Auditors can approve documents based on outdated/stale summaries after re-submission.
Fix: Add (asserts! (is-eq (get-doc-status doc-id) status-summarized) err-invalid-status-transition).
summaries map
The map is keyed only by doc-id. Multiple agent submissions silently overwrite each other. The version field is agent-supplied and not validated — can be set to any value or go backwards.
Impact: No audit trail of previous summaries. A malicious agent could overwrite a good summary just before review.
Fix: Key by {doc-id, version} with auto-incrementing version, or {doc-id, agent}.
reviews map
Keyed only by doc-id. A second auditor's review overwrites the first with no history. No consensus mechanism among auditors.
Impact: A single compromised auditor can approve anything.
Fix: Key by {doc-id, auditor} and require N-of-M approvals for critical documents.
disputes map
Keyed by doc-id only. A new dispute silently overwrites any existing (even unresolved) dispute, destroying evidence.
Impact: Dispute evidence can be silently replaced by another auditor.
Fix: Use a dispute counter and key by {doc-id, dispute-id}.
analyze-complexity
Can be called on any document regardless of lifecycle status — even before a summary exists or after approval. Results are overwritable and not tied to a specific summary version.
Impact: Complexity scores may not correspond to the actual summary that was reviewed.
Fix: Restrict to status-summarized documents. Tie score to summary version.
predict-regulatory-impact
Same as M-4. Predictions can be submitted at any lifecycle stage and overwritten at any time, including after final approval.
Impact: Post-facto modification of the on-chain record.
Fix: Restrict to appropriate lifecycle stages. Make predictions append-only.
tx-sender Throughout — No contract-caller?All access control uses tx-sender. Acceptable for direct calls but limits composability in inter-contract scenarios.
No print statements for any state changes. Makes off-chain indexing and monitoring difficult. The contract claims to provide an audit trail, but off-chain systems have no event stream to consume.
INFO Unused status-reviewed constant: status-reviewed (u2) is defined but never used. The lifecycle jumps from status-summarized directly to status-approved or status-rejected.
INFO get-doc-status returns u0 for non-existent documents: Indistinguishable from a real submitted document. Should return optional or check existence.
INFO Integer division precision loss in complexity scoring: (/ (* base-score u100) (+ readability-index u1)) — for small inputs, scores cluster at 0 due to integer truncation.
| Aspect | Rating | Notes |
|---|---|---|
| Access Control | ⚠️ Moderate | Role-based but overly centralized, no transfer mechanism |
| State Machine | ⚠️ Weak | Status transitions not enforced in most functions |
| Data Integrity | ⚠️ Weak | Last-write-wins across summaries, reviews, disputes |
| Financial Risk | ✅ None | No token transfers or value at stake |
| Code Quality | ✅ Good | Well-structured, clear naming, thorough comments |
| Composability | ⚠️ Limited | tx-sender only, no trait implementations |
ReguGuard implements an interesting concept — on-chain regulatory document management with AI-human collaboration. The code is well-organized and readable. However, the core issue is incomplete lifecycle enforcement: most functions don't check document status before executing, allowing out-of-order operations. The single-entry-per-document pattern for summaries, reviews, and disputes means data can be silently overwritten — undermining the "immutable audit trail" goal the project claims to provide.
No critical financial vulnerabilities exist since the contract handles no tokens or value transfers. The main risks are data integrity (overwritable records) and governance centralization (single admin key).
The concept is sound, but the implementation needs significant hardening of state machine transitions and data storage patterns before it could serve its stated purpose of providing tamper-proof regulatory compliance records.