The Penitentiary Information Layer

A technical concept for a longitudinal, interoperable and role-based correctional information layer

Penitentiary classification is a longitudinal process that is still largely represented through documents.

That creates an interesting contradiction.

A person may remain within the correctional system for years. During that period, psychologists, educators, social workers, legal professionals and treatment bodies produce assessments, define objectives, record incidents, evaluate programmes and periodically reconsider classification.

The information exists.

The professionals exist.

The documents exist.

And yet the evolution itself may remain difficult to see.

A digital file containing hundreds of electronic documents is certainly a digital file.

It is not necessarily a digital representation of a process.

That distinction is the starting point for this concept.

The proposal is not to automate penitentiary classification, create a new risk algorithm or replace professional assessments.

It is considerably less ambitious technologically:

to create a longitudinal information layer capable of showing where the process was, what has happened since, where it is now and which professional information supports that change.

Almost none of the technology required to do this is new.

Most of it has been mature for years.

1. The documents are not the process

Correctional systems already generate substantial amounts of information.

There may be psychological reports, educational assessments, social reports, treatment programmes, interviews, institutional observations, disciplinary information, permissions, release planning and successive classification decisions.

Digitising those documents is useful.

But digitisation alone does not solve the longitudinal problem.

Imagine two classification reviews separated by six months.

At the first review, several treatment objectives remain outstanding.

During the following period one objective is completed, another remains unresolved, a programme ends but requires further observation, and the person’s external support structure improves.

At the next review, every relevant piece of information may already exist somewhere in the electronic record.

The important question is whether the information system can represent the transition without requiring a professional, lawyer or judicial authority to reconstruct it manually from dozens or hundreds of documents.

This is not primarily a document-storage problem.

It is an information architecture problem.

2. The underlying technology has existed for years

This is not a technology waiting to be invented.

Correctional systems in the United States already provide useful reference points.

California’s Department of Corrections and Rehabilitation uses its Strategic Offender Management System, or SOMS, in classification and rehabilitative processes. Its Rehabilitative Case Plan can be used by correctional counsellors when considering programmes and classification recommendations. SOMS also supports electronic workflows involving different institutional and external actors in release preparation.

Washington State has publicly described a correctional information environment centred historically around OMNI and is moving towards a new Correctional Information Management System, or CIMS, together with data infrastructure intended to reduce fragmentation and provide more unified access to information.

At federal level, the Bureau of Prisons has used SENTRY since the early 1980s to manage information including classification, programmes, discipline and other institutional data.

These systems are not identical to the architecture described here.

Nor is this intended as a comparative study of US correctional technology.

Their relevance is simpler:

they demonstrate that the principal technological building blocks have already operated in real correctional environments for years.

The relevant question is therefore not whether the technology exists.

It is how mature technologies could be assembled around a longitudinal, interoperable and role-based information model.

3. A layer, not another isolated platform

The first architectural decision should probably be not to create another technological island.

Public administrations may already possess identity systems, document repositories, professional applications, electronic signatures, judicial portals and procedural databases.

Replacing them would create cost and dependency without necessarily improving the underlying process.

A more economical approach would be to create a modular information layer capable of interacting with existing systems.

The longitudinal layer would not need to own every document.

A report could remain within an existing institutional repository.

Authentication could continue to be provided by an existing identity service.

A judicial portal could expose the module without being redesigned.

The objective is not to rebuild the information environment.

It is to make one dimension of that environment — evolution over time — visible.

4. Documents underneath, states above

The central unit of the interface need not be the document.

It could be the current state of a relevant area and its change since the previous review.

For example:

These labels would not replace professional assessments.

That distinction is fundamental.

A status such as “progressing” is not a psychological conclusion generated by software. It is an interface element representing a human professional assessment whose supporting material remains available underneath.

Simplifying the representation does not mean simplifying the professional judgement.

The interface provides orientation.

The professional report provides substance.

5. Comparison may be the most useful function

At each new classification review, the system could present the previous state beside the current one.

Not to make the decision.

Simply to make the difference visible.

Computationally, this is a modest task.

The machine is not evaluating a person.

It is comparing structured states previously created or validated by human professionals.

Yet that simple comparison may provide one of the most useful functions of the entire architecture.

6. One information model, multiple legitimate views

Not every participant should see the same information.

Nor do they need to.

Modern information systems have managed this problem for decades.

Authentication establishes who the user is.

Authorisation determines what that user may access or modify.

The interface then presents the appropriate information layer.

The depth changes.

The underlying process does not.

One information model. Multiple legitimate views.

Strong authentication, professional certificates, cryptographic identity, role-based permissions, attribute-based access control and audit logging are not emerging technologies.

They have existed for years.

7. The same architecture could remove operational friction

Once professional identity, authorisation and institutional access exist, the same infrastructure can support simpler operational functions.

Professional communications with correctional facilities are one example.

Where legally and operationally appropriate, an authenticated lawyer could identify the relevant person, establish professional entitlement when necessary and access communication slots made available by the institution.

The lawyer would not need access to the centre’s complete internal schedule.

The interface would expose only those appointments available for professional booking.

No new decision-making structure is required.

No artificial intelligence is required.

Technically, it is an authenticated scheduling workflow.

