Documents
The pages the team already trusts. We do not ask them to copy the library into a second wiki.
Lanequery is a software company. The software reads the policies, runbooks, and specs a team already keeps, and returns the passage that decides the question, with the page it came from.
People already wrote the answer. It sits in a policy, a runbook, or a spec, and they still open three tools to find it. Lanequery brings the passage back and leaves the files where they are.
The pages the team already trusts. We do not ask them to copy the library into a second wiki.
The paragraph that decides the question, not a summary that could have come from anywhere.
Every passage keeps the page it came from, so the person who asked can open the source.
Four steps. Each one has an output the team can look at. Nothing is added to the library that the library did not already contain.
Policies, runbooks, specs, and the other pages the team already keeps.
Output · the library as it isThe one that actually decides the question, not the nearest related page.
Output · the deciding paragraphThe citation stays attached. A sentence without a page is not an answer we send.
Output · passage and pageThe search is a way in. The documents stay where the team put them.
Output · no second wikiLanequery sits on top of the pages a company already has. It does not replace the library, and it does not invent a sentence the pages do not contain.
When two documents disagree, both passages stay in the answer. We do not fold them into one smooth reply. The person who asked still makes the call.
We start with the question, then return the smallest piece of the library that decides it: the passage, the page, and a note when two sources do not agree.
Illustrative. Nothing here is a customer result. The words come from the documents the team already has.
The work is shaped around the library a team already trusts. We do not start a second copy of it.
Policies, runbooks, and specs, searched where they already live.
No second library to maintain.The answer is the words that decide the question, brought back as they were written.
The person who asked can read them.A sentence without the page is not an answer we send.
Open the source and see the words.When two documents say different things, both remain in the answer.
We do not smooth them into one reply.The page stays with the answer.
A sentence without a page is a guess. We do not send those. The person who asked can open the source and read the words themselves.
We do not begin by designing a new library. We begin with the pages a team already uses when someone asks a question that should have a written answer.
Policies, runbooks, specs, vendor notes, the handbook nobody wants to retype. If a page is the one people open when they are stuck, it belongs in the search. Drafts that nobody treats as current stay out until the team says otherwise.
The useful search is not a tour of the archive. It is the short list of questions that come back every week: who approves, which version is current, what the rule actually says. We start there.
Each answer is a passage, the document it came from, and the page. If a second document disagrees, that passage is attached too. The person who asked decides. We do not decide for them.
When the question is answered, the files stay in the tool the team already uses. Lanequery is the way back to the paragraph. It is not a second home for the documents.
An answer is a short record. The words below are the fields, not a sample of someone else’s documents. When a field has nothing to say, it stays empty. We do not fill a gap with a likely sentence.
Lanequery is for people who are tired of searching three tools and still not knowing which sentence is the current one.
Operations, finance, support, and the people who keep a handbook because the work depends on a written rule. They have the pages. What they lack is a way to bring back the paragraph that decides today’s question, with the page still attached.
A useful week is a handful of real questions, not a rebuilt archive. The same folders stay. The answers get shorter and easier to check.
A team that wants a new wiki, a chatbot that sounds sure, or a summary that could have come from anywhere. If the documents are not written yet, there is nothing for us to return.
We also do not take a library and turn it into a public example. The pages stay with the team that wrote them.
Most of the work is refusing to add words. These are the limits we keep, even when a smoother answer would be easier to read.
If the library does not contain the answer, we say so. We do not draft the missing rule and present it as found.
Two current pages can disagree. Both stay. We do not average them into a single confident paragraph.
We do not migrate the library into a new home and then ask the team to maintain both.
Pages a team asks us to search are not used to build a product for someone else.
A likely sentence without a page number does not leave us. The reader has to be able to open the source.
We return the passage. The person who asked still chooses what to do with it.
Write if yours is not here. The note goes to [email protected].
No. The search reads the pages you already keep. When the question is answered, those pages stay where your team put them.
Both passages come back, each with its page. We do not pick a winner and hide the other line.
We say the library does not contain it. An empty return is a result. A guessed sentence is not.
No. If a page is unclear, the answer says the page is unclear and shows it. Editing the rule is the team’s work.
The team that asked, and the people doing the search. We do not publish the library, and we do not use it as an example for another company.
Send the question that keeps coming back, and the names of the folders your team already trusts. We will say whether those pages can answer it.
Name the documents the team already trusts. We will say what the library can answer, and what it does not contain.
Software company
Springfield, Massachusetts 01101
United States