Client-level and matter-level permissions
Access follows role and matter need. Permissions are granted at the client level and narrowed at the matter level, so a person working on one portfolio segment does not thereby gain visibility of another. Client-specific segregation requirements can be recorded during onboarding and applied as a standing rule.
Audit history
Actions against a matter — who did what, when, and on whose authority — are written to the record. The audit history is part of the docket rather than a separate log, which is what makes it usable when a question is asked months later.
Source-linked agent actions
Every operational action Jidoka takes is linked to the record entry that justifies it: the communication that created the event, the rule that produced the date, the playbook clause that set the recipient. An agent output that cannot be traced to a source is not treated as a fact about the matter.
Professional approval controls
Substantive and procedural work is approved by the responsible IP professional before it is filed or sent. Jidoka prepares and routes; she does not self-authorise a filing, a response or a communication that requires professional judgement.
Encrypted storage and provenance
Matter data is held in controlled working environments with encryption at rest and in transit, and each record entry carries its provenance — where it came from and what produced it. Detailed infrastructure disclosures are provided under engagement rather than published here.
Model and provider abstraction
The operating layer is deliberately not coupled to a single model or provider. Which system processes what, for which purpose and under which controls, is a configuration of the engagement — not a permanent architectural dependency.
What we do not claim
No certification, audit standard or compliance framework is claimed on this page. Where a specific standard is required for an engagement, it will be addressed contractually and evidenced before it is asserted.