perffection.com technical details and rollout inventory
technical details, evidence posture, and rollout boundaries

Technical details

This page preserves the deeper cairn-backed rollout details for reviewers who need evidence, boundaries, and nonclaims. The friendlier public start page explains the customer path; this page keeps the technical posture, staged capability map, and owner-governed approval model in one place.

Show before you buy Start with a private brief, then review a candidate before any launch.
Evidence path Candidate, review, promote, rollback, and provider actions are meant to be evidenced.
Owner governed Reveal, CRM, email, money, domains, and hosting actions stay gated.

Ask for a reviewed preview

cairn-backed intake
Fit path
Service interests for the private brief

The submitted message enters the private intake workflow. Signup, production money, domains, real-user email, public webhooks, live LLM generation, and full migration are not open yet.

Owner entry

Owner workspaces are bearer-gated. This public entry opens the owner workspace shell only; it is not public signup, account creation, checkout, email, money, domain, webhook, or provider access.

Owner workspace Review workflow
Live now Private intake and reviewed preview are live through generic cairn routes.
Starter path Small businesses can begin with a brief and a preview, before buying a larger build.
Evidence posture Review reports, private blobs, rollback, and provider records are the operating model.
Not claimed yet Full migration, signup, production money, domains, public webhooks, real-user email, and live LLM generation.

What perffection is for

product path

The reference vision is a full business platform: website, content, CRM, calendar, shop, email, domains, analytics, voice, and app workflows. The Cairn remake starts with the parts already evidenced, then promotes more services only when their review, quota, rollback, and provider records are ready.

starter path

Small business first

Begin with a private brief, a reviewed preview, and plain-language status instead of a large up-front commitment.

growth path

Apps as needed

Calendar, shop, CRM, email, media, and analytics are product goals that must install through reviewed service boundaries.

enterprise review

Evidence over slogans

Security, ops, scale, and compliance posture are shown through signed evidence and runbooks, not certification claims on this page.

Fit paths

same private intake

perffection should welcome the low-friction starter request and the disciplined procurement review without changing the current launch boundary. Both paths use the same private intake and reviewed-preview surface; neither opens public signup, production money, provider delivery, public webhooks, domain provisioning, certified compliance, or live LLM generation.

accessible starter

Small business and ministry

Start with a plain brief, a reviewed preview, and clear next steps without a large procurement process.

operator reviewed

Growing operation

Map the desired workflow to reviewed service modules, quotas, rollback, owner controls, and provider evidence before launch.

procurement review

Enterprise evaluator

Ask for the evidence posture, risk boundaries, data handling, and runbooks that a serious buyer needs to inspect.

Engagement model

private brief first

These are ways to begin, not purchase buttons. Every engagement path starts through the same private brief and reviewed preview. No checkout on this page, no public account creation, no payment collection, no provider action, no domain provisioning, and no live LLM run is opened by choosing a lane.

starter engagement

Begin with a brief

A small team can describe the website or workflow, review the first preview, and decide whether a larger build is worth discussing.

guided build

Grow by reviewed modules

Additional CRM, content, calendar, shop, email, analytics, or billing work is scoped through evidence-labeled service boundaries before launch.

enterprise review lane

Inspect before commitment

An evaluator can review the current proof, nonclaims, private-data posture, rollback path, and runbook posture before any broader approval.

An operator follows up through the gated owner workspace; this public page does not start email, money, signup, webhook, domain, or provider flows.

Voice interview creation

provider closed

The spoken-creation path will let a customer or owner talk through an app idea, then turn that conversation into private transcript blobs, safe discussion metadata, and an owner-reviewed build brief. The current public page does not request browser audio permission, call ElevenLabs or any voice provider, upload audio, run live transcription, run live LLM generation, create a source candidate, deploy, promote, email, bill, or start provider action.

current path

Ask through the private brief

Select voice interview in the brief form when a guided conversation would help explain the app; the request still enters the private intake workflow.

cairn boundary

Transcript first, provider later

Future spoken sessions must map to Cairn realtime sessions, private transcript refs, provider receipts, resource charges, and plaintext-free access evidence.