This illustrates a broader principle:

A useful information system should not merely describe an administrative process. It should remove unnecessary friction from it.

8. Designed for constrained environments

Low-cost architecture should not be understood only in terms of server expenditure.

The other end of the connection matters.

Public-sector workstations may appear relatively modern while operating under significant constraints: managed browsers, endpoint protection, VPN connections, certificates, multiple administrative applications, restricted configurations and sometimes congested or slow network connections.

The system should therefore be designed for the environment users actually have, not for the hardware developers would prefer them to have.

That means treating constrained operation as a design requirement rather than an exceptional case.

A professional should be able to see:

previous review → relevant changes → current state → supporting document

without first downloading the entire case file.

A public platform that requires thousands of workstation upgrades merely to display administrative information has transferred an architectural problem to the hardware budget.

A low-cost platform should be inexpensive at both ends of the connection.

9. The infrastructure can be deliberately unremarkable

Nothing in the proposed workload requires high-performance computing.

This is not telemetry.

It is not scientific simulation.

It does not require real-time artificial intelligence.

The core workload consists primarily of authenticated users reading and updating structured records, accessing documents and preserving an auditable history of changes.

A possible infrastructure could therefore use mature and widely available components.

For a proof of concept, the computational requirements would be modest enough to operate on conventional virtual infrastructure.

A more serious pilot could separate application, database, identity, documents, testing and backup while still remaining within an infrastructure envelope measured in hundreds rather than tens of thousands of euros per month.

This is deliberately an infrastructure observation, not a public-sector project budget.

Institutional integration, security accreditation, support, governance, migration, procurement and operational continuity are different cost categories.

The point is narrower:

computing capacity is not the economic barrier.

Nor is the core application technically exotic.

Its essential functions — authentication, structured records, permissions, documents, comparison, scheduling and audit — lie comfortably within conventional web and database engineering.

10. Public infrastructure should survive its contractors

A public-sector system has an additional architectural constraint.

Contractors change.

One company may develop a module.

Another may later maintain it.

Another contract may cover identity services.

A different supplier may operate document management or hosting.

A subsequent procurement procedure may replace one or several of them.

This should not be treated as an exceptional event.

It should be assumed from the beginning.

That requires more than access to source code.

The data model should be documented.

Interfaces should be explicit.

Dependencies should be declared.

Deployment should be reproducible.

Application, data, documents and identity should not be unnecessarily coupled.

Open and documented formats reduce the cost of transition.

The system should be designed on the assumption that a future maintenance team may have had no involvement whatsoever in its original development.

This is not merely software elegance.

It is a practical response to the reality of public procurement.

Public infrastructure should survive its contractors.

11. The next contractor should inherit the engineering memory

Documentation matters.

But resilient architecture should not assume perfect documentation.

Real software is developed under deadlines.

Incidents occur.

Corrections are implemented.

A service fails, the cause is identified, a patch restores normal operation and the team moves to the next problem.

Formal documentation may follow immediately.

Sometimes it does not.

The system should therefore preserve its own engineering history as far as reasonably possible.

Much of this history can be derived from ordinary engineering tools: version control, issue tracking, automated tests, continuous integration records, dependency definitions, release notes and incident logs.

The next contractor should not simply receive software that happens to work.

It should receive enough information to understand why it works as it does, what has already failed, what was corrected and which residual issues remain known.

A new contractor should inherit not only the code, but the engineering memory of the system.

Otherwise every contractual transition risks becoming an exercise in software archaeology.

12. Production-ready does not mean defect-free

Software changes continuously.

Operating systems are updated.

Libraries evolve.

Security vulnerabilities appear.

Browsers change.

Certificates expire.

External interfaces are modified.

Unexpected behaviour appears under real workloads.

A mature production system is therefore not necessarily a system without defects.

It is a system in which critical defects have been addressed, remaining issues are understood, updates can be introduced safely and ordinary incidents can normally be handled through maintenance rather than redevelopment.

The objective is not to eliminate change.

It is to reach the point where:

That distinction is especially important when maintenance contracts and technical teams change over time.

13. What the system deliberately does not do

The architecture becomes clearer when its limits are explicit.

The technology performs a much more modest function:

it organises, preserves, compares and presents the information on which human professional responsibility operates.

14. Perhaps the missing technology is organisation

Almost every technical component described here has existed for years.

Relational databases are mature.

Document management is mature.

Cryptographic authentication is mature.

Role-based permissions are mature.

Audit logging is mature.

Version control is mature.

Web applications are mature.

APIs are mature.

Scheduling systems are mature.

Linux server infrastructure is mature.

The proposal therefore does not depend on a future technological breakthrough.

Its difficult questions are elsewhere: the information model, institutional permissions, interoperability, professional workflow and continuity between organisations and contractors.

That leads to a slightly paradoxical conclusion.

A system intended to make a highly complex penitentiary process easier to understand may require very little technological innovation.

Its principal improvement may simply consist of arranging existing information in the same order in which the process actually occurs.

The correctional system evaluates evolution.

Its information systems should therefore be able to show it.

Spanish adapted version
A version of this technical concept adapted to the Spanish legal and penitentiary context is available at EBAN Abogados.
Read the Spanish adapted version →