A self-contained record. Every governing document is reproduced in full at the foot of this page, so nothing here depends on repository access.
A safe editing and content-production layer for a website that already exists. The people closest to the facts make allowed changes; whoever is responsible for the site keeps the bounds, the proof, and the way back. No migration, no rebuild, no second site that quietly becomes the real one.
It exists because every owner of a live site faces the same bind. Routine change is either too slow and expensive — wait for the person who can safely touch the site, and pay for a sentence — or too dangerous, handing over wp-admin, SFTP, the theme, or the database. A rebuild is disproportionate and usually politically impossible.
First wave: independent business owners, and the agencies and freelancers who built their sites. Adjacent: in-house marketers at multi-site and franchise operators, and membership organisations. The website speaks to owners first with an agency route one click away; outbound sales effort concentrates on agencies, because one agency brings a portfolio, already holds the credentials, and absorbs first-line support.
Bounds, history, verification and restore are what make that freedom safe to grant. They are supporting reassurance, not the leading reason anyone buys.
BRAND.md is reproduced below in full and is the most developed brand thinking that exists. It should be read as one candidate direction — particularly its §7 visual language, with the deep muted blue-green palette, oxidised copper accent, bracket mark and editorial restraint.
It carries no special authority in this decision. It was written first, which makes it feel settled; that is recognition, not merit. Any other direction — including one nobody has drawn yet — should be evaluated on exactly equal terms, and should win if it serves the strategy better. The same applies to its messaging framework and tagline ordering.
The strategy in VISION.md: the audiences, the channel split, USD pricing with the invoice-and-wait anchor and the annual plan, demo-before-credentials onboarding, and Studio being built in parallel. The product truths in PRODUCT-SURFACE.md and README.md. And the constraint that restore claims must be scoped honestly to the active connection, because the defects behind that are real and recorded in README §3.4.
Not settled: the visual identity, the interface structure, the message hierarchy on the page — and the name itself, which has passed registry and web screening but has not had a professional trademark similarity search.
Each proposes a distinct identity and a distinct adaptation of the product interface. All six are self-contained pages, theme-aware, using no external fonts, and all were updated for the 2026-08-15 documentation. They do not share a single copy treatment; two families of copy exist across them, which is worth normalising before a final side-by-side.
Thesis: the calm proofing desk beside the live shopfront — measured access, visible states, a clean record of every change. This is the BRAND §7 direction.
Interface idea: the conversation is paired with a separate evidence ledger. Conversation carries intent and explanation; the ledger carries operational fact, state transitions, affected content and undo availability.
Strength: most mature system design; cleanest separation of guidance from operational truth. Risk: emphasises the mechanism rather than the reason to buy.
Recommended pair
Thesis: keep the owner's familiar digital address open, useful, current and recognisably theirs.
Interface idea: the conversation is anchored to the selected section of the live page. The owner picks real content and discusses the change in context; bounds, verification and recovery stay available without dominating.
Strength: the best expression of the actual reason to buy, and it states directly that agencies can grant modern autonomy without surrendering the relationship, brand boundaries, or higher-value work. Risk: read too literally it looks specific to local retail, and must visibly stretch to professional services, organisations and agency-managed portfolios.
Thesis: every change is a calm, visible route from permission to public proof, with the return journey clearly marked. Drawn from public-service information systems and quality-control notation.
Interface idea: the conversation sits beside a persistent publication route showing where the operation is between defined access, backup, bounded operation, public verification and possible restoration.
Strength: strongest operational clarity, especially for agencies and higher-consequence changes. Risk: procedural or institutional at an owner-first front door, and can make an everyday task look more complex than it feels.
Thesis: BRAND §7 taken to full strength and built as its own best case. The proofing metaphor is structural rather than decorative — trim sheet, register marks, marginal proof annotations, and a toggle that strips the correction layer to reveal the clean page beneath.
Interface idea: the three voices in the panel become three kinds of mark — a pencil proposal that has changed nothing, a hand annotation from an accountable person, and a signed-off proof of publication. The pre-credential demo is the pull versus the press.
Strength: reads instantly as work by someone who has been responsible for a live site. Risk: warmth. A slow brand with no single memorable image, and a metaphor that explains change well and Studio not at all.
Recommended pair
Thesis: it belongs to the shop, not to the agency. Calm editorial infrastructure is agency-coded and reads as someone else's professional tool the owner is being allowed to borrow; this should look like equipment she owns.
Interface idea: phone-first at real device proportions, because the buyer is often standing in a kitchen. The Charter becomes an enamel plate bolted to the panel. One rule governs the voices: only the record casts a shadow. Emoji controls are replaced by a single drawn shop tag, cutting the footer from three controls to one.
Strength: wins the owner outright, and survives a phone in bad light. Risk: the institutional buyer defending a vendor to procurement; strong flavours date faster; some agencies read it as charming rather than as a peer.
Thesis: trust is not a feeling, it is a record you can read. Softness is not evidence.
Interface idea: the conversation and the audit log become one numbered register, so scrolling back through the chat is the history and the separate history surface disappears. Progressive disclosure becomes a Plain / Record / Full lever. The pricing argument is itemised arithmetic rather than a claim, and restore scoping is a per-transport coverage table.
Strength: the most rigorous, and the only one where honest limits read as confidence rather than as a hedge. Risk: reads serious before friendly, may be filed as accounting software in a four-second phone judgement, and is expensive to maintain.
The owner's motivator is making small changes now, without paying and waiting for each one. This is the first filter, not the last.
Test each direction with an agency principal arriving from outbound onto a page written for owners. Do they feel attacked, or equipped?
Studio is a records-and-approval workspace being built in parallel, not a later phase. “We would need a new image for that” is a cost arriving in months.
Custody is the qualifier that makes it safe to say yes, not the motivator that opens a wallet. It should be present exactly where the fear is, and quiet elsewhere.
Weigh against how fast a strong flavour dates, and against the identity having to work inside sites other people designed.
Identity is exclusive. Interaction patterns are composable, and several below are worth keeping regardless of which identity wins. Do not merge visual identities.
The site can be loud. The panel lives inside sites other people designed and must be a good guest, or agencies will not deploy it. A direction can legitimately win one surface and lose the other, and the fix is usually to quieten the panel rather than to change the identity.
These solve specific product problems and can be adopted under any identity.
| Pattern | From | Problem it solves |
|---|---|---|
| Conversation anchored to the selected page section | Living Shopfront | Makes the change concrete and in context instead of described in the abstract |
| Separate evidence ledger beside the conversation | Margin & Measure | Splits model intent from operational fact, so a fallible voice cannot be mistaken for the record |
| Persistent publication route | Verified Sequence | Shows where an operation is between access, backup, operation, verification and restore |
| Conversation and audit log as one register | Ledger Rule | Removes the separate history surface entirely — scrolling back is the history |
| The Charter surfaced as a standing plate | Painted Tin | Gives the product's namesake concept a visible home; today it has none |
| Named disclosure lever instead of a hidden gesture | Ledger Rule, Proof Desk | Replaces the triple-click developer-mode easter egg with discoverable levels |
| Undo shown only where a verified return path exists | Margin & Measure family | Encodes honest restore scoping in behaviour rather than in a caveat |
Adopt this one whatever happens: “Undo appears only when this connection has a verified return path. SiteCharter states the available coverage before publishing, and verifies a restore after it happens.” It is the strongest formulation of honest restore scoping in the set, because it is a product rule rather than a disclaimer.
The strongest fit for why anyone buys is the warm, owner-first, shopfront register — it makes everyday autonomy feel valuable in the design itself rather than asserting it in a sentence. Two directions express it, and they have never been compared side by side.
Since the stated risk for both is that they read as local retail only, the one that stretches more easily has the advantage. That is an argument from stated risk, not from having looked at them.
Required either way — make the pricing anchor a shared cost, not an accusation. Every direction currently frames it as a small agency change costing $50–150 plus days of waiting. Outbound is asking those same agencies to adopt this as a retention tool, and their clients can read the page. Make the loop the villain, not the agency.
No agency surface exists in any of the six. Outbound targets agencies, so outbound needs a page to land on, and its thesis is the retention argument: let clients feel the shift without concluding they no longer need an agency. What exists today is a navigation link deliberately kept secondary. The owner front door has been built six times over; the surface the revenue motion points at has not been built once.
Verified programmatically across all six directions: no external network requests, no embedded font files, theme-aware rendering, and no forbidden vocabulary — no unqualified reversibility claim, no comparison against website builders on the pricing surface, and no currency other than USD as a source figure.
Not verified: nobody has looked at any of the six rendered in a real browser. All checking has been structural. Visual judgement is entirely open, and the decisive test — the hero and demo section in front of three owner-operators on a phone, and the agency argument in front of two agency principals — has not been run.
The complete governing documents as of 2026-08-15. Nothing on this page depends on repository access; these are the originals, not summaries.
Version: 0.3 (working document)
Date: 2026-08-14
Status: Strategic foundation for further development, branding, and commercialization
Product name: SiteCharter (brand rationale and domain evidence in BRAND.md)
SiteCharter is the safe editing and content-production layer that lets the people closest to the facts update the existing website — without giving away control of that site.
The product solves a recurring bind that appears at one site or across a whole portfolio:
SiteCharter provides delegated autonomy with safeguards: named people can make allowed changes and produce structured material; the responsible party defines the bounds; the system retains proof, history, and the ability to restore. The public site stays the one already delivered or owned. There is no migration to a new platform and no second site that quietly becomes the real one.
Core position:
Autonomy on the site you already have. Control stays with whoever is responsible for that site.
The first-wave message must make the trade explicit: the people closest to the facts can act; the responsible party keeps the bounds, the proof, and the undo. Agency language can make the two sides personal, but the core position cannot require an agency in the story because the same operating model must work for in-house and membership teams.
Three pillars:
Tone: Calm, competent, adult, trustworthy. Avoid “AI magic” and revolutionary rhetoric.
Safe, conversational editing directly against the live site via an overlay panel.
Private production space for structured content and more advanced output.
Studio is a deliberate, named part of SiteCharter — not an invisible integrated feature and not a fully separate product.
Every buyer already has a live website—or a fleet of them—with real history, integrations, search equity, and organisational ownership. Routine change is either too slow and expensive (wait for the person who can safely touch the site) or too dangerous (hand over wp-admin, SFTP, the theme, or the database). A rebuild is disproportionate and often politically impossible.
They need a third path:
Named people make allowed changes. The system proves those changes on the public URL. The responsible party can inspect and reverse them.
That job stays constant between a shop, an agency client, a franchise location, and an association. What changes is who pays, who defines the bounds, who supplies the facts, who approves, and whether the work is a direct Edit or a structured Studio job.
One person may hold several roles at a small business. At larger organisations they separate.
| Role | Decision or job | Typical people |
|---|---|---|
| Economic buyer | Decides whether less waiting and less risk justify the subscription | Owner, agency principal, marketing director, secretary-general |
| Responsible party | Defines access, allowed operations, approval rules, and the restore path | Freelancer, agency operator, web lead, central marketing |
| Editor / producer | Supplies the current facts and asks for the change or produces the recurring package | Owner, client employee, local manager, comms staff, volunteer |
| Approver | Confirms sensitive or structured output before publication | Owner, account lead, brand lead, board or association officer |
The product must earn trust from both sides of the handoff. Editors need confidence that they can act without breaking the site. Responsible parties need evidence that autonomy does not become uncontrolled access.
| Surface | Job | Typical use |
|---|---|---|
| Edit | Direct, bounded change to the live site | Hours, offer, photo, correction, staff detail |
| Studio | Private source → structured record → review → artifact → explicit publish | Menu, event programme, member update, location campaign, exhibition list |
Both surfaces use the same site adapters, policies, public verification, history, and restore path. Studio is not another platform and not a separate brand. It is the private production room for work that should not begin as an instruction against the live page.
These are the benefits the product must demonstrate, not merely claims for a brochure.
The business outcome is a shorter path from fact to verified public change, with a smaller blast radius and lower recovery cost.
What the system does not claim: it will not replace a redesign; it will not become a first-class connector for every locked builder at launch; it is not a general automation platform, a membership-management system, a franchise CMS, or 24/7 support.
Who they are. Owner-operators and the trusted people beside them: an office manager, clinic receptionist, restaurant manager, shop employee, venue coordinator, or consultant with one main property. The buyer and editor are often the same person; the original freelancer may still be the responsible party.
Buying trigger. A visible fact is wrong now; a recurring stream of small invoices has become irritating; the original builder is slow or gone; or the owner has already broken something once in the CMS and no longer wants full access.
Job to be done. “I need Tuesday’s hours, this week’s offer, or a new photo on the site I already paid for—today—without breaking it and without paying a specialist for a sentence.”
Current bad options. Wait and lose sales. Pay for a tiny change. Enter an unfamiliar admin and hope. Leave the site stale. Move to a simpler builder and sacrifice the site they already invested in.
Why they buy. They work on their own URL in plain language, see draft → verifying → published, and have a visible undo path. The setup proves access and completes a harmless verified edit before asking for trust.
Likely objection. “If this touches my live site, how do I know it will not break it?” Answer with the actual sequence—defined access, backup, bounded operation, public verification, restore—not with model accuracy.
Lead with. Update the site you already have, without waiting for every small change. Verified and reversible.
Success looks like. The owner completes the first verified edit during onboarding, returns unaided for the next real change, and prefers the subscription to the old wait/invoice cycle.
Acquisition. English-first marketing, direct signup, and referrals from builders who no longer want to provide ad hoc copy support.
Who they are. Solo WordPress or static-site freelancers through small studios and maintenance teams. They delivered the site, remain reputationally responsible, and still receive the low-value tickets. They can be buyer, responsible party, approver, and distribution channel.
Buying trigger. Routine edits consume margin; a client asks for wp-admin; a maintenance retainer is commercially awkward; the agency wants a cleaner handoff after launch; or a client is at risk of leaving because simple work feels slow.
Job to be done. “Give the client autonomy over routine facts so I can stop being a copy-change helpdesk—without giving away broad access or losing control of the site I am still expected to support.”
Current bad options. An underpriced retainer that drowns the team. An overpriced retainer the client resents. Full CMS access that causes design drift and emergency rescue. A hard refusal that damages the relationship.
Why they buy. The agency defines paths, operations, roles, and optional approval; sees public verification and history across sites; reuses Studio Blueprints for recurring work; and can reverse a client change without reconstructing what happened.
Economic benefit. Routine tickets disappear or become client self-service; oversight becomes a defensible service; handoff requires less bespoke training; a portfolio creates partner or affiliate revenue without forcing white-label delivery.
Likely objection. “Are you taking the client relationship?” The workspace belongs to the site, but the commercial model welcomes the agency, makes responsibility visible, preserves agency-owned Blueprints, and supports either agency-paid or client-paid accounts.
Lead with. Give clients room to update. Keep the safeguards you are responsible for.
Success looks like. A client publishes a verified edit without the agency typing it; the agency can see exactly what happened; routine ticket volume falls; both parties still know who owns which responsibility.
Acquisition. Run in parallel with direct owner acquisition through founder-led agency outreach, a small design-partner cohort, partner terms, and evidence from real handoffs.
Who they are. Brand, digital, and marketing-operations leads at franchise systems, retail and clinic groups, hospitality portfolios, dealer networks, and other organisations with tens to hundreds of existing local sites or location sections. Central marketing usually buys. A web lead or agency of record may define the bounds. Local managers supply the facts.
Buying trigger. Location data is visibly stale; central marketing is an update bottleneck; local CMS access has produced off-brand pages; a campaign requires many near-identical local variants; or a migration proposal is too expensive and disruptive.
Job to be done. “Locations must stay locally true—hours, menus, offers, staff, notices—without drifting off-brand, and I need to know and reverse what went live.”
Why the current choices fail. Locking local teams out produces stale sites. Broad CMS roles produce inconsistent design and claims. Email and spreadsheets hide status. Replatforming an established fleet creates a programme of work when the immediate need is controlled change.
Why this is the same product. It is the agency handoff at portfolio scale. Central marketing or the agency defines a Charter and reusable Blueprints. Local teams use Edit for bounded facts. Campaigns and sensitive claims use Studio, approval, and scheduled release. Each publish still ends in public verification and remains reversible.
Specific value. More accurate local pages; fewer central tickets; brand consistency; visible location-level history; repeatable campaign production; and no fleet migration as a condition of adoption.
What must exist before broad selling. Portfolio overview, dependable multi-seat roles, policy inheritance with local exceptions, Blueprint maturity, bulk status, and an approval queue. These buyers should enter discovery and limited design partnerships now so those capabilities are built from evidence, not imagination.
Lead with. Let locations keep their sites current. Keep brand rules, proof, and undo at the centre.
Do not lead with. Rebuild the fleet, headless architecture, a new CMS, or AI that “runs every location.”
Buying motion. Design partner first; then an annual portfolio agreement with a bounded pilot across a small set of representative locations. Keep the agency of record inside the operating model where one exists.
Who they are. Trade associations, professional societies, chambers, clubs, galleries, churches, member networks, and similar organisations with a trusted public site and recurring structured communications. A small staff or volunteers know the material; a part-time web person or agency controls publication; officers may approve it.
Buying trigger. Last month’s events are still live; a directory, programme, notice, or exhibition list is rebuilt by hand each cycle; spreadsheets and email have become the actual content system; or a wrong date/name has already embarrassed the organisation.
Job to be done. “Turn the material we already collect into this month’s approved web and print output, then publish it onto the site members already use—without a migration and without changing a critical fact by accident.”
Why the current choices fail. The web person becomes a bottleneck. Volunteers receive broad WordPress access. Repeated copy/paste creates factual drift. Specialist membership platforms ask the organisation to replace far more than the publishing workflow it needs to fix.
Why this is the same product. Studio is the production desk: sources → collections → records with provenance → artifacts → approval → publish through the same safe adapters. Edit handles one-off corrections. Verification, bounds, and rollback protect an exhibition date or member notice exactly as they protect opening hours.
Specific value. One source for recurring records; fewer copy/paste errors; clear approval; reusable web/print/social artifacts; continuity across staff and volunteer turnover; and publication onto the established member destination.
What must exist before broad selling. One proven Studio workflow, comprehensible source handling, fact locking, approval, reusable artifact templates, and a reliable bridge to the live site. Start with a narrow design-partner use case rather than promising “all associations.”
Lead with. Produce recurring updates privately, approve them clearly, and publish them onto the site members already know.
Do not lead with. Chatting with a website, membership administration, dues, community features, or a platform migration.
Buying motion. A paid or tightly scoped design partnership around one recurring output—events, exhibitions, member offers, programmes, or directories—often with the original agency still involved.
| Audience | Time benefit | Risk benefit | Organisational benefit |
|---|---|---|---|
| Independent owner | No queue for routine facts | Verified change and undo | Less dependence on one specialist |
| Agency / freelancer | Fewer low-margin tickets | Bounded access and an audit trail | Better handoff and partner revenue |
| Multi-site marketer | Local updates without central retyping | Brand policy, approval, and rollback | One operating model across the portfolio |
| Membership organisation | Reusable recurring production | Fact provenance and explicit approval | Continuity across staff, boards, and volunteers |
Newsrooms, PRs, and comms teams. They do not buy an editor. They buy safe, reversible, attributed change when a statement must go live on a property they do not fully control. Same verification story; different buyer language. Do not lead GTM here.
Public sector / municipalities. High need for undo and audit; slow procurement. Same rights-and-safety promise. Do not sell it as a first-class vertical until Edit self-serve is proven.
Channel split (decided 2026-08-15): the website and broad online marketing speak to owners/end users first, with an easily accessible agency surface one click away. Outbound sales and direct marketing effort focus mainly on agencies and freelancers — one agency sale brings a portfolio of sites, the agency holds the credentials (removing the hardest onboarding step), and absorbs first-line support.
Agency symbiosis (unchanged):
The name must:
.com (and .se when cheap), or an unused name we already own that is not already a person, a mushroom, or another product.All pricing is stated and marketed in USD (English-first GTM). SEK/EUR appear only as localized display equivalents at checkout, never as the source figures.
| Package | Contents | List price direct (USD/mo) | Partner price (approx.) |
|---|---|---|---|
| SiteCharter Edit | Base editing, verification, history | $49–59 | $29–39 |
| SiteCharter Studio | Edit + Studio module | $79–89 | $49–69 |
Pricing is a hypothesis and must be validated.
LLM-assisted handling of other sites where access exists. Higher cost, clear “best effort” communication, strict write limits, mandatory backup.
Deep integration with heavily locked platforms (e.g. Shopify, Wix, Squarespace) as first-class.
Mutations primarily via files and documented high-level APIs. Raw SQL write is avoided as the default path.
Requirement: Self-serve from the start (the process must not require manual work per customer from the team).
Three decisions (2026-08-15) shape the flow:
Flow in brief:
During development and early pilots the team may onboard manually to learn, but the goal is to productize that away.
The system guarantees:
Boundaries, backup, verification, no silent publish on failure, history and restore capability within documented limits.
The system is best effort on:
Generic connector, complex/unusual structures, environments outside our control (cache, CDN, plugins, server configuration).
Responsibility:
The customer/agency is responsible for access credentials and for content they approve. SiteCharter is responsible for the tool behaving according to the documented safety and verification rules.
There is no commercial-proof gate or milestone (removed 2026-08-15): build, sales, and marketing all proceed in parallel. Steer with the operational metrics and funnel below, not with a threshold.
Studio is developed as a named module with its own bounded context but shared identity, project context, brand knowledge, audit, and publishing adapters.
Early delivery direction:
Detailed specification lives in a separate Studio document.
Connector expansion should be justifiable by usage or willingness to pay; nothing else is revenue-gated.
The doc set is split across two repos — know where the canonical copy lives:
site-editor repo (github.com/cgoberg/site-editor, checked out at /opt/site-editor), alongside the code. The forge repo's platform/site-editor/ exposes them via symlinks.platform/site-editor/.Document status: This is the collected strategic foundation. It does not replace the original technical plans; it summarizes and steers them according to the decisions that have been made. §4 (audiences, jobs, benefits) was expanded 2026-08-14 so branding can be judged against all four buyers, not only the first-wave pair.
Version: 0.3
Date: 2026-08-14
Status: Locked product name + brand system
Product name: SiteCharter
Belongs to: VISION.md
This is the reference for how SiteCharter is named, positioned, spoken about, felt, and brought to market. It follows the audience, role, benefit, and buying-motion expansion in VISION.md §4.
Exact marketing-site copy, a finished logo file, and a component library come later. The name, the metaphor, the four-audience messaging, and the visual constraints are locked enough to build against.
SiteCharter
Pronunciation: SITE-char-ter. The words are ordinary English. Swedish speakers can use the English pronunciation; the spelling never changes.
| Part | Familiar meaning | Product meaning |
|---|---|---|
| Site | The website already owned or delivered | The existing live property remains the destination |
| Charter | A grant of rights with stated rules and responsibilities | Who may change what, how publication is checked, and how it can be reversed |
One sentence: every site gets a clear Charter for safe change.
SiteCharter names the mechanism that makes autonomy responsible. It is not a promise that a model will always be right. It is a promise that authority is defined and that publication follows known safeguards.
It passes the strategic tests:
.com is available at a normal registration price; the .se, .io, .app, and .net also returned available (see §11).| Room | The Charter answers |
|---|---|
| Independent owner | What can I change safely on the site I already paid for? |
| Agency / freelancer | What can the client change without broad CMS or server access? |
| In-house / franchise | What may locations update locally, and what still needs central approval? |
| Membership organisation | Which facts, records, artifacts, and approvals govern each recurring publish? |
sitecharta.com is available) and hard to enforce. This raises, not lowers, the priority of the professional trademark search.Category descriptor: Safe editing and content production for the site you already have.
Brand line:
Change what needs changing. Keep what matters safe.
Operating promise: The people closest to the facts can act. The responsible party defines the Charter. SiteCharter verifies the public result and keeps a way back.
For people responsible for a website that already exists—business owners, the agencies who delivered it, in-house marketers at multi-site operators, and membership organisations—SiteCharter is the safe editing and content-production layer that lets the people closest to the facts make allowed changes and prepare structured material, while defined authority, public verification, history, and restore remain in place.
Unlike general AI agents, platform-locked builders, and broad maintenance access, SiteCharter works on the site already delivered or owned. It makes controlled change possible without making migration the price of autonomy.
Keep the site No rebuild or migration. WordPress and file-based/static sites first.
Define the Charter Give named people useful authority without giving them broad access.
Prove the change Back up, publish through bounded operations, verify the public result, record it, and keep restore available.
| Against | SiteCharter stance |
|---|---|
| Frontman and other AI editors for existing sites | They lead with “click and tell AI.” We lead with bounds, public verification, and undo. Frontman’s WordPress plugin can run in production as experimental software; its JS-framework path is development-only and ends in a git diff. We sell a safety model on the live site, plus Studio for structured recurring work. Do not start a feature war on “AI.” Start on what is allowed, what was proven live, and what can be reversed. |
| General AI agents / coding agents | Bounded, named operations, project-scoped identity — not a free agent on the server. |
| Platform-locked builders (Wix, Squarespace, Shopify-as-CMS, Webflow as a destination) | Works on the site you already have. No rebuild. |
| Traditional agency / freelancer retainers | Same safety, less waiting and less cost for routine changes. The retainer can become oversight, not typing. |
| Giving the client wp-admin or SFTP | Autonomy without the keys. |
| “Just migrate the fleet to a new CMS” | The fleet already exists. SiteCharter sits on it. |
| Association / membership platforms | We are not a dues, login, or community product. We publish approved member material onto the site they already have. |
Frontman is the closest product collision in the “edit the site you already have” category. The public difference is not “we also use a model.” The public difference is custody: allowlists, backup, public verification, rollback, audit, workspace ownership, and Studio.
Personality:
Calm · Capable · Protective · Plain-spoken · Handoff-friendly
Voice rules:
Good:
“The location changes Saturday hours. Brand sees exactly what went live and can undo it in one click.”
Bad:
“AI transforms how your customers interact with their website in real time.”
Also bad:
“Our autonomous agent can transform any website instantly.” (unbounded, unprovable, and builder-coded)
Change what needs changing. Keep what matters safe.
Always pair the brand line with the category descriptor until the name is recognised:
Safe editing and content production for the site you already have.
Keep the site you already have No rebuild, new CMS, or parallel destination. Work on the live property already owned or delivered.
Give people useful, defined authority Hours, offers, photos, event lists, and recurring records—inside named operations, paths, roles, and approvals.
Prove what reached the public site Backup, public verification, history, and restore. A successful API response is not treated as a successful publish.
Produce recurring work before it goes live Studio separates sources, critical facts, editorial treatment, artifacts, review, and explicit publication.
15 seconds (English):
“SiteCharter is the safe editing layer for a website that already exists. The people closest to the facts can make allowed changes, while the person responsible for the site keeps verification, history, and undo.”
15 seconds (Swedish):
“SiteCharter är ett säkert redigeringslager för en sajt som redan finns. De som står närmast informationen kan göra tillåtna ändringar, medan den som ansvarar för sajten behåller verifiering, historik och möjlighet att ångra.”
Agency variant:
“Let clients handle routine updates on the site you delivered. You define what they can change and keep proof and undo.”
In-house / franchise variant:
“Let locations correct local facts. Central marketing defines the Charter. Every publish is checked on the live site and can be reversed.”
Membership variant:
“Turn recurring source material into approved updates and artifacts, then publish them onto the site members already use.”
Use the first as the brand line and the second as the early category line.
Do not use an agency-only autonomy/control line as the umbrella tagline. It excludes owners who hold both roles and weakens the multi-site and membership story.
Jobs, benefits, and “do not say” lists live in VISION.md §4. This section is the brand application.
Headline job: Update the site I already paid for, today, without breaking it.
Lead: “Update the site you already have, without waiting for every small change. Verified and reversible.”
Proof points: live overlay, draft → verifying → published, one-click undo, your URL.
Avoid: agency, blueprints, portfolio, handoff, AI.
Headline job: Stop being a copy-change helpdesk without giving away wp-admin.
Lead: “Give clients room to update. Keep the safeguards you are responsible for.”
Proof points: path bounds, named operations, audit, rollback, Blueprints, clean exit (workspace belongs to the site).
Avoid: “we replace your retainer.” Frame a better retainer, or a way to end the bad ones without abandoning the client.
Headline job: Local freshness without brand drift, with undo.
Lead: “Let locations keep their sites current. Keep brand rules, proof, and undo at the centre.”
Proof points: inherited Charter with local exceptions, many local Edit users, Studio + approval for campaigns, portfolio status.
Avoid: rebuild the fleet, headless, “AI manages all your locations.”
Brand note: Do not invent a “SiteCharter Franchise” product. Same product, portfolio terms.
Headline job: Recurring structured updates onto the site members already know.
Lead: “Approved member updates, on the site you already have.”
Proof points: Studio sources → records → approval → verified publish; provenance on dates and names.
Avoid: overlay-first “chat with your website”; association-management (dues, member logins).
Brand note: Do not invent a “SiteCharter Members” product. Studio is the surface.
Acquisition starts with owners and agencies while narrow design partnerships begin in the adjacent audiences. In-house and membership are why the name and slogan cannot be agency-only. Messaging must not undercut agencies that resell or recommend SiteCharter—including when a franchise or association still has an agency of record.
Calm editorial infrastructure: precise enough for the responsible party, approachable enough for the person changing Saturday’s hours. The system should feel placed beside the existing site, never as if it is trying to replace it.
The picture in the head is a proofing desk beside a live shopfront: the source material, the proposed change, the public result, and the record of what happened are all legible.
Exact palette, typefaces, and logo files are the next visual deliverable.
These apply across Edit, Studio, onboarding, and marketing.
Hybrid:
Agencies should prefer to be associated with SiteCharter, not competed against by it.
| Name | Use |
|---|---|
| SiteCharter | Product umbrella |
| SiteCharter Edit | Base editing capability |
| SiteCharter Studio | Named production module |
| Charter | The workspace policy and responsibility model inside a site; never the public product shorthand |
| Agency Blueprints | Reusable templates inside Studio (keep this descriptive; do not brand it as a fourth product) |
Avoid fragmenting into many public product names early.
Internal repo and service names (site-editor, atelje.log) can stay until a deliberate implementation rename pass. Customer-visible surfaces should move together after the domain is registered and the mark passes legal screening.
| Domain | Status (verified 2026-08-14) | Evidence | Action |
|---|---|---|---|
| sitecharter.com | REGISTERED — ours | Registered 2026-08-14 01:37:50Z at Porkbun; confirmed by Verisign RDAP and Porkbun domain/listAll |
Canonical brand domain; nothing further needed |
| sitecharter.se | REGISTERED — ours | Created 2026-08-14 at Loopia (LOOPIA_CGSE_API_USER); confirmed by IIS whois and Loopia getDomains |
Swedish-market match secured |
| sitecharter.io | Available | Exact technical-market defensive name | Do not register; not needed |
| sitecharter.app | Available | Exact application defensive name | Do not register; not needed |
| sitecharter.net | Available | Exact fallback | Do not register; not needed |
The .com and .se were registered during this naming pass (the earlier draft of this
section incorrectly stated that no domain had been registered — it was written ~1h37m
after the .com registration). The alternate candidate tendhold.com and
tendhold.se are also owned, registered 2026-08-13. See
NAMING-REVIEW-2026-08-14.md for the head-to-head evaluation and the conditions under
which Tendhold would replace SiteCharter.
Fresh authenticated inventory returned 22 Porkbun domains and seven domains across the two working Loopia API accounts. Domains belonging to live products, clients, family, and personal sites were excluded. Names explicitly excluded from this fresh naming pass were treated as inventory only, not as candidates.
| Name | Why not |
|---|---|
| carveapex.com | Unused, but aggressive and optimisation-coded; it contradicts calm custody and safe delegation. |
| reskraft.se | Unused Swedish name; not English-first and not a fit for the website category. |
| Mushroom-related parked inventory | Memorable but categorically wrong and likely to import unrelated search meaning. |
No unused owned name admitted to the fresh candidate slate was stronger than the best registerable exact .com.
This pass began after the four-audience venture brief was expanded. Earlier naming conclusions were not used as candidates, evidence, or tie-breakers.
.com available, or is a genuinely suitable unused owned name..com availabilityScores are relative (1 weak, 5 strong). Domain results are successful Loopia replies from 2026-08-14, not inferred from DNS.
| Candidate | Strategic meaning | Four-audience range | Trust | Say / spell | Distinction | Exact .com |
Total / 30 |
|---|---|---|---|---|---|---|---|
| SiteCharter | 5 | 5 | 5 | 4 | 4 | 5 | 28 |
| SiteRemit | 5 | 5 | 3 | 4 | 4 | 5 | 26 |
| SiteLeeway | 4 | 5 | 2 | 5 | 4 | 5 | 25 |
| Amendwise | 4 | 3 | 4 | 4 | 4 | 5 | 24 |
| EditAttest | 4 | 3 | 5 | 3 | 4 | 5 | 24 |
| EditPact | 3 | 3 | 4 | 5 | 4 | 5 | 24 |
| Candidate | Reason |
|---|---|
| SiteRemit | “Remit” has the exact bounded-authority meaning in British English, but money-transfer meaning is prominent in US English and can imply sending or moving rather than staying on the existing site. |
| SiteLeeway | Expresses autonomy clearly, but “leeway” can sound like looseness, tolerance, or drift—the wrong emotional cue for the responsible party. |
| Amendwise | Friendly and safety-oriented, but document/legal amendment associations narrow the category and “wise” is a common naming suffix. |
| EditAttest | Strong on proof, weak on autonomy and existing-site continuity; EditAttest Edit is redundant and Studio becomes secondary. |
| EditPact | Easy to say and implies an agreement, but it reads as a feature brand and does not explain the site-level operating model. |
.com as available and non-premium.SiteCharter wins because it makes the product architecture legible. The product does not merely let someone edit: it grants useful authority over an existing site under explicit rules, verifies the result, and preserves accountability and reversal. That idea survives every audience and expands naturally from Edit into Studio and portfolio governance.
Document status: Name and strategic brand platform locked. Sufficient to guide registration, messaging, early UI tone, and market narrative. Trademark clearance and visual identity production remain explicit next steps.
Product name: SiteCharter (locked 2026-08-14; rationale and domain evidence in BRAND.md — canonical in the forge repo, platform/site-editor/)
Date: 2026-08-15
Status: Living current-state document
This README describes what exists today, what is proven, and where the project stands.
Strategic direction lives in VISION.md. Studio specification lives in STUDIO.md. Brand and GTM live in BRAND.md. Technical implementation detail lives in PLAN.md.
SiteCharter is a safe editing and production layer for existing websites.
Core promise:
Change what needs changing. Keep what matters safe.
(The earlier "Client autonomy. Agency control." line is retired as umbrella copy — BRAND.md §5.4 rules out agency-only framing at the brand level; it survives as the agency-variant pitch.)
Works on the site the customer already has. No migration to a new platform required.
| Document | Role |
|---|---|
| VISION.md | Strategy, packaging, GTM, ownership, roadmap principles |
| STUDIO.md | Detailed Studio specification for development |
| BRAND.md | Positioning, voice, visual direction, UX principles, go-to-market |
| PLAN.md | Technical architecture, adapters, threat model, implementation plans |
| README.md | This file – current state and practical orientation |
Real non-founder usage has been demonstrated on live sites (including static and WordPress properties).
Change volume and operator experience have been exercised in production-like conditions.
Automated tests exist at multiple levels (unit and adapter-oriented). Exact counts and site lists should be kept current in operational notes / PLAN.md.
Treat production evidence as pilot-grade: real, but concentrated in few users so far.
Safety-critical (must fix — tracked in PLAN.md §4.4, top of backlog):
--permission-mode default + disallowed-tools list, so a user-level bypassPermissions setting can let the model use Bash around the adapter bounds. The "named operations only" guarantee is not currently enforced end-to-end. (RUNBOOK "Phase 1 close gates", incidents-sandbox #1.)transport: rest covers files only — no database export — so post/option/media changes are not restorable from Layer-2. Fix arrives with the connector plugin's DB-export endpoint; until then the restore promise must be honestly scoped per transport in the UI.flush_endpoint; same plugin closes this.Product gaps:
Studio is fully specified in STUDIO.md and positioned in VISION.md as a named module, not a separate product and not an invisible merge into Edit.
Current status: Design and specification complete for early slices. Build proceeds now, in parallel with Edit hardening (decided 2026-08-15). Slice 0 implements the full nine-entity domain model from the start to avoid later rework.
Early delivery intent:
Studio shares identity, workspace/project context, brand knowledge, audit, and destination adapters with Edit.
Customer browser
└─ Overlay (Edit) or full-page app (Studio)
└─ Backend (API, auth, jobs, audit)
├─ Site adapters (WordPress, static/files, later others)
├─ Private Studio storage
├─ LLM tool layer (bounded / MCP-style operations)
└─ Verification against public URLs
First-class connectors (priority):
Generic path: LLM-assisted best-effort for other stacks where access exists, with strict write limits and mandatory backup.
Explicitly not first-class early: Shopify, Wix, Squarespace deep integrations.
Details: PLAN.md and VISION.md §6.
Responsibility boundaries are defined in VISION.md §9.
| Package | Contents | Intent |
|---|---|---|
| SiteCharter Edit | Safe live-site editing | Lower-cost base (~$49–59/mo list) |
| SiteCharter Studio | Edit + Studio module | Premium (~$79–89/mo list) |
All pricing is stated in USD; local currencies are display equivalents only. Pricing surfaces must anchor against what the product replaces (the $50–150 invoice-and-wait cycle per small change), and an annual plan (12 for the price of 10) keeps burst-editors subscribed through quiet months. Details: VISION.md §5; agency/partner pricing and affiliate model: VISION.md §5 and §4.
Pricing is hypothesis only until validated.
There is no commercial-proof gate or milestone (removed 2026-08-15): build, sales, and marketing proceed in parallel, steered by the operational metrics and funnel in VISION.md §11.
Two parallel tracks (see PLAN.md §15 for the full ordered backlog):
This file should stay short and factual. When reality changes, update the evidence and gap sections first.
Maintainer note: Keep README aligned with VISION. If strategy changes, change VISION first, then reflect here.
Version: 0.4
Date: 2026-08-15
Status: Development basis – authoritative product/architecture contract for Studio
Belongs to: VISION.md
Replaces: Previous standalone Studio proposal as the living definition
This document is the source of truth for SiteCharter Studio.
Appendices preserve useful detail from the earlier proposal without competing as a second product definition.
SiteCharter Studio is the named module for private, structured content production within SiteCharter.
Solves: Create, review, and publish more advanced or recurring material (posters, menus, listings, collections) without mixing it with direct site mutation.
Studio is:
Studio is not:
Short product statement:
Studio turns a customer's material and data sources into brand-consistent content for private review, export, or controlled publication.
| Aspect | SiteCharter Edit | SiteCharter Studio |
|---|---|---|
| Job | Direct mutation of the live site | Private production → review → artifact → publishing |
| Surface | Overlay on the public site | Full-page authenticated workspace |
| Storage | Site files / API | Private storage + provenance |
| Publishing | Immediate with verification | Explicit, scoped per destination |
Required bridges:
Site Editor changes structure, copy, and presentation.
Studio owns private source material, collections, production jobs, flows, previews, approvals, and outputs.
Destination adapters transfer approved Studio content into website sections, CMS fields, files, or external systems.
A recipe/module declares its mode.
One-off or campaign production.
Human (or seed) fills records → review → artifacts → publishing/export.
Recurring sync from a Source.
Runs create/update records idempotently. Conflicts and critical-fact deviations are stopped for review.
Source seeds the base material. Humans complete, enrich, and approve before publishing.
Linked to site/project (same as Edit). Holds Studio data for that site.
| Attribute | Description |
|---|---|
| id | UUID |
| workspace_id | |
| type | manual | spreadsheet_template | rss | calendar | api (later) |
| config | Type-specific configuration (URL, mapping, credentials-ref) |
| status | active | paused | error |
| last_run_at | |
| identity_field | Stable source identity field when applicable |
| removal_policy | mark_removed | archive | ignore | … |
| Attribute | Description |
|---|---|
| id | UUID |
| workspace_id | |
| original_path | Private storage |
| mime_type | |
| checksum | |
| rights_status | known | unknown | restricted |
| rights_note | |
| source_provenance | Where the asset came from |
| derivatives | Generated variants (size, format, path) |
| Attribute | Description |
|---|---|
| id | UUID |
| workspace_id | |
| blueprint_id | Nullable |
| name | |
| schema_version | |
| field_definitions | Schema for records |
| Attribute | Description |
|---|---|
| id | UUID |
| collection_id | |
| external_key | Idempotency key from source (nullable) |
| status | draft | in_review | approved | published | archived | removed |
| fields | Map of field values |
| provenance | Per-field or record-level |
| last_run_id |
| Attribute | Description |
|---|---|
| key | |
| value | |
| field_class | critical_fact | editorial | computed | asset_ref | controlled |
| owner | source | user | agency | system |
| review_status | ok | needs_review | rejected | confirmed |
| confidence | Optional |
| provenance | source/run/user/timestamp/location |
| Attribute | Description |
|---|---|
| id | |
| workspace_id / blueprint_id | |
| mode | production | flow | hybrid |
| source_ids | |
| mapping | Source → field mapping |
| filters | |
| enrichment_rules | |
| approval_policy | |
| destination_bindings | |
| schedule | Nullable (for flow) |
| Attribute | Description |
|---|---|
| id | |
| record_ids / collection_scope | |
| type | web_fragment | pdf | social_set | package |
| path | Private storage |
| template_id | |
| status | rendering | ready | failed |
| provenance | run_id, template_version |
| Attribute | Description |
|---|---|
| id | |
| artifact_id / record_id | |
| destination | Adapter + target |
| status | pending | planned | applied | verified | failed | rolled_back |
| verification_result | |
| approved_by | |
| published_at |
| Attribute | Description |
|---|---|
| id | |
| recipe_id | |
| trigger | manual | schedule | source_event |
| status | running | completed | failed | partial |
| started_at / finished_at | |
| summary | Counts of created/updated/conflicts |
| Attribute | Description |
|---|---|
| id | |
| scope_type | record | artifact | publication |
| scope_id | |
| requested_by | |
| approver_role | owner | agency | senior |
| status | pending | approved | rejected |
| note | |
| decided_at |
Supporting concepts: View, Template, Enrichment, Publication binding (durable link between Studio record and remote representation).
| Class | Rule |
|---|---|
| critical_fact | Must not be silently overwritten by AI or source on conflict. Stop for review. |
| editorial | AI may propose. Human approves before publish if policy requires. |
| controlled | Selected from a defined vocabulary. |
| computed | System may recompute. Tracked. |
| asset_ref | Must point to an asset with valid rights_status for the intended destination. |
Ownership policies (per field or blueprint default) control who may change a value after the first write.
Conflict policies: source wins / Studio wins / newest wins / stop and request review (default for critical facts).
Failure to verify when publishing to the web follows Edit discipline: no silent successful publish.
id: menu-weekly
mode: flow
source: spreadsheet_main
collection: menu_items
mapping:
external_key: sku
fields:
name: col_name
price: col_price # critical_fact
allergens: col_allergens # critical_fact
description: col_desc # editorial
filters:
- field: available
eq: true
approval_policy:
critical_fact_conflict: stop
publish_requires: agency_or_owner
destinations:
- type: web_section
target: menu_page
schedule: "0 6 * * 1"
Storage format is an implementation choice; the logical contract must be supported.
Blueprint = reusable definition instantiable in multiple workspaces.
Contains:
Rules:
Requirement: Usable before Gate E.
Tied to record, artifact, or publication. Approving a web preview does not auto-approve print or social.
in_review / approval pendingv1 may be simple (status + notification + permission check).
Allowed early:
manualspreadsheet_template (documented template)rss / atomcalendar variantPrinciple: No broad “connect any database/API” programme until a concrete paying case exists.
AI may propose mappings during setup; the approved mapping becomes versioned deterministic config.
web_fragmentpdf (realistic print requirements when claimed)social_setpackage (zip/manifest + provenance summary)Same adapter thinking as Edit: plan → apply → verify → (rollback)
Early priority: web via existing site adapters + export/package.
Later: direct social API publishing (not a core early requirement).
external_keyPer source/collection:
mark_removed (recommended default)archiveignoreCritical fact disagreement → needs_review; publish blocked until resolved.
Prove assets, multi-format, layout, print, approval, export.
See Appendix A for richer domain detail.
Critical facts (price, allergens/attributes), simpler recurring updates.
See Appendix B.
Later candidates: Property Listing, Podcast RSS flow — Appendix C–D.
Build timing (decided 2026-08-15): Studio is built now, in parallel with Edit hardening. Slice 0 implements the full §5 domain model (all nine core entities) from the start, to avoid reworking the model once real verticals exist. Slices remain the build order; the §16 gates measure validation, they do not grant permission to build.
DoD: Private storage per workspace; identity link; all nine §5 core entities; audit; Studio backup strategy.
DoD: Manual input + asset upload; field classes; template → artifact; approval; real user full cycle.
DoD: Critical facts respected; web publish via existing adapter; external user wants to continue.
DoD: Blueprint created and instantiated in two workspaces; agency approval end-to-end.
DoD: Spreadsheet or RSS → idempotent records; critical_fact conflict → needs_review; clear run status.
| Gate | Requirement |
|---|---|
| A | Slice 0 complete and stable |
| B | Slice 1 full cycle by a real user |
| C | Module used repeatedly / willingness to continue |
| D | Blueprint reused on >1 workspace |
| E | Clear willingness to pay linked to Studio |
Narrative validation detail from the earlier proposal is preserved in Appendix F as reference, not a second scoring system.
Suggested primary areas: Create, Collections, Flows, Appearance, Review, Export and publish.
unknown / restricted block public destinations until explicit approvalThese appendices are not a second product definition.
They provide domain depth, examples, and implementation hints for early modules and flows.
Templates react to artist count, artwork count, portrait availability, image orientation, title length, and medium.
Single-artist, three equal artists, and many artists without portraits need different layout contracts.
A-series print, pavement-sign format, Instagram portrait, square social, story, web image, PDF.
A calendar/spreadsheet can hold exhibition and booking records with field-level visibility (public / limited / private).
Confirming an exhibition can seed a private poster job with dates and artist names; the user adds artworks and portraits before generating and approving outputs.
Flowing typography and pagination; avoid bad section splits; keep name/price associated; consistent allergen notation; multi-language length changes.
Prices and allergens are critical facts. Missing/uncertain values block publication.
Need scheduled activation/expiry, cloning, temporary unavailability, version comparison, destination-specific publish state.
Lunch, dinner, drinks, takeaway, table card, window sign, digital display, mobile QR menu, website menu, social lunch image, PDF.
Website, PDF, and display should consume the same approved menu version.
Different property types expose different required fields.
Confirmed facts and sales text stay separate. AI may propose introduction text; it must not silently change area, fee, price, or viewing time.
Object page, prospectus, window sheet, social advert, carousel, story, email presentation, office display, viewing sheet, structured portal record.
Status transitions are explicit publish / update / unpublish / mark sold / archive actions.
Source fields: stable episode ID, title, description, pub date, audio URL, duration, artwork, episode/season, explicit flag, link, optional transcript.
Recipe sketch:
include published episodes
→ sort newest first
→ normalise source description
→ propose excerpt and topic tags
→ choose episode art or podcast fallback
→ create or update episode page
→ update episode index
Safe defaults:
Source owns identity, status, price, dimensions, viewings, agent, media refs.
include Upcoming and For sale
→ exclude internal and paused
→ sort by priority and publication date
→ group by location or type
→ create cards and detail pages
→ campaign artifacts only for selected records
Example status mapping:
Upcoming → upcoming section
For sale → active list
Sold → sold archive
Paused → unpublish
Archived → private only
modules/
├── exhibition-poster/
│ ├── module.yaml
│ ├── schema.json
│ ├── extraction-rules.md
│ ├── validation-rules.yaml
│ ├── workflows.yaml
│ ├── templates/
│ ├── output-presets.yaml
│ └── destination-mappings/
├── restaurant-menu/
└── property-listing/
Module owns domain schema, extraction guidance, field classes, validation, review stages, templates, output presets, domain destination mappings.
Core owns workspaces, sources, assets, provenance, collections, recipes, runs, versions, approvals, artifacts, destination contracts, audit.
studio_workspaces
studio_sources
studio_source_snapshots
studio_assets
studio_asset_derivatives
studio_collections
studio_records
studio_record_versions
studio_field_values
studio_recipes
studio_recipe_versions
studio_views
studio_templates
studio_artifacts
studio_destinations
studio_publication_bindings
studio_runs
studio_run_items
studio_approvals
Every row scoped to workspace/project. Credentials referenced via encrypted secret store, not inline.
candidate
identity confirmed
rights unknown
approved for web
approved for print
rejected
Discovered assets are never treated as customer-owned without explicit approval.
AI is well suited to: understanding unfamiliar material; proposing schema/mapping; extracting facts; classifying assets; drafting editorial text; proposing filters/recipes; explaining conflicts; suggesting templates; exploratory previews.
Deterministic code must own: recurring ingestion after mapping approval; stable identity/dedup; filters/sort/group/compute; validation; scheduling/retries; destination writes; audit/approval enforcement; routine render from approved templates; publication verification.
Use the gates in §16 as the operative gates.
The following narrative criteria from the earlier proposal remain useful acceptance checks:
Useful production result: real customer produces accepted package from real material; no premature publication; correction time recorded.
Repeatability: second job reuses template/schema/rules without rebuilding the workflow.
Cross-customer/domain: shared core used by a second workspace or module without domain conditionals contaminating the kernel.
Controlled recurring flow: stable IDs, idempotent runs, useful diffs, correct removal behavior, visible conflicts.
Commercial/operational repeatability: another customer can be configured, operated, supported, and billed with predictable effort.
Document status: v0.3 is the authoritative Studio specification. Appendices preserve domain depth and implementation hints from the earlier proposal without maintaining a second competing definition.
Verified 2026-08-14 by reading overlay.js (1909 lines), PLAN.md §6–§7, VISION.md §3,
BRAND.md §8. This supersedes the invented overlay in the first pass of the brand
directions, which depicted a small inline card with a typed instruction and a state strip.
That is not the product.
Read this before redrawing the product moment. Everything in §1 is observed in shipping code, not aspiration. §3 is planned and labelled as such.
A conversational side panel injected into the customer's own live site. Not an inline element editor, not a card, not a form.
min(520px, 96vw), full height. Non-covering — the backdrop is
panel-width with pointer-events: none, so the page stays readable and clickable
alongside it. This is deliberate and important: the site is not obscured by the tool.env(safe-area-inset-bottom) padding, 16px input to defeat iOS auto-zoom, 44–48px
touch targets. The lead buyer is often on a phone; this is not an afterthought.?forge URL param, or by
typing the word "forge" anywhere on the page.sessionStorage); the draft message survives too.p, em, strong, code).deploying / live). These are hidden by default and
revealed by dev mode.deployed / failed / muted), a 3-line summary, and metadata.↩ Undo, and a successful undo produces its own card: "The change
was undone / The page is back to how it was before the change."overlay.js:635 carries the comment:
/* Verified publication — bridge-owned, never model-authored */
Three parties speak inside one thread, and they do not have the same authority:
| Voice | Who | Authority | Today's treatment |
|---|---|---|---|
| Assistant | the model | fallible, may be wrong | rounded bubble, markdown |
| Operator | a human at Forge Nord | accountable, identified | left accent rule, "Message from support" tag, read receipts, can arrive as a notice when the panel is shut |
| Bridge | the system's own record | verified fact, structurally unforgeable by the model | the publication card and reveal notice |
This is the product's central trust claim rendered as UI. "A 200 response is not treated as a successful publish" is not marketing copy — the bridge fetches the public URL and only the bridge may say it went live. The model literally cannot author that card.
Any redraw must make these three voices visually distinct and must make the bridge's voice the one that looks least like chat. Solve this differently in each direction; do not skip it.
Per PLAN.md §7 and VISION.md §3.2. Depict as a credible near-future bridge, never as something that exists today.
review_status and provenance; the treatment wrapped around them does not.external_key idempotency; a conflict on a
critical fact stops the run and becomes needs_review rather than overwriting.The bridge to depict: how does something produced in Studio arrive on the live site, and how does the person in the overlay see that a block on this page is Studio-managed rather than freely editable?
Note (corrected 2026-08-15): STUDIO.md exists in the site-editor repo
(/opt/site-editor/STUDIO.md, github.com/cgoberg/site-editor) and is the authoritative
Studio specification — it simply had no symlink in the forge view when this file was
first written. It is now symlinked alongside PLAN.md. Studio is in build now (full
nine-entity model from Slice 0), per the 2026-08-15 decision.
These are real, observed, and fair game. Each direction should address at least two, and say which.
Keep all of these — they are the product, not decoration:
The shipping code brands itself "The Forge" with a ◆ mark and a gold-on-dark theme
(#c9a96e on #1a1714); the doc set (PLAN, README, STUDIO) was retitled to SiteCharter
on 2026-08-15. Under the locked brand this surface becomes SiteCharter Edit. Draw it as SiteCharter, in your
direction's own palette — not in the current gold-and-dark theme, which belongs to the
previous identity and is not a constraint on you.
Revision 2 — 2026-08-15. Updated for the upstream doc-set changes: channel split (VISION §4.11), USD pricing with anchor and annual plan (VISION §5), demo-before-credentials onboarding (VISION §7, PLAN §9), honestly-scoped restore (PLAN §4.4, README §3.4), and Studio in build (STUDIO.md v0.4).
Use this copy verbatim. Do not rewrite, improve, shorten, or re-order it. The point of holding copy constant is that C-G compares design, not writing. If a line does not fit your layout, change the layout.
Section order is fixed. Same order, same viewport behaviour, in all three directions.
Brand: SiteCharter
Links: How it works · What it costs · For agencies · Sign in
Button: See it run on your own site
Design requirement (VISION §4.11 channel split). The site speaks to owners first; the agency surface must be easily accessible but visibly secondary — one click away, never buried and never given equal weight to the owner path. Outbound sales targets agencies; the website does not. Solve this in your own idiom: a distinct treatment for the agency link, a secondary door in the footer, a differently-weighted nav item. Do not build a two-audience split hero.
H1: Change what needs changing. Keep what matters safe.
Deck: Safe editing and content production for the site you already have.
Body: Update the site you already paid for, without waiting for every small change. You watch it go from draft, to verified, to published — and you can undo it.
Primary CTA: See it run on your own site
CTA support line: No account. No credentials. Just your address.
Secondary CTA: See what happens on publish
Eyebrow: What this is built on
1 — Keep the site No rebuild, no migration, no second site that quietly becomes the real one. WordPress and file-based sites first.
2 — Define the Charter Named people get useful authority over named things. Hours, offers, photos, staff details — not the theme, not the database, not the server.
3 — Prove the change Back up first, publish through a bounded operation, check the public URL, record what was seen, and keep the way back open.
Eyebrow: What happens when you publish
This is a genuine ordered sequence, so numbering it is legitimate.
1. Defined access You connect the site once. The paths and operations you allow are named up front. Nothing outside them is reachable — including by us.
2. Backup Anything at risk is copied before it is touched. The copy is kept, not overwritten by the next change.
3. Bounded operation The change runs as a named operation — "update opening hours" — not as open access to the server.
4. Public verification We fetch your live URL and check what the public actually sees. A 200 response is not treated as a successful publish.
5. Restore Every change keeps a way back, and the return is verified too.
Required scoping line, visible in this section — not a footnote: How much a restore covers depends on how your site is connected. With the WordPress connector plugin it covers files and the database. Over SFTP it covers the files we touched. We tell you which one you have before you publish, not after.
Eyebrow: Try it first
Title: Watch it work on your own site. Before you trust us with anything.
Body: Type your web address. We fetch a copy of your own homepage and run a change on that copy — draft, verifying, published, undone — so you can see how it behaves before any password, plugin, or account exists. Nothing is written. Your real site is not touched.
Three steps:
1 Enter your address — no account needed.2 Watch a real change run on a copy of your own page.3 Decide then, not before, whether to connect.Connect options, shown as three plain routes:
Eyebrow: A worked example Required label (must be visible, not a tooltip): An illustration of the flow. Not a customer story.
Title: Tuesday, 08:40. The hours changed.
Body: The kitchen closes an hour earlier from this week. The person who knows that is standing in the kitchen. The person who can edit the site is not.
Timeline:
08:40 — Opens the site on her phone, taps the panel, types: "We now close at 20:00 on
weekdays."08:40 — Draft. The change is shown against the live page before anything is written.08:41 — Verifying. The page is backed up, the hours block is updated through a named
operation, and the public URL is fetched back.08:41 — Published. The line that went live is shown, exactly as a customer sees it.later — Can be undone. The previous version stays one click away.Closing line: No ticket. No wp-admin. No hoping.
Eyebrow: The panel, on a live page
Build this from PRODUCT-SURFACE.md, not from a description here. It is a conversational
side panel that does not cover the site, and a bottom sheet on phones. The three voices —
model, human operator, bridge — must stay distinguishable, and the bridge must remain the
only voice that can assert a change went live.
The mock site behind the overlay — a small bakery, rendered as a real page someone paid for, in a visual world clearly different from your own direction. It is the customer's site, not yours.
Required in the panel:
Draft · Verifying… · Published ·
Can be undoneMonday–Friday 07:00–21:00 → Monday–Friday 07:00–20:00Undo this changeEyebrow: What it costs
Required anchor, given visual prominence — this is the pricing argument, not a footnote: A single small change from an agency is typically a $50–150 invoice, plus days of waiting. One avoided ticket pays for the month.
Never price against website builders. The comparison is always the invoice-and-wait cycle.
SiteCharter Edit — $49–59/month Editing, verification, history, and restore on one site.
SiteCharter Studio — $79–89/month Everything in Edit, plus the private production space: sources, records, approval, artifacts.
Agencies and portfolios — from $29/site/month Shared bounds, Blueprints, roles, and portfolio status across many sites. Talk to us.
Required, shown as a real option and not a footnote: Annual: 12 months for the price of 10.
Required small print: Prices in USD. Local equivalents shown at checkout.
Product: How it works · What it costs · Studio · For agencies · Status Company: About · Writing · Contact Legal: Terms · Privacy · Data processing
Bottom line: SiteCharter — Forge Nord. Built in Sweden. English first, Swedish to follow.
Strapline under the wordmark: Safe editing and content production for the site you already have.
AI (as a lead or selling point), agent, magic, revolution, transform,
seamless, effortlessera, in any compoundCarl — the founder is C-G / Carl-Gustav ÖbergCharter used alone as the brandcommercial proof, or any framing that makes selling conditional on a validation
milestone — that gate was removed on 2026-08-15Client autonomy. Agency control. — retired umbrella line