human review

No automatic build

The owner chooses what becomes a support discussion, build brief, source review, or reviewed promote; the voice path does not auto-generate or auto-deploy.

Live ElevenLabs-style calling remains a separate governed provider rollout with signed receipts, ledger/resource accounting, no-secret evidence, transcript privacy checks, and explicit approval.

Service library boundary map

checked-in inventory

Service statuses come from checked-in service-library-chirho.json. They describe the current boundary posture for each module, not automatic live availability: provider, signup, production-money, public-webhook, domain, live-LLM, certification, SLA, bank, and Walmart approvals remain explicit.

Website and content intake

Private intake, safe list, governed reveal, reviewed preview link, and owner feedback metadata over generic Cairn app routes.

proven

CRM and lead follow-up

Owner-governed promote, CRM timeline metadata, CRM profile reveal, and test-mode email UI; production real-user email is separate.

proven

Reviewed preview and edit loop

Customer-preview-v2 route is reviewed-hash-bound with owner promote and rollback controls; it is not automated generation.

reviewed-preview

Email delivery

Hosted Mailu direct-SMTP test acceptance and IMAP-observed receipt evidence exist; sender policy and real-user promotion stay explicit.

test-evidence

Payments and billing

Hosted Stripe test-mode Connect transfer and reconciliation evidence exist; production money and webhook ingress require separate approval.

test-evidence

Domains and provisioning

DNS/TLS cutover, rollback, monitoring, and customer communication runbooks are future provider-action evidence.

explicit-approval-required

Calendar and shop

Interest capture and catalog copy only; bookings, orders, provider effects, quotas, and compensation paths are not launched.

deferred

Analytics, uploads, media, and voice

Privacy retention, storage, export, realtime transcript, and data-residency evidence must exist before customer media launches.

deferred

Live app generation

Source review and manually reviewed candidate paths exist; customer live-LLM backend generation is not running.

explicit-approval-required

SSO, API, and integrations

First-party perffection.com login and OAuth are future cross-app identity services backed by generic Cairn identity/session/scoped-token evidence; public signup and token issuance are not open.

deferred

Platform admin and tenant oversight

Safe tenant/app posture, service-account gas, monitors, provider enablement, and launch gates are planned as verified evidence views; impersonation and raw tenant plaintext stay closed.

deferred

Enterprise assurance

Point-in-time evidence and runbooks exist; audit certification, regulated-healthcare, SLA, bank, and Walmart claims are not made.

explicit-approval-required

Beta account path

no live auth action

The next public staging target is beta-chirho.perffection.com. The current perffection.com reference stays useful until the beta is polished and at or above feature parity; then the Cairn-backed beta can replace it deliberately. This account shell is an entry preview only: it does not submit credentials, open signup, log in users, issue tokens, start OAuth, reset passwords, call providers, or create app users.

M85 proves the generic Cairn auth flow locally: disabled registration, human-check-gated user registration, tenant-owner and app-user login, wallet history, OAuth client binding, scoped-token issue/use, scoped-token rate limiting, auth-attempt evidence, and credential/token non-persistence. That proof is local/staged evidence only; hosted public signup and hosted public login remain closed.

tenant owner

Owner account rail

Future owners need first-party sessions, app portfolio controls, wallet/topup posture, support, review/promote, rollback, provider setup, and app-user administration in one dashboard.

local-proof-only
app user

App-user account rail

Future app users should reuse a perffection.com login inside each app boundary, with app-scoped roles, preferences, usage, exports, support, and personalized admin themes.

closed-on-hosted
platform admin

Operator account rail

Platform oversight remains a separate operator identity and signed-action model; this shell does not impersonate tenant owners or app users and does not expose raw sessions or tokens.

no-impersonation
hosted gates

What still has to open

Hosted public signup requires reviewed human-check or equivalent anti-abuse evidence, rate-limit evidence, account recovery posture, production-money approval, and public auth monitoring before it becomes an action.

review-required

