Help

Access is by invitation. A work email can sign in once it holds a seat in a workspace. A seat comes from one of three places:

• » A partner firm sets up the workspace of a business and Fohrkast emails the administrator a claim link (see Claiming a workspace).
• » An administrator gives a colleague a seat under Members and sign-in. The address receives an email naming the seat and the workspace.
• » Fohrkast opens the workspace of a business, a partner firm or a distributor and emails its first person.

Each seat is a fixed set of permissions. Every grant, change and removal is recorded in the workspace's audit trail.

Overview opens with a setup checklist of nine steps, each with its time, who usually does it and what it unlocks. Steps go in any order, each is marked done from what the workspace already holds, and none blocks anything. A partner firm sees the same checklist for each client.

Members and sign-in, Plan and usage, holds the fit check for the administrator and the privacy lead: the figures declared at sign-up beside those measured (sign-ins, systems, websites, consent records and the people estimate from scans). A figure above a plan limit changes nothing until renewal; only seats stop an action.

Partner firms, distributors and Fohrkast's own staff hold the roles under Roles at each level.

Sign-in is by work email, without a password. Fohrkast emails a 6-digit code to the address; the code is valid for 10 minutes.

The administrator, privacy lead, developer, partner firm and distributor seats open sealed records, give approvals, make API keys or act for several businesses, so they require an authenticator app (Google Authenticator, Microsoft Authenticator or another app that shows 6-digit codes). The app is set up at the first sign-in, by scanning the QR code or typing the key shown, then entering the code from the app. Other seats may set up the app by choice.

• » Once the app is set up, each sign-in takes the email code and then a code from the app. A device cannot be remembered to skip the app code.
• » Set-up shows 8 backup codes, once. Each backup code works once, in place of an app code.
• » After 5 wrong app codes in a row, the account locks for 15 minutes.
• » Some actions ask for a recent app code even within a session: a code from the last 15 minutes to change who holds a seat, or to sign, renew or revoke a partner firm mandate; a code from the last 10 minutes to release a breach summary.
• » Administrator, privacy lead, developer, partner and distributor sign-ins end 12 hours after the email code.

Account recovery without the phone and without a backup code is not built into the product yet. Questions: support@fohrkast.com.

Three rules hold in every workspace. The administrator decides who holds which role, then steps back: owners assign roles and the roles carry out the daily work, and an administrator can hand role management to an admin. No role holds everything: money, data access, law and people management sit with different roles. Every grant, change and removal is recorded with the role key and the seat-bundle version, never a name or an email.

Members and sign-in holds an access review every 90 days: each seat with its role, its last sign-in and who granted it; the administrator or an admin confirms each seat or removes it, and the review itself is recorded. A notice shows while a workspace has a single owner. Only an administrator grants, changes or removes another administrator seat, and a workspace keeps one administrator.

A client manager acts for a client only within that client's mandate: the powers the client granted, until the mandate ends. A client the firm has not assigned to the client manager does not open, by any link.

A distributor sees partner firms by name and businesses as counts only, never business names or records.

Separation of duties: a rulebook release signed with Fohrkast's key needs the approval of a second person, the Founder or another law role, of the exact draft; a refund above ₹1,41,586 needs the approval of a second Founder or Billing role before it is sent. No one approves their own request. No Fohrkast role reads a business's records: only emergency access does, with a reason, a time limit and a log the business sees.

Enterprise and Institution start with onboarding by Fohrkast, in eight phases: proposal, security and legal review, kickoff, discovery and source plan, technical set-up, configuration and data mapping workshops, training and pilot, go-live and close support and hand-over. One rule decides who does what: Fohrkast does the work inside Fohrkast; the client's IT does the work inside its own systems; the client makes every legal decision.

