标签：#legaltech

Building any intake pipeline, you'll hit the same problem eventually. Files arrive from multiple sources. Some you've already processed: re-uploads of the same document, copies from two different intake paths, items your worker errored on last run and re-queued. Call the anchoring API blindly and you end up with multiple proof records for identical bytes. The ProofLedger v1 API returns a duplicate_of field in its 201 response when it detects a hash it's already seen. But that's only half the solution. A network round-trip costs time and quota even when it comes back as a duplicate. Hash-based local deduplication is the other half. Here's how to build a worker that handles both layers. Hash Locally First The core pattern: compute the SHA-256 digest before making any API call. If you've seen this digest before, skip it. If you haven't, submit it. Two things you need: a persistent record of digests you've already anchored, and chunked hashing so large files don't blow memory. import hashlib import json from pathlib import Path SEEN_DB = Path ( " anchored_hashes.json " ) def load_seen (): if SEEN_DB . exists (): with open ( SEEN_DB ) as f : return json . load ( f ) return {} def save_seen ( db ): with open ( SEEN_DB , " w " ) as f : json . dump ( db , f , indent = 2 ) def hash_file ( path : str ) -> str : h = hashlib . sha256 () with open ( path , " rb " ) as f : for chunk in iter ( lambda : f . read ( 65536 ), b "" ): h . update ( chunk ) return h . hexdigest () 65536-byte chunks keep memory flat regardless of file size. The load_seen / save_seen pair gives you a persistent record that survives worker restarts. Submitting and Reading duplicate_of When duplicate_of appears in the API response, its value is the proof ID of the earliest anchor for that hash. That's the canonical ID. The new proof ID from this call is irrelevant. import requests API_URL = " https://proofledger.io/api/v1/proof " API_KEY = " sk_YOUR_KEY_HERE " def anchor_file ( file_path : str , seen : dict

Most tutorials on AI agents assume the agent should get more autonomous over time — more tools, more scope, less human intervention. That's the wrong architecture for regulated professional-services work, and if you're building for accounting or legal clients, it's worth understanding why before you write a line of code. The constraint that shapes everything In accounting and legal workflows, there's a hard line between preparing work and exercising professional judgment. A first-pass extraction of numbers from a bank statement is preparation. Deciding how to characterize a transaction for tax purposes is judgment. An agent that drafts a client letter from a template is preparation. An agent that decides what legal advice goes in that letter is not — and building one that does is a liability, not a product. This isn't a hypothetical concern. The 2026 legal industry data shows the gap plainly: 69% of individual lawyers now use generative AI at work, according to the 8am 2026 Legal Industry Report, but firm-wide adoption of legal-specific AI sits at only 34%, and 54% of firms report no training or governance plan for responsible AI use at all. The technology is ahead of the guardrails, and that's exactly the gap this architecture is meant to close. So the architecture I use treats "human approval" as a first-class step in the pipeline, not an afterthought bolted on for compliance theater. Concretely, that looks like four layers. 1. Ingestion layer Documents come in from wherever the firm already receives them — email, upload, integration with QuickBooks, Xero, Clio, iManage — get classified, and get normalized into structured data. 2. Extraction / drafting layer The agent does the actual work: pulling line items, matching transactions, assembling a first-draft letter, flagging clauses in a contract that need a human eye. 3. Approval gate Nothing produced in step 2 moves forward without an explicit human action. This isn't a suggestion in a UI that can be ignored; it's