Concoro

A candidate finds a public-sector job announcement that looks promising. The title is vague, the requirements begin on page twelve and the deadline sits between a legal reference and an administrative approval.

Public-sector opportunities in Italy are technically public. But they are scattered across institutional portals, described with inconsistent terminology and frequently published inside long administrative documents.

Most existing services behaved like databases. They offered lists, categories and filters, but left candidates to translate their education and experience into the language used by public institutions.

The real question was not how to improve search. It was how to help candidates understand relevance, eligibility and what to do next.

The first concept collected active competitions and presented them through a cleaner search interface. It was useful, but it treated each announcement as a page to display rather than a document that first needed to be understood.

Traditional job boards assume a clear title, location, employer and list of requirements. Public notices rarely arrive that politely.

Concoro therefore evolved into a decision-support product built around three stages: structure the opportunity, connect it to the candidate and explain the relevance. Search, onboarding, matching and alerts all needed the same shared understanding of both sides.

• Structure the opportunity
• Connect it to the candidate
• Explain the relevance

The same profession could be described differently by two institutions. Similar qualifications appeared under different headings, while a job title might describe a contractual classification rather than the work itself.

I developed a normalised model covering professional sector, job family, employment type, location, deadlines, eligibility, qualifications, technical knowledge, capabilities, examination programme, legal references and status.

This shared schema allowed Concoro to present opportunities consistently even when the original notices were inconsistent. Without it, better filters would have produced a more polished version of the same confusion.

Many public portals reproduce the organisation of the institution publishing the information. Concoro was designed around the person trying to use it.

Opportunity cards surface what a candidate needs for an initial decision. Administrative and legal detail remains available on the full page through progressive disclosure.

The goal was not to pretend public competitions were simple. A candidate browsing twenty opportunities does not need every legal reference in each card. A candidate preparing an application does.

• What is the role?
• Where is it located?
• When is the deadline?
• Which qualifications are required?
• Does it fit my background?
• What happens next?

Filtering still required users to understand how their background mapped to official public-sector terminology. Someone may know they studied economics and prefer administrative work without knowing the relevant professional family or contractual category.

I designed a five-step onboarding flow covering education, professional background, preferred sectors, geography, eligibility conditions and areas of strength.

The interface asked candidates questions they could reasonably answer about themselves. Behind it, their answers became structured and semantic data for recommendations, prioritised search, alerts, eligibility guidance and future application support.

• Education and qualifications
• Professional background
• Sectors and job families
• Geographic preferences
• Eligibility and skills

The first matching approach compared one embedding for the candidate with another for the complete notice. Long notices mix legal references, procedures, responsibilities, qualifications and examination details; treating them as equally meaningful made the results hard to control.

I divided every opportunity into three semantic dimensions: role core, requirements and domain context. Each was embedded separately and stored in Pinecone.

Recommendations combined these semantic results with structured constraints, excluded expired opportunities, grouped results by competition and returned a limited prioritised set. The model became more controllable because the product gave it a narrower, better-structured job.

A candidate may be interested in a role without being eligible for it. Showing a promising opportunity and revealing the disqualifying requirement only after a long read is not engagement. It is wasted attention.

Deadlines, qualifications, mandatory conditions and employment categories therefore act as product constraints rather than passive text on a detail page.

Recommendations also explain why they appear—professional background, education, geography, skills or domain preference—instead of presenting an opaque percentage as authority.

The purpose was not to convince the user that the algorithm was right. It was to give them enough context to decide whether the result was useful.

Candidates were already trying to understand a complicated employment process. They did not also need to learn how to interview a chatbot correctly.

AI worked mostly behind the visible experience: interpreting documents, extracting information, classifying roles, normalising terminology, preparing semantic representations, retrieving opportunities and supporting explanations.

The interface remained built around familiar actions—browse, filter, save, compare and receive alerts. The intelligence reduced translation work without demanding attention for itself.

• Interpret
• Extract
• Classify
• Normalise
• Retrieve
• Explain

The structured record made each notice easier to understand, but the official source remained authoritative. Candidates could see where information came from and return to the original document when preparing an application.

Status and deadlines were treated as system-level constraints. Expired competitions closed automatically and disappeared from active discovery, semantic retrieval, recommendations and alerts.

Freshness was not a label added after retrieval. In this context, current data, visible sources and explicit uncertainty were part of the user experience.

Coverage increased the platform’s usefulness but also introduced inconsistent documents, unusual classifications and incomplete records. The architecture needed validation states, reprocessing and ways to identify records requiring attention.

More complex personalisation could improve relevance while making recommendations harder to understand. I favoured a modular matching structure over a single opaque score.

Readable summaries had to coexist with legal completeness, while large-scale automation had to preserve human control. The interface simplified navigation, not the underlying legal reality.

• Coverage vs data quality
• Personalisation vs transparency
• Simplicity vs legal completeness
• Automation vs control

Concoro evolved into an end-to-end information product capable of processing notices, converting them into a shared schema, maintaining current states, supporting structured and semantic search, building candidate profiles and producing explainable recommendations.

The most important result was the common information architecture connecting source documents, structured opportunities, candidate profiles and recommendations. That layer allowed the product to move beyond displaying information and begin helping candidates make decisions.

There were no mature behavioural analytics or long-term outcome data at this stage. The next phase needs to test whether the system improves discovery, eligibility understanding and application decisions—not simply whether it produces sophisticated recommendations.

A search interface cannot compensate for inconsistent, incomplete or poorly classified information. Much of Concoro’s experience was determined before a result appeared on screen.

The largest AI improvements came from clearer schemas, meaningful document sections and deterministic constraints—not a newer model or a longer prompt.

Designing an intelligent product means designing the system that produces the experience, not only the interface through which people access it.

Making information public is not the same as making it usable.