Pulan
Your documents hold obligations you cannot see, spread across systems nobody can search as one.
It is not another place to put documents. It works on the stores you have and answers for them.
How it works
Pulan generates documents from templates your users configure, routes them through approval rules your users manage, and governs what is inside them.
- Generate
A template library your own users configure, filled from governed data on every run.
- Route
Multi-step approval with deterministic rules, and the departments, roles and users managed in the same place.
- Govern
Intake, search, redaction, question answering, and a graph linking documents to the entities inside them.
Where your documents are
A SharePoint site, a shared drive, a mailbox, a line of business system.
Pulan
Reads them where they are, and records what it read.
What comes back
An answer, the documents it came from, and who asked for it.
What it does today
- Nineteen independently deployable services, each upgraded on its own.
- One database per tenant, routed per request rather than filtered by a column.
- Redaction that removes text from the PDF content stream and then diffs its own output for a fidelity verdict.
- Plain-language question answering grounded in the documents you uploaded.
- Deterministic routing: a rule engine decides who approves, not a model.
Roadmap
- Design partners now, with direct access to the people building it.
What we do not claim
- No text inside scanned images. Redaction and extraction cover text-layer PDF and DOCX.
- No records management: no retention schedules, no legal hold, no certified destruction.
- No per-document access lists. Access is granted per document class.
- No approval deadlines, delegation or escalation.
- No compliance outcome is guaranteed. The product carries evidence, a regulator draws conclusions.
- Nobody outside the design-partner phase is running it, and we are not borrowing anyone else's logos.
A good fit
- Legal and insurance teams whose work lives in documents.
- Teams under DPDP, HIPAA or GDPR where a redaction has to be provable rather than decorative.
- Organisations willing to be a design partner and shape the order the roadmap gets built in.
Not a fit yet
- Anyone who needs scanned paper read today.
- Anyone who needs a records-management system with legal hold.
- A buyer who needs referenceable customer names before signing.
Pulan does three things to a document, and they are the three things a document team already does by hand.
Generate
A template library your own users configure. No developer is involved in adding a template or changing one. Each run fills the template from data the system already governs, so the document and the record behind it agree.
Route
Approval that moves in steps you define, with the departments, roles and users managed in the same place. A rule engine decides who approves what. It is deterministic, so the same document takes the same path every time, and a model is never asked to make that decision.
Govern
Intake, search, redaction and a graph. Nine document formats go in. Text comes out of the ones that carry a text layer. Questions get answered from the documents you uploaded rather than from a model’s memory. Redaction removes the text from the PDF content stream and then diffs its own output, so what you get back is a verdict about the redaction rather than a black rectangle drawn over words that are still in the file.
The graph is the part that is hard to do by hand. It links documents to the entities inside them, so a policy, its endorsements, its claims and the person named on all three sit in one place, and the answer to why two records were matched is a path you can read.
Why a documents product ends up being a compliance product
DPDP, HIPAA and GDPR read like security regulations. In practice they behave like documentation regimes. HIPAA asks for a written risk analysis and a written policy. GDPR Article 30 asks for a record of processing activities. India’s DPDP Act asks a data fiduciary to erase personal data when consent is withdrawn, and to be able to show that it happened.
Each of those obligations is a document, a date, and evidence that the thing was done. That is what the graph and the record are for. It does not make the obligation go away, and it does not decide whether you have met it.
Where Pulan is
Early, deliberately. A small engineering team is building it on real documents, with design partners who get direct access to the people writing the code.
The list of what it does not do is the same list its own engineers keep. It is published because a buyer finds those gaps in week two anyway, and finding them in writing is cheaper for everyone than finding them in a pilot.
We check the problem before anyone talks about a build.