What this note covers
This note explains how thelogicloom, the public site at thelogicloom.site, treats information when someone reads the site or sends an enquiry. thelogicloom is a digital marketing practice focused on higher education, with selective work in media, enterprise, and business-to-business growth. The pages describe services such as search, paid media, creative systems, lead qualification, and reporting. They are not a shop, and they do not sell a physical product.
The source layout of this site belonged to an education-focused agency practice. The public brand on these pages is thelogicloom. Where a sentence still needs a legal name, a street, a phone, or a confirmed mailbox, it is left unpublished. This site does not publish a registered office.
Two kinds of information show up in this work. The first is information a visitor types into this website. The second, which this static build does not process, is information a client might later share inside a paid engagement, such as account access or a definition of a qualified student enquiry. This note describes both, and it says which one is actually happening today.
Information the website actually stores
The contact form asks for a full name, a business or company name, a business email, a phone number, the service of interest, a preferred date and time, and project requirements of at least twenty characters. The browser checks those fields before it accepts the note. A missing name, a malformed email, a too-short note, a missing time, or a phone number that is not plausible will keep the form on the page and show an error beside the field.
When the form is valid, the browser writes a record into local storage. The record includes the fields, a timestamp, and a reference beginning with TL-. The success panel shows that reference. The record is not transmitted by this website. A person at thelogicloom will not see it until a live inbox is connected and the form is rebuilt to use it. Saying otherwise would be false.
The cookie bar writes a separate key, thelogicloom-cookie, when the reader presses Accept. It stores the word accepted. It does not store a name. It exists so the bar does not cover the page on every visit. The cookie policy describes the same key. The two pages should be read together.
Server logs, analytics identifiers, and advertising cookies are not part of this build. The pages do not load a tag manager. If a future deployment adds one, this note has to change first. Fonts may load from a public font host so the typography matches the source design. That request reveals a normal browser connection to that host. It is not a social network and it is not a remarketing audience.
How enquiries may be used once an inbox exists
If a confirmed mailbox is later attached, thelogicloom would use enquiry text to answer the question, to decide whether the brief fits, and to propose a scope. The fit question matters in this niche. A university admissions cycle, a publisher's audience goal, and a long business-to-business sale do not use the same funnel. The enquiry is the start of that judgment, not a list to be sold.
thelogicloom does not sell enquiry lists. The practice does not buy student data on this website. A message that arrives about a campus, a course, or a city is a business enquiry from an institution or a company, not a licence to contact the students mentioned in it. If a writer accidentally includes a student's personal data in the message, the live practice should delete that part unless it is actually needed to answer, and should tell the writer.
Staff access, once a live inbox exists, should be limited to the people who answer new business and the person who would lead the work. A shared inbox that every contractor can browse is a poor fit for admissions content. The storefront cannot name those people as a confirmed roster beyond the team page, which is carried from the source record and should be confirmed before it is treated as the current thelogicloom staff list.
Client and student information in a paid engagement
A paid engagement is separate from browsing this website. It starts with a written scope. Inside that scope a client might grant access to a site, an ad account, a tag, or a definition of a qualified enquiry. thelogicloom would use that access to do the named work: structure campaigns, write and test creative, repair technical issues that block discovery, and report outcomes in ₹.
Institutions sometimes want an agency to look at lead quality. Lead files can contain phone numbers, cities, course interest, and counsellor notes. Those files are the institution's information. thelogicloom's role, if it is agreed, is to help define what a qualified enquiry is and to measure cost per qualified enquiry. It is not to build a private student database for thelogicloom. Retention of any export should be no longer than the scope requires, and the scope should say who deletes the file at the end.
Media and enterprise work can include audience lists and brand guidelines. The same limit applies. The material is used for the engagement. It is not a right to advertise thelogicloom's other clients to that list. Case studies on this site name organisations because the source record presented that work. A new client should say in the scope whether their name and results may be published.
Sharing, retention, and security
This static site does not share form data with a vendor because it does not send the form. A later live site should list any inbox host, any file store, and any measurement tool before they are turned on. Sharing with a subcontractor, for example a specialist editor or a tracking engineer, should be limited to what that person needs and should be visible in the scope.
Enquiry records on this frontend live until the reader clears site data. There is no thirty-day server purge to describe, because there is no server copy. For a future inbox, a sensible starting point is to keep unanswered enquiries only as long as needed to reply, and to keep a short record of the reply for as long as a normal business correspondence file is kept. That period must be confirmed. It is not stated here as a legal minimum we claim to have certified.
Security on this build is the security of the reader's browser and of the host that serves the files. No payment card field exists. No password account exists. Do not send passport numbers, financial account numbers, or health information through the form. The form is for a marketing brief.
Children, other countries, and changes
thelogicloom's site speaks to institutions and to the adults who market them. It does not ask a child to register. Articles about student recruitment discuss how colleges communicate. They are not a service directed at children. If a parent believes a child's information was placed into an enquiry by someone else, the practical step on this build is to clear the browser storage on that device and, once an inbox exists, to write and ask for deletion of any server copy.
Readers outside India can open the pages. This build still stores enquiry text only on the local device. A live transfer of client files across borders would need to be described in the scope, including where the file sits. This page does not claim an adequacy decision or a certification mark.
When this note changes, the page should show a revised date and a short description of what moved. The current text matches the frontend as built: local storage, no checkout, no tag manager, sample business details still to confirm. A material change, such as adding a real mailbox or a measurement tool, requires an edit to this page before or at the same time as the change.
How to ask a question
Use the contact form and put the word privacy in the first line, plus any TL- reference you were shown. On this storefront the message stays in your browser. That limit is stated on the form's success panel as well. Until a mailbox is confirmed, there is no second channel, and we will not invent a phone number to look more complete.
Please do not send sensitive documents as a substitute for a scope. If you need a processing arrangement for student data, ask for it as part of the written scope. The public page can explain the practice. It cannot sign a contract by being read.
A month in the work
A privacy note is easier to trust when it follows a real month of work rather than a list of slogans. The calendar below describes how thelogicloom intends to handle information during a typical higher-education engagement. It is an operating picture for this storefront, and it still needs a confirmed legal entity before it is used with a live client.
Week 1
Week one is the enquiry. A dean, a marketing head, or a founder types a full name, a company name, an email address, a phone number, and a description of the admissions problem. On this storefront those fields stay in local storage under the key thelogicloom-enquiries. They are not posted to a server. The reference code shown after send, in the form TL- and eight digits, is generated in the browser so the writer can quote it later. If the writer clears site data, the note is gone. That is the correct expectation for this build.
Week 2
Week two, once a live inbox exists, would be the point at which a person at thelogicloom reads the brief. Until that inbox is confirmed, nobody outside the writer's own browser can see the form. A future live site should say who opens the inbox, how long the message is kept, and which vendor hosts the mail. Those facts are not published on this site. We will not invent a street address or a personal mailbox to fill the gap.
Week 3
Week three of a signed engagement is when client files start to matter. Campaign exports, landing-page copy, counsellor scripts, and fee tables are client information. thelogicloom would use them to plan media and measurement, not to build a separate consumer product. Student enquiry files, if a client later asks the agency to look at them, should be treated as the client's data. The agency's role would be limited to the task in the scope. This page does not claim that such a processing contract already exists.
Week 4
Week four is reporting. A leadership dashboard should show spend, qualified enquiries, and cost per outcome in ₹. It should not publish a student's phone number in a screenshot that gets forwarded around a board pack. Access should be limited to the people named on the account. When the engagement ends, working files should be returned or deleted on the timetable in the scope, except for records the agency must keep to explain an invoice. None of that file handling happens inside this static website.