• » The kickoff questionnaire, for the administrator, the privacy lead or the IT lead: the legal entities, the systems holding personal data, websites, apps, vendors, AI tools, notice languages and how many people hold each role. People are counted by role, not named. It produces the source plan (each system with its type, its administrator on the business's side and its scanner install session) and the seat plan.
• » Overview shows the onboarding plan: each phase with its planned and actual dates, the sources scanned, the websites on blocking, the workshops and training held, each item with its administrator and due date. Planned dates are estimates counted from the signed order form; a step that waits on the business moves them.
• » On the setup checklist, "Done by Fohrkast onboarding" marks the notice, the website and its banner, the data map, the vendor register and the AI register; "With Fohrkast onboarding" marks the scanner, the team's seats and the incident contacts and card, done by the business's own people in a session Fohrkast runs. The administrator names the privacy lead and the grievance officer.
• » The Fohrkast onboarding mandate, signed by the administrator on the onboarding plan's page, names the Fohrkast staff on the plan and the steps they may work on inside the workspace: prepare the privacy notice and its translations for the privacy lead, add each website and run the website check, draft purposes for the data map, add vendors to the vendor register and add AI tools to the AI register. It never opens sealed personal data, gives a seat or publishes; the notice and every legal choice stay with the business. It ends at hand-over, or when the included onboarding lapses 9 months after the order form, whichever comes first, and the administrator revokes it at any time. Each action under it is recorded in the business's audit trail with the power used.
• » Sessions: one data mapping workshop of 2 hours for each legal entity, and 4 role-based training sessions (administrator and privacy lead, iT and developers, front desk and grievance officer, incident team), held once for Enterprise and twice for Institution.
• » At go-live, Fohrkast issues the onboarding summary: the scope, what was set up, what the business confirmed, the success criteria and the open items with their administrators and dates. The administrator confirms and signs it on the onboarding summary page; both signatures are recorded, and it downloads as PDF and CSV.

A partner firm imports the businesses it advises. For each business, Fohrkast emails the administrator's address on record a claim link, valid for 14 days and usable once. The partner firm can send a new link.

The claim page names the business and the partner firm. The person claiming confirms being the administrator of the business, or authorised by the business to claim, and types a full name, which is sealed in the business's audit trail. Claiming gives the administrator seat to the address the link was sent to; sign-in then follows the steps above, with the authenticator app set up at the first sign-in.

A claim is refused from a session that holds a partner firm, distributor or Fohrkast seat, and for an address that belongs to a member of the partner firm.

No legal duty moves to the partner firm: the business remains the Data Fiduciary (s.8(1)). Until an administrator signs a mandate, the firm holds counts and drafts only, with no access to records or personal data.

The mandate is under Members and sign-in, Partner firm mandate. The administrator ticks the powers granted: publish documents, review and accept, accept unedited updates in bulk, log requests, and prepare and track incidents. Opening sealed personal data and adding staff are excluded unless ticked. A mandate runs for 12 months, can be revoked at any time with immediate effect, and shows a renewal prompt from month 11.

A partner firm's workspace opens on its Client portfolio: each client business with its claim and its mandate, the duties met, upcoming, open and overdue, the input required, the open cases and the next deadline. Counts only: client records, individuals and documents remain in each client's workspace.

• » Import clients: a CSV file, or pasted lines, whose first line names the columns business name, administrator name, administrator email, administrator mobile, sector preset. The sector preset is shop, accounting_firm, clinic, or blank. At most 200 clients per file. The preview shows each line's duties and any problem; nothing is created while any line is flagged.
• » Each client gets its own workspace, with the partner firm's seat (counts and drafts only), and a single-use claim link to the administrator email, valid for 14 days (see Claiming a workspace). While a workspace is unclaimed, Send again emails a new link to the administrator email on record. The administrator's details are held sealed in the client's workspace and never appear in the portfolio.
• » At import, the partner firm records who pays for the clients: each business, or the partner firm. Each client starts on the Through a partner plan; invoices go to each business until partner invoicing is settled.
• » Until an administrator of the client signs a mandate, the firm holds counts, dates and drafts for that business, with no access to its records or personal data. Under a live mandate, the client opens from the portfolio with its dates, privacy notice, requests and incidents; each action needs the matching power and is recorded in the business's audit trail with the mandate reference and the power used.
• » Drafts lists each client's privacy notice update drafted by Fohrkast from its records, and translations awaiting the client's own check. A bulk accept publishes the unedited updates as drafted, for clients whose mandate includes accepting unedited updates in bulk; a notice holding the business's own wording is accepted one business at a time.
• » The partner kit holds four training modules, each a lesson in the dashboard ending with a short test, a playbook for the DPDP retainer, client material and, for a client's IT team, the scanner's installation package. Each person marks each module done on its page; a person who has completed all four modules holds a Fohrkast-trained record: training on the Fohrkast product, not a professional qualification. The partner firm counts as trained once its Administrator or an Admin has completed all four.
• » Deal registrations, linked from the portfolio, lists the firm's registered prospects (see Deal registration).
• » Insights, linked from the portfolio: each client's health (duties due and overdue, requests near their deadline, open incidents, setup progress, scanner and website banner), renewals due, clients above a plan limit, drafts awaiting a client's approval, mandates ending and the firm's registrations by stage, for this month, the last 3 months or a financial year (April to March, IST). A client opens to its card of counts and states; its records open only under the client's mandate. Each table downloads as CSV.

A distributor's workspace lists its partner firms (accounting and tax firms, consultancies, IT resellers, law firms) with counts across the businesses each serves. Business names, individuals and records remain with each business and its partner firm.

• » Attribution: each business is attributed to a distributor when it is created or imported, from its partner firm's distributor, and when its partner firm joins a distributor. Fohrkast staff set or correct an attribution with a reason: not recorded at onboarding, recorded against the wrong distributor, moved under the distributor agreement or distributor agreement ended. Each change is recorded in the business's own audit trail with the new and the previous distributor.
• » Share-base statement: by month (IST) and plan, the businesses brought on through the distributor's partner firms and the amounts invoiced before GST, invoiced with GST and paid, in INR. Counts and amounts only: never business names, individuals or records. It downloads as CSV, each month dated from its first moment in IST (+05:30).
• » Businesses are counted as attributed at the end of the month (today, for the current month), by the plan then in force; a lapsed plan counts as Statutory only. Invoiced: tax invoices issued in the month. Paid: amounts received in the month against paid invoices, TDS deducted counted as paid, refunds excluded.
• » Until Fohrkast issues invoices through the platform, every amount reads zero and the statement says Billing not started. Counts are current.
• » Share: 15%, of the list price before GST of each license activated through the distributor. The share statement lists each license and its share; the share-base statement shows counts and amounts only.

The distributor kit holds the training modules and material for recruiting partner firms. Deal registrations: see Deal registration.

Insights, linked from the Partners page: a scorecard per partner firm (businesses, the share active, setup completion, renewals due, open and won registrations), the pipeline by stage, the share base by month and partner onboarding. A partner firm opens to counts by plan and status, never business names. Each table downloads as CSV.

Insights' Financials tab, for a distributor's Administrator and Finance seats and a partner firm: the share base or the client subscriptions by month, the share or earnings, a 3-month estimate with its method, retention and the weighted pipeline, before GST. Until billing starts it shows the weighted pipeline only. A partner firm's earnings are its commission on its clients' subscriptions, at the terms of the partner agreement. Each table downloads as CSV, as one Excel workbook or as one PDF; a distributor's never carry a business name.

A distributor or a partner firm registers a prospect under Deal registrations: the legal name of the business, its city, the expected plan, and a contact at the business with a work email and, optionally, a mobile number.

• » A registration holds a prospect for 90 days from the day it is made. The first valid registration stands: a prospect registered by any distributor or partner firm, awaiting Fohrkast or accepted and within its 90 days, cannot be registered again.
• » A prospect is matched on its legal name and city. Case, punctuation and a company form at the end of the name (such as Pvt. Ltd., Private Limited or LLP) are ignored.
• » Fohrkast accepts or declines each registration. Each shows as Awaiting Fohrkast, Accepted, Won, Lost, Declined or Lapsed.
• » The contact's details are sealed. Fohrkast staff open them only to check the registration, and each opening is recorded in the registrant's workspace log. They are cleared when the registration is declined or lapses.
• » A registration is won when the prospect becomes a business on Fohrkast: Fohrkast staff record it with the business it became, or it is matched when a business onboards whose legal name matches and whose address holds the city. A won registration holds its prospect with no end date. Staff record a registration lost when the prospect will not buy, and the prospect can then be registered again. The contact's details are cleared when a registration is won or lost.

The registration rule forms part of the distributor and partner agreements.

An individual may ask a business for access to their personal data (s.11), its correction or update (s.12(2)) or its erasure (s.12(3)), name a nominee (s.14), withdraw consent (s.6(4)) or raise a grievance (s.13). Requests reach the Requests page in two ways:

• » On the business's hosted request page, opened from its notice, short link or QR code, in English or Hindi and without an account. The individual confirms the request with a 6-digit code sent to their email, valid for 10 minutes, and receives a reference and a status code to follow it online.
• » Logged by a staff member from WhatsApp, phone, SMS, in person, email, letter or the website. The arrival time is required, and an entry made more than 24 hours after arrival is marked as a late entry. A request logged this way holds a reference only: no name, number or message.

Each request then has the same steps on its own page:

• » Verify identity. A staff member checks who is asking and records how. The email code on the hosted page shows only that the person holds the mailbox, so those requests are checked the same way. A request about a child also needs a parent: confirmed by an email code and a declaration (s.9(1), Rule 10), or checked by staff in person. No response can be recorded before the check.
• » Locate records. Where the scanner is set up, it searches the business's own systems for the individual; Fohrkast receives table names and row counts only.
• » Draft the reply. Fohrkast drafts it in English or Hindi, including reasoned refusals, which give the grievance route and then the Data Protection Board (s.13(3)). The business sends the reply; Fohrkast neither sends nor keeps it.
• » Erasure: the business records each vendor asked to erase the details and its answer, and its own deletion, then prints a deletion certificate.
• » Nomination: the nominee is recorded or revoked, sealed under the individual's key (Rule 14(4)).
• » Record the response and its channel. The administrator or the privacy lead then closes the request.

Each request carries the date of its duty from the signed rulebook. Access, correction and erasure are dated 90 days from receipt, a Fohrkast interpretation of Rule 14(3). A grievance is answered within the period the business publishes, at most 90 days (Rule 14(3)); grievances have their own desk under Requests. A nomination and a withdrawal of consent have no fixed period in the law (s.6(6) for withdrawal). Until 13 May 2027 these dates show as recommended steps.

The privacy lead, or the administrators where there is none, receives an email reminder halfway to the date and 7 days before it; once the date has passed, every administrator receives it too.

Details an individual gives on the hosted page are sealed under that individual's own key. Only the administrator and the privacy lead can open them, and a partner firm where the business grants that power in its mandate; each opening is written to the audit trail. Every step of a request is in its timeline, hash-chained (SHA-256), with times in IST.

Any seat from front desk upward reports an incident on the Incidents page: its type, when it was first noticed internally, any earlier alert from a tool, third party or individual, and when the business became aware that personal data was affected. The initial summary is encrypted under the business's key and holds no names of individuals. A drill runs the same deadlines with no filing made.

The awareness time is never pre-filled; the breach deadlines run from it (s.8(6), Rule 7). The business tells each affected individual and the Data Protection Board without delay (Rule 7(1), Rule 7(2)(a)); its detailed report to the Board is due within 72 hours of becoming aware (Rule 7(2)(b)). Until 13 May 2027 these show as recommended steps, not legal deadlines.

CERT-In's report is due within 6 hours of noticing or being told of a reportable cyber incident (CERT-In Directions, 28 Apr 2022, Direction (ii)). The administrator or the privacy lead records whether the incident is one of the Annexure I types, or not sure, and when it was noticed; the clock then runs on the incident and on Overview, alerts go by email at 0, 2, 4 and 5 hours, and stop once the report is recorded as filed. Fohrkast drafts the email and a phone script; the business sends.

• » Contact roles (privacy lead, grievance officer, CERT-In contact) are set under Incidents, Contacts and alerts. Each open incident duty alerts the holders of its role by email and in the app; an alert not acknowledged in time goes to the administrators.
• » The administrator or the privacy lead prints the incident card from Incidents, Incident card: one page for use when Fohrkast cannot be reached, on A4, as a wallet card (85.6 x 54 mm) to cut out, or as a text file. It holds the three Rule 7 steps as the signed rulebook states them, the CERT-In 6-hour line with CERT-In's email and phone, the business's contact roles and administrators, the contact in its published notice, the Data Protection Board's address once published (none as of 21 Oct 2026) and Fohrkast support. It holds the business's own staff contacts and nothing about any customer. Each print or download is recorded in the audit trail.
• » The report pack holds the facts and root cause, sealed under the business's key, an internal review, and the notice to affected individuals (Rule 7(1)). Fohrkast drafts both texts from the incident; the business edits them, and each is released only after a recent authenticator code.
• » The list of affected individuals is generated by the scanner in the business's own environment. Fohrkast holds counts only.
• » The administrator or the privacy lead records each filing per recipient: stage, channel, time sent (IST), an optional reference number (encrypted) and an optional receipt (PDF, PNG or JPEG, up to 10 MB). A filing without a receipt is recorded as declared.
• » The administrator or the privacy lead closes the incident with the outcome the business determines.

Fohrkast drafts the privacy notice from the business's purposes and data map; the business checks and publishes it (s.5, Rule 3). Each published version has one rendition per language, and each consent record points to the version and rendition it was given under.

Consent is recorded per purpose, from the website banner and from in-person channels, against a pseudonymous browser token. Names are not recorded. A withdrawal applies on the website at once.

On a website, the banner holds each marked tracker until the matching consent. A browser that sends Global Privacy Control or Do Not Track is treated as declining every optional purpose.

A website added in Fohrkast starts in report-only for 7 days from the banner's first report: known trackers run, and the website's card on the Consent page lists those the banner would have held. Blocking follows unless the administrator or the privacy lead keeps the website in report-only. Report-only is not available to a business that serves children or persons with a lawful guardian: s.9(3) bars tracking of children. The same card links to the install steps for WordPress (a plugin), Shopify and Wix:

• » WordPress: the Fohrkast Consent plugin 1.0.0, for WordPress 5.0 or later and PHP 7.4 or later, with the website key under Settings, Fohrkast Consent. It prints the banner as the first element in <head> on every public page and turns the script tags of known trackers into held tags, so the browser does not fetch them before consent. With the WP Consent API plugin active, it passes each choice on as statistics and marketing.
• » Shopify: the snippet pasted on the line after the opening <head> tag of the theme's layout/theme.liquid; a different or updated theme needs the snippet again. A Shopify App Store listing awaits Fohrkast's Shopify Partner account.
• » Wix: the same snippet under Settings, Custom Code, which needs a Wix Premium plan and a connected domain. A Wix App Market listing awaits Fohrkast's Wix developer account.

The Consent page shows the individuals with a recorded choice, choices by purpose and by notice version, and withdrawals.

A business without a website, or with places where people are asked in person, uses its hosted pages: the notice and consent choices, and the Your data page where individuals make requests. Fohrkast hosts both; no website is needed. The short link /p/<code> opens the notice and consent choices, and /p/<code>/data the Your data page. Links and codes carry no personal details.

• » Set-up is under Consent, Hosted page and short links. The administrator or the privacy lead makes the short link and adds a collection point for each place where people are asked: a counter, a waiting room, a delivery slip, an invoice footer. Each collection point has its own short link and poster.
• » Each short link prints as an A4 poster for the wall or an A6 slip, one per language of the published notice. The QR code and the link open the notice and consent choices, which link to the Your data page. The poster's short notice and the WhatsApp line come from the published notice.
• » The hosted pages show Not yet published until the administrator confirms the business, through a one-time link sent to the administrator's sign-in email address. The confirmation is recorded on the audit trail.

The front desk tablet, for a clinic, coaching centre or shop counter, is set up under Consent, Parent and guardian checks, shown for a business that serves children or persons with a lawful guardian.

• » Each person makes their own choice on the tablet; nothing is kept on it for the next person, and each choice is recorded as made at the counter.
• » The tablet opens the notice page in front desk mode: signed in with a front desk seat or above, or through a desk link that works without signing in. Only the administrator or the privacy lead makes a desk link, and it is shown once.
• » After each choice the tablet returns to the start for the next person, after 60 seconds if nobody taps Next person.
• » When a parent or guardian chooses, the tablet shows a reference for staff to check who is choosing; the choice is not used until the check is recorded.

A business adds each of its websites under Consent, Add a website. Only the administrator or the privacy lead adds, changes or retires a website.

• » Website address: https only, saved as scheme, host and port; a path is dropped. www.example.in and example.in are separate websites, and the banner records a choice only from pages served at the exact address.
• » Purposes: ticked from the purposes in the notice builder. Once a notice is published, the banner shows the purposes of the published notice.
• » Languages: the languages the banner and the notice page offer (s.5(3)), and whether the banner shows everywhere or in India only.

Each website has a banner key of its own. The Consent page shows, for each website, the shield.js line to install as the first element in the page <head>, without async or defer, and an example of a marked tag: a script marked data-fohrkast="analytics" or "marketing" runs only after the matching consent. Known trackers, including Google, Meta, Microsoft Clarity, CleverTap and MoEngage, are also held when another script adds them to the page. A tracker tag written into the page without the marking may be fetched, or run, before consent.

The website check runs when a new address is saved, and again from the Website check page. It reads up to 30 pages on the same site, respects robots.txt, and runs at most once every 5 minutes. It lists forms that collect personal data and trackers that load before consent. It does not sign in, submit forms or send cookies, and keeps field types only.

Retiring a website stops its banner key answering: Fohrkast no longer serves the banner's settings for it or records choices sent with it. Consent records already made stay on the audit trail. A website whose banner key also opens the hosted page and its short links cannot be retired; its address can be changed.

fohrkast-scan runs on a server in the business's own network. It reads a database or file store through a read-only login and transmits metadata only (labels and counts). Personal data values and database credentials remain on that server. It requires Node.js 24 LTS.

• » Downloads is under Members and sign-in. The administrator, the privacy lead and developers of a business can download, as can the seats of a partner firm or a distributor.
• » Each file is served from private storage through a link valid for 5 minutes, issued after the seat is checked. Each download is recorded in the workspace's log with the seat, the version and the time.
• » Each release lists the SHA-384 checksum of every file, signed with Fohrkast's release key (ECDSA P-384, SHA-384). The installation package holds the scanner, its checksum and signature, the release public key and the installation guide.
• » The install pages, one per tested database, are linked from Sources on the Your data page: checking the file, the read-only login, the first scan and removal.

A developer, the privacy lead or the administrator generates a scanner key under Sources; it is displayed once. Before every run, the scanner confirms its key with Fohrkast over HTTPS: the key must be live and not retired, the workspace active, the version not below Fohrkast's minimum and the file one Fohrkast released. Without that confirmation it reads nothing and sends nothing.

A retired key no longer activates any scanner, and Fohrkast refuses reports sent with it. Reports already received remain in the data map.

• » Fohrkast looks for personal data in each source it is given access to: databases and files through the scanner, business apps through connectors, websites through the website check.
• » During the data map review the business adds what discovery did not reach: vendors by hand on the Vendors page, more databases and files through the scanner, and anything else by writing to support@fohrkast.com, so that the record covers them.
• » Confirming the data map is the business's sign off that nothing is missing.

The AI agents page holds the register of the AI systems and tools in use, the review of each AI vendor, the controls on rented chat bots and the staff rule on AI use, on every plan. Fohrkast holds the names of systems and vendors and the answers recorded there. Prompts, chats and staff names stay with the business.

• » Register: each AI tool, AI feature and AI agent that sees personal data (s.8(1), s.8(5)), with its vendor, kind and purpose, the personal data it sees, the consent purposes it serves, where the data goes, whether the vendor trains on it, the answerable role and the next review. AI use identified by the code scan and the vendor list opens as a pre-filled entry. Only the administrator or the privacy lead adds or changes an entry.
• » Vendor review: each AI vendor's data terms, training opt-out, location, retention and sub-processors (s.8(2), s.8(5), Rule 6(1)(f)). Starting points come from the vendor's own published pages, each naming its source and the date read; a starting point is not the business's answer. The result is approved, approved with conditions or not approved, and a plain approval is refused while any answer is a consumer account, training on the data or not known. The review is kept on the vendor's record in Vendors.

Rented WhatsApp and chat bots: 5 controls for a bot rented from a vendor, each recorded as in place, not in place or not recorded:

• » A consent line is shown before the bot collects personal data (s.6(1), Rule 3).
• » No Aadhaar, health or financial details are collected without a stated purpose (s.5(1), s.6(1)).
• » A retention period is set for chat history at the vendor, with processing logs kept at least one year (s.8(7), Rule 8(3)).
• » Rights requests and complaints are handed to a named person (s.8(10), s.13, Rule 14(1)).
• » The bot's first message links to the privacy notice (s.5(1), Rule 3).

Staff rule on AI use: a one-page rule on which AI tools staff may use with personal data, adopted by the administrator or the privacy lead from a template, and each staff member's acknowledgement of it (s.8(5), Rule 6(1)). The wording is held encrypted under the business's key; acknowledgements record a staff reference and a role, never a name.

The Indian AI rulebook is a draft: duties for AI use under the DPDP Act 2023 and DPDP Rules 2025. A draft opens no task and never shows as overdue; the duties take effect only through a signed release.

A business's website, server, scanner and AI gate call Fohrkast's public API v1, under /api/in/v1. A key is shown once at creation; Fohrkast keeps only its SHA-256. Each key has one scope (consent check, gate, scanner, front-desk tablet) and one business. A test key reads only: a call that would add to the record answers 403 and records nothing.

The reference, with each path, key scope and error, scanner activation, consent receipts, the webhook and feed body and the NO OFFERS list, is at fohrkast.com/help/api.

Each workspace's audit trail is a chain: every entry carries the hash of the entry before it. Each night at 02:00 IST Fohrkast writes one line per workspace, with its id, its number of entries and the hash of its latest entry, and joins the lines into one fingerprint, the root of a Merkle tree (RFC 6962 hashing, SHA-384) of fixed depth 20, padded where there is no workspace, so its proofs are the same length whatever the number of workspaces. Independent time-stamping authorities in four countries sign the fingerprint; a night counts as sealed once two have signed it. They receive the fingerprint only.

fohrkast.com/trust/seal lists each sealed night of the last 30 days: the date, the fingerprint, the countries and times of the signatures, each signed token, and the OpenSSL commands that check a token. It lists no workspace and no count.

On Overview, the Administrator and the Privacy lead (and an Auditor, where the workspace has one) see the newest seal that holds the workspace's record book: the workspace's own line, the inclusion proof (the 20 hashes that join the line to the fingerprint) and Verify, which recomputes the fingerprint in the browser and compares it with the published one.

If an entry made before a seal were changed later, recomputing the chain would no longer give the hash in that night's line, and the signed fingerprint would show the difference.

A request about a business's own customers or staff goes to that business, which answers it in its workspace.

• » Decides and sends breach notices and intimations, and files with the Data Protection Board and CERT-In. Fohrkast drafts the notices and the intimations, and records each filing the business logs.
• » Sends the reply to each individual's request. Fohrkast drafts each reply.
• » Keeps its legal duties as the Data Fiduciary, including when a partner firm acts under a mandate (s.8(1)).
• » Takes its own legal advice: the dates, drafts and readings of the Act and the Rules in Fohrkast are not legal advice. Each reading states its basis; a Fohrkast interpretation is marked as one.
• » Makes its own statements about meeting the law. A Fohrkast record or evidence pack shows the business's records at a date and is not a certification of the business.