An administrative procedure isn't a chain of emails. In practice, though, it often is.
Pwas describes the procedure as the regulation writes it — phases, owners, deadlines, acts — and has the system enforce it, leaving behind the audit trail the law requires without anyone having to assemble it by hand.
The procedure is defined by law. The software rarely knows it.
In public bodies the rules already exist and are written down: who owns the procedure, within how many days it must conclude, which acts are needed, who signs what, when tacit consent applies. The problem is that this knowledge lives in regulations and in officials' heads, while the systems handle only the pieces: the registry records documents, administrative acts have their own application, the rest of the procedure is held together with emails, shared sheets and people's memory. When an official retires or moves department, part of the procedure leaves with them.
illustrative scenario
An authorisation application in a mid-sized public body.
A citizen submits an application by certified email. The registry records it and assigns a number. From that moment the procedure exists in law, but it exists in no system as an object with its own state. The case officer opens it as a network folder, requests opinions from three offices by email, receives two replies as PDFs and one verbally, consolidates them, prepares a draft act, sends it to the director, waits for signature.
Meanwhile nobody can reliably answer the simplest question: how many open cases are past day sixty? To find out, someone has to open the registry, extract a list and cross-reference it by hand with folders and emails. It gets done once a month, and by then it's too late to intervene.
What changes with Pwas
The work starts from the regulation, not the software. The procedure is written as it is codified: an application has a subject, an applicant, a registration date and a calculated deadline; it involves an admissibility check, an opinion-gathering phase, an assessment phase and adoption; opinion-gathering involves particular offices depending on the application type; a request for additional documents suspends the deadline; the procedure owner is determined by rules, not chosen by hand.
That description becomes the system. From it come the case officer's screens, the director's dashboards, the permissions (each office sees the cases it must opine on), and something public bodies almost always lack: procedure state as data, with the deadline calculated and suspended automatically according to the declared rules.
The same application, afterwards
The application arrives by certified email and is registered as always — the registry remains the system of record, as it should. But from that registration the procedure is created automatically, with a calculated deadline, an owner assigned by rule, and opinion requests sent to the competent offices with their own due dates. Each office sees in its own queue what it must do and by when. The director opens a dashboard and sees how many cases are due within fifteen, thirty and sixty days, by office and by type — not at month end, now.
When the moment for the act arrives, the draft is generated from data already in the procedure and enters the signature circuit; the signed act returns to the procedure, is registered and, where required, published. The citizen, if the body chooses, checks the state of their own application in a restricted area reading the same data.
When the regulation changes
A regulatory amendment introduces a new mandatory opinion for one category of applications and reduces the deadline from ninety to sixty days. Conventionally this is a change request to the application supplier, with timings and costs that often exceed the window in which it can be applied.
Here you add the opinion to the procedure description, declare which application types it's mandatory for, and update the deadline. New cases immediately follow the new rule, cases in progress keep the rule in force when they opened — because this too, an extremely delicate matter in public bodies, is declared rather than left to the interpretation of whoever uses the system.
the comparison
What happens today, what happens afterwards.
The recurring situations in an office handling procedures with multiple actors.
Today
The procedure lives outside the systems
The registry records documents, but no system knows the state of the procedure.
Deadlines are checked by hand, and at-risk cases surface when it's too late.
Opinions are requested by email and chased by phone.
The case file is a network folder whose completeness depends on who maintains it.
A regulatory change requires a change request to the supplier.
Citizens phone the office to find out where their case stands.
With Pwas
The procedure is an object with rules of its own
The procedure is created from registration and has state, owner and calculated deadline.
At-risk deadlines are visible on a dashboard, in real time, by office.
Opinion requests are steps in the flow, with due dates and automatic chasing.
The case file is complete by construction: every act is linked to the procedure that produced it.
A regulatory change is a configuration update, applicable within the statutory window.
Citizens check their own application in a restricted area, where the body provides one.
how you get there
The path, concretely.
Compatible with the registry, document system and archiving already in use.
01
We start from the regulation and from those who apply it
We read the rule and then listen to the case officer, who alone knows how the cases the rule doesn't foresee are actually handled. Both sources matter: the regulation says what should happen, the officer says what does.
02
We describe one procedure, not all of them
We pick a representative procedure and formalise it: phases, actors, acts, deadlines, suspensions, tacit consent cases. The description is readable by officials, who validate it before anything gets built.
03
We connect registry and document system
The registry remains the system of record, archiving stays as prescribed. Pwas attaches to what exists through the available interfaces, avoiding duplicate registration and new obligations for operators.
04
One office in real operation
The procedure goes into use in one office, alongside the current method for as long as needed. This is where the exceptions no regulation describes emerge, and they get formalised as they appear.
05
Rollout and transfer of capability
We extend to other procedures — repetitions of a validated pattern — and train internal staff on maintaining the configuration, so that regulatory changes don't depend on a procurement cycle.
an example flow
A procedure that remembers its own deadlines.
The application is registered and assigned, the term runs in the system, acts are recorded and publication is part of the procedure.
what changes structurally
Properties of the system, not promised outcomes.
Characteristics verifiable in a demonstration, not performance figures from other bodies.
100%
of actions traced and reconstructable
Who did what, when and on which act: the trace isn't a register to fill in, it's a consequence of how the system works.
1
source for procedure state
Case officers, opinion-giving offices, management and the citizen's restricted area read the same data, not different extracts.
automatic
deadline and suspension calculation
The deadline, suspensions for additional documents and due-date warnings all derive from declared rules, not from periodic manual checking.
on-premise
installation in your own infrastructure
The system can run entirely inside the body's perimeter or on qualified cloud, as a deployment mode and not a reduced version.
These figures describe how the platform works, not results measured at specific bodies. Every public sector project requires a specific assessment of the regulatory and technical requirements applicable to the organisation.
in depth
The questions directors and digital transformation leads ask us.
"Do we have to replace the registry, the acts application and archiving?"
No, and proposing it would be a poor idea. Registry and archiving carry regulatory obligations of their own, are often already under contract and subject to compliance checks: putting them in question turns a feasible project into one that never starts.
Pwas sits where there is currently nothing: in governing the procedure as a single object. The registry keeps registering, the document system keeps archiving, the acts application keeps producing acts. What changes is that there is finally one place where the application, the opinions, the assessment, the act and the deadlines are the same thing, linked and queryable.
The connection happens through the interfaces those systems expose. Where a system exposes none, we work with structured file exchange — less elegant, equally workable, and in any case preferable to asking operators to register things twice.
"How do we stand up to audit, access control and transparency requirements?"
Three mechanisms, all structural rather than bolted on afterwards.
Traceability isn't a module. Every operation that changes data retains author, moment and context. There's no alternative path allowing data to change without leaving a trace, because the trace is part of the write mechanism, not a feature someone can switch off.
Visibility is declared at data level. Who can see which procedures, and which fields within them, is a rule of the model: it holds in screens, dashboards, the restricted area and automated flows, because the system enforces it in one place.
Publications derive from the data. When an act must be published with certain fields and certain redactions, what gets exposed is a declared rule, not a manual transcription that can go wrong.
This doesn't replace the compliance assessments the body must still carry out, nor the impact assessment where the processing requires one. It does make them far easier to prepare, because the system's behaviour is written in a readable document instead of scattered through code.
"Our constraint is staffing: few people, without advanced IT skills."
It's the most real constraint of all, and it has to be addressed on two separate levels.
For those who use the system — case officers, front office staff — the rule is that the system must ask less than the current manual method, not more. If opening a procedure takes more steps than creating a network folder, the project is already lost. In practice that means the procedure is created from registration with no re-entry, that assignments follow automatic rules rather than manual choices, and that screens show the fields of that procedure and nothing else.
For those who maintain the system, the configuration is a readable structured document: adding a field or changing a deadline is within reach of a trained official, typically whoever already handles digital transformation, without programming skills. Deeper work needs a technical profile, which can be internal, a partner's or ours. The difference from a traditional application is that the body has a choice, instead of structurally depending on the supplier for every regulatory change.
"Does AI make sense in a public body? Isn't it a risk?"
It's a risk if AI is put in charge of deciding. It isn't if it's put to the three things it's objectively good at, where human control remains complete.
Reading inbound documents: an application arriving by certified email as a scanned PDF is read and its data proposed pre-filled, for the case officer to verify. It saves retyping, not judgement. Searching the document estate: finding precedents on a given matter across years of acts, with a natural-language question instead of a keyword search. Preparing drafts: a draft act or communication compiled from procedure data, which stays a draft until a person adopts it.
The non-negotiable point is how the agent reaches the system. It cannot perform actions that aren't declared as possible for the user who asked: it builds a plan, the plan is verified against real permissions, sensitive actions require explicit confirmation and every step stays reconstructable. An agent doesn't adopt an act, doesn't close a procedure and doesn't publish anything: it prepares material for whoever has the authority to do so. In a public body this distinction isn't a technical precaution, it's the condition on which the whole thing is admissible.
quick check
Is this your organisation?
Probably yes
You have procedures involving several offices that today coordinate by email.
You can't tell in real time how many cases are close to their deadline.
Regulatory changes catch you unprepared because they depend on a supplier request.
The procedure file is effectively a network folder.
You want to open a citizen area but don't know what data would feed it.
You have data residency constraints or need installation within your own perimeter.
Probably not
You only need a document registry or an archiving system.
Your procedures are already well covered by a vertical application that works.
Nobody in the organisation can spend time formalising the procedures.
You're looking for an institutional website or a portal restyle.
frequently asked
Public sector: the specific questions.
Does it integrate with the document registry we use?
Yes, where the registry system exposes interoperability interfaces, which today is common in the main applications used by public bodies. The registry remains the official record: Pwas reads the registration and creates the procedure from it, returning produced documents to the registry. Where interfaces don't exist, we work with structured file exchange agreed with the registry supplier.
Can it be installed in our own infrastructure?
Yes. Installation within the body's perimeter is a supported deployment mode, running the same system as on cloud. It's the most frequent choice where constraints exist on the residency or nature of the data processed, and it stays reversible: a hybrid setup, with the citizen-facing part on cloud and the core on site, is equally workable.
How is it procured? Are you compatible with tender procedures?
Procurement routes depend on the body and the contract value, and the choice of instrument — direct award, negotiated procedure, use of central purchasing frameworks — rests with the contracting authority supported by its own procurement office. We can provide the technical documentation needed to prepare the procurement file and take part in preliminary market consultations where the body runs them. We don't provide legal advice on procurement procedures: that remains the body's.
How do you handle personal data and special categories?
The principle applied is minimisation at model level: which data exists, who sees it and how long it's retained is declared explicitly rather than being an implicit consequence of the code. This makes it easier to prepare the record of processing activities and any impact assessment, which remain the body's obligations as controller. On our side we act as processor under the appropriate agreements.
How long to the first procedure in operation?
For a single, well-defined procedure the order of magnitude is a few weeks from the agreed formalisation, plus the time needed for the registry and document system connections, which depends on interface availability and on the relevant suppliers. Later procedures take less, because they repeat a validated pattern.
What happens if the supplier changes when the contract ends?
The configuration describing the procedures belongs to the body, in readable structured text files, versionable like any other document. Data sits on a standard relational database queryable with common tools. A successor with ordinary skills can take the system over without depending on proprietary formats or exclusive tooling.
We use technical cookies and, with your consent, analytics cookies (Google Analytics) to understand how the site is used. Read our Privacy & Cookie Policy.