No form, fetch, action link, password field, OAuth callback, token route, provider login, checkout, production-money path, public webhook, domain provisioning, email send, voice provider, or live LLM generation is introduced by this beta account shell.

perffection.com login and app accounts

identity boundary

Future app users should be able to use a first-party perffection.com login across the apps they belong to, while Cairn supplies the generic identity, wallet, ledger, scoped-token, OAuth client, session, revocation, and audit primitives underneath. This public page does not open public signup, public login, OAuth authorization, third-party provider login, token issuance, app-user provisioning, hosted email, domains, storage, media, analytics, checkout, production money, public webhooks, real-user email, live voice provider, or live LLM generation.

account-foundation-chirho.json is the checked account foundation map for the full app: platform admin, tenant owner, app user, and service-account layers. Public signup, public login, OAuth authorization, token issuance, password reset, and third-party provider login stay closed until a reviewed implementation and hosted evidence promote them.

first-party login

Perffection-branded accounts

The product surface can be perffection.com, but identity rows, sessions, auth-attempt limits, wallets, and scoped tokens stay generic Cairn-backed records.

app scoped

One login, many app roles

Platform admin, tenant-owner, and app-user roles must stay distinct; no dashboard may silently impersonate another tenant or app user.

provider services

Email and domains later

Perffection-provided services such as hosted email or domains need provider custody, quota, billing, receipt, revocation, and admin evidence before offering.

full app sequence

Build account rails before automation

Self-serve app creation, LLM and voice edit discussions, payments/topups, domains, email, provider services, and real platform-admin actions depend on this account foundation.

The next implementation step is a reviewed identity/OAuth boundary, not live public signup or a customer-facing OAuth provider.

Platform admin oversight boundary

safe oversight

Perffection needs a platform operator view for tenant/app inventory, service accounts, gas refresh posture, monitors, provider enablement, support posture, launch gates, and audited operator actions. This public page records that boundary only: it does not open a platform-admin console, does not impersonate tenant owners or app users, does not reveal tenant plaintext, private blobs, bearer tokens, sessions, credentials, provider secrets, billing secrets, or raw ledger internals, and does not run cross-tenant rollback, email, provider, payout, signup, OAuth, token, domain, webhook, voice, or LLM actions.

tenant posture

Evidence before intervention

Platform operators should see verified app refs, gates, monitors, quotas, support status, and provider posture before any explicit audited action.

no impersonation

Separate operator identity

Operator support must be signed as an operator action, not hidden inside a tenant-owner or app-user session.

small-business readable

Safe status, not raw internals

The same posture should be understandable to a small business while preserving enterprise audit boundaries.

The next implementation step is a generic, owner-gated platform-admin safe overview read model; live operator actions require separate reviewed Cairn primitives.

Resource admission posture

quota map

resource-admission-chirho.json maps noise, reads, writes, reveals, provider actions, money, review/promote, media, and generation candidates to the intended Cairn admission boundary. This is a planning and evidence map: it does not claim automatic capacity, traffic immunity, or finished enforcement for deferred modules.

Static GET noise

Public shells and static JSON should terminate at Caddy/static logs, not durable DAG, CAS, app-state, effect, privacy, or ledger rows.

edge-static

Private intake writes

Accepted public writes create private-blob refs and safe metadata; heavier promotion needs trusted-source gates and owner write quotas before durable work.

admitted-private-write

Owner safe reads

Owner dashboards use verified gates and safe projections; disposable status refreshes can be shed while signed evidence remains authoritative.

owner-gated-read

Governed reveals

Plaintext appears only in the owner response/browser session; reveal access logs are privacy evidence and should consume owner and app reveal quota.

governed-reveal

Email provider actions

Provider sends are paid-effect-gated, idempotent, and signed; replay must not double-send or double-charge.

paid-effect-gated

Money actions

Money-adjacent work is verified-ledger gated; production money and public webhook ingress remain separate approvals.

paid-effect-gated

Review and promote

Review reports and ref moves are hash-bound audit history; rollback is a compensating ref move, not erasure.

reviewed-ref-move

