Without governed context
“Draft a festival update. The date is somewhere in our calendar, capacity changed yesterday, and please remember our old policy…”
- Manual copy and paste
- Unknown source freshness
- Approval history disconnected
BookMyMandir™ / Automation Studio / proposed add-on
Your festival team should carry approved context into every workflow.
One governed context layer for temple operations—designed for official APIs, temple-owned accounts and human approval. The execution product is not available yet.
Tenant: temple workspaceMode: draft + approvalStatus: proposed
- Official APIs or approved credentials
- One temple tenant per context item
- Human approval before public action
- Planned tenant MCP · no session pooling
Designed to connectEvidence shown per source
TWTemple workspaceFoundation onlyAVApproved account vaultFoundation onlyMPTenant MCP endpointNot builtVEVedika adapterNot builtXAXalen Studio adapterNot builtWBTemple websiteNot builtSOOfficial social APIsNot builtMCMail & calendar APIsNot builtANApproved analyticsNot built
Workflow proposal / no live data
See how a governed temple workflow would read.
Select a scenario to inspect the source, context and required approval. This preview does not execute an automation.
RequestPrepare one review packet for today’s temple operations.
1Keep each source timestamppolicy check
2Omit unavailable recordspolicy check
3Separate facts from suggested follow-upspolicy check
Proposed outputDraft brief awaiting operator review
No action is taken from this preview.
Concept preview · no connector, model, provider or temple record is active in this surface.
Connection walkthrough
An account name is not an integration.
Each provider stays unavailable until its exact contract, scopes, revocation and tenant isolation are verified.
TWTemple workspaceFoundation onlyAVApproved account vaultFoundation onlyMPTenant MCP endpointNot builtVEVedika adapterNot builtXAXalen Studio adapterNot built
Versioned source envelopetenant · actor · scope · provenance · consent · freshness
Approved or planned interfaces
APISDKMCP
A future tenant-scoped MCP endpoint may connect from evidence-labeled supported clients. BMM-initiated model runs require an official API or BYO approved API key.
- 01Authorize
Use an official provider contract and minimum scopes.
- 02Structure
Attach tenant, source, consent and freshness.
- 03Approve
Keep public and destructive actions behind a person.
The operational gap
Records exist.
Decisions still lose their context.
01Temple teams move between enquiries, service capacity, content, staff and provider accounts.
02Copying fragments into another tool drops consent, provenance, freshness and who approved what.
The intended difference
Don't reconstruct the temple before every task.
With the proposed Studio
“Prepare a draft from these approved sources. Cite missing facts and stop at review.”
- Tenant and source attached
- Missing data explicitly omitted
- Human review remains required
What one approved workflow learns, another may reuse only within the same tenant and grant.Architecture target · not a live claim
How it is designed to work
Connect once. Keep control at every step.
Non-negotiable product rules
Automation that stays accountable to the institution.
0consumer AI subscriptions or browser sessions automated
1temple tenant boundary for every connection, item and run
Humanapproval before public, financial, hiring or destructive actions
Context the temple can govern
The account, source and decision trail remain visible.
Portability, revocation, retention and deletion are acceptance gates—not footnotes.
01 / ScopeOnly customer-approved sources and fields
No neighbouring repository, private database or unapproved provider scope becomes context.
02 / ProvenanceEvery item keeps where and when it came from
Drafts distinguish recorded facts, missing data and suggested work.
03 / ControlRevoke, delete and rotate without a support dependency
These controls must be tested before a connector can be called real.
04 / PortabilityTemple-owned records leave in a documented format
Provider-held data and retention limits must remain explicit.
Designed for temple institutions
One context layer. Different operator responsibilities.
Start the day with the records that need a decision.
Proposed briefs bring together open enquiries, capacity, calendars and internal queues without inventing a completed booking or outcome.
- 1Review what changed
- 2Assign the next human owner
- 3Keep source timestamps attached
Required sources
The underlying BMM records are at mixed maturity; no Studio orchestration exists.Approved calendar records · Open enquiries · Capacity desk · Support queue
Separate add-on packaging
A proposed INR pilot for Pro, Max and Team.
These display prices are separate from core BMM plans. Checkout, entitlements, GST display, provider-cost treatment and paid activation do not exist.
PROPOSED_PILOT · GST/tax display and checkout are not active · pricing copy never grants entitlement · Included limits and provider-cost economics await approval.
Proposed pilot
Automation Pro
₹1,099/moProposed annual total ₹13,188Proposed add-on for one operator workspace- Bounded agent slots
- Bounded approved source accounts
- Draft and review workspace
- Separate usage budget
Proposed pilot
Automation Max
₹6,799/moProposed annual total ₹81,588Proposed add-on for higher-volume teams- Higher policy-governed limits
- More approved source accounts
- Shared run history
- Provider-cost guardrails
Contact proposal
Automation Team
ContactProposed per-seat institutional add-on- Role-aware approvals
- Shared tenant context
- Institutional onboarding
- Scoped support and service options
Need hands-on delivery?
Scope a separate professional service order.
Onboarding, migration, websites, content, campaigns and provider setup require written scope, least-privilege access, approvals, change logs, fees and handback.
Discuss servicesFrequently asked
The boundary is part of the product.
Automation Studio is a direction with a deliberately locked first shell. Public claims advance only with evidence.
Review all BMM tool maturityNo. This is the first public and dashboard shell. The separate entitlement, INR billing, provider grants, context ingestion, skill registry and run service are not built, so the dashboard stays locked.
BookMyMandir will not pool or automate consumer subscriptions or browser sessions. A future tenant-scoped MCP endpoint may be connected from evidence-labeled supported Codex, Claude or other clients. Model runs initiated inside BMM require an official API or a customer-supplied approved API key.
No. They are upstream provider products. Even under common ownership, BookMyMandir needs a versioned, approved and tenant-safe client contract before a capability can be offered here.
Not in this shell. The intended architecture requires a human approval before public posts, ads, payments, hiring outreach, directory publication or destructive provider actions.
No. They are separate proposed add-ons with separate usage, provider-cost and invoice lines. INR price, GST, trial, limits and seat rules are still awaiting business approval.
A temple may request separately scoped onboarding, migration, website, content or campaign services. A request is not an order or delivery promise; scope, approvals, access, fees and handback must be agreed in writing.
Build evidence, not theatre
What happens after this shell.
One real vertical slice
One official source, one tenant model, one approved skill, one gateway, revocation, deletion and audit.
Separate INR entitlement
Business-approved limits, GST display, provider costs, webhook idempotency, cancellation and fail-closed access.
Evidence-led expansion
Each connector and skill stays planned, foundation, beta or verified according to its own passing contract.