Media and analytics

Customer media, transcripts, analytics streams, retention, export, and storage quotas are deferred until lifecycle evidence exists.

deferred-enforcement-required

Generation candidates

Future generation consumes model budget, review quota, and deploy quota; generated code must stay review-bound before live refs move.

deferred-enforcement-required

Todo app data-growth example

rough ranges only

data-growth-example-chirho.json uses a simple todo app to explain which requests create durable Cairn records and which should stay at static edge logs. It is an explanatory estimate, not pricing, not capacity evidence, and not a scale guarantee.

Anonymous static GET noise

Hundreds to many thousands of page and asset GETs can happen before a real write; query-string noise should create zero intended durable Cairn rows.

edge log only

Private todo writes

Tens to hundreds of item writes per day would create private refs plus signed app-state/query/effect evidence; raw todo text stays private and is not shareable evidence.

durable private write

Owner safe reads

Dashboard refreshes can outnumber writes; they should use verified gates, caches, and volatile/read evidence rather than customer-state rows per refresh.

volatile read pressure

Governed reveals

Plaintext reveals should be rare and intentional; each can add plaintext-free privacy access evidence while plaintext stays in the owner response.

privacy log growth

Cold-storage candidates

Old completed items and stale projections may move cold only through policy that preserves verifiable refs, signatures, and restore evidence.

retention policy needed

Deferred heavy surfaces

Media, realtime voice, analytics streams, and live generation can grow faster than todo writes; each needs separate quota and restore proof.

separate proof needed

Cold-storage lifecycle boundary

posture map, no action

cold-storage-lifecycle-chirho.json explains what may be disposable, what may move cold, what must remain verifiable, and what needs restore evidence in a time-travel Cairn app. It is not active GC, not live archive automation, and not permission to erase history.

Edge GET aggregate logs

Public static GET noise is disposable external log data; it is not app state and does not need Cairn restore evidence unless elevated by an incident.

external-disposable-log

Disposable query projections

Safe list and status projections may be rebuilt from authoritative signed rows; restore proof should verify the source rows before display.

warm-disposable-projection

Private customer write refs

Private intake, feedback, CRM refs, and private blobs may move cold only when signatures, hashes, key ids, subject binding, and governed reveal still verify.

hot-verifiable-record

Privacy access evidence

Plaintext-free access records are never-disposable audit evidence; archival custody must preserve sequence, subject scope, and no-plaintext proof.

never-disposable-evidence

Ledger and provider evidence

Money and provider history cannot be undone by erasure; cold restore must re-run ledger, provider, and reconciliation verification.

never-disposable-evidence

Source review and ref history

Unpromoted candidates may become cold candidates, but reviewed hashes, promote records, rollback records, app refs, and route refs remain verifiable history.

cold-verifiable-candidate

Deferred media and generation artifacts

Media, voice, analytics, and generated code need separate storage quota, retention, export, data residency, and restore proof before launch.

policy-required-deferred

Public build review

review-only, no deploy

This public build review shows the current customer-preview candidate. It is non-authoritative transparency: the report moves no app refs, runs no effects, and creates no lead data.

A separate human-reviewed promote step is required before any reviewed candidate becomes a live app. Capability-bearing candidates stay local-review evidence unless the owner explicitly approves them through generic cairn controls.

App loading
Cost loading
Capabilities loading
Candidate loading
  • customer-preview route review loading

Build-before-you-buy path

1
Share Send business goals, services, links, and constraints through private intake.
2
Preview Receive a reviewed preview or app candidate before buying a full launch.
3
Refine Use customer preview feedback and owner review to request changes.
4
Approve Owner-approved work moves through generic Cairn promote and rollback controls.
5
Operate Quotas, evidence, compensation, domains, email, billing, and support become visible as each service is approved.

perffection is a separate app over cairn. cairn remains the generic runtime; perffection uses generic owner/admin-gated routes and blessed capabilities instead of engine-baked product routes. This page describes the product path; it does not claim public signup, production money, domains, real-user email, public webhooks, live LLM generation, or full migration are open.