Developers
Build with PTR
The PTR API and SDK are a product, and access to them is arranged under an enterprise agreement. So the first step is a conversation rather than a signup form. What follows is what the agreement provides, and what this site already hands any developer without one.
What the agreement provides
Access to the PTR API and SDK is granted under an enterprise agreement, arranged by getting in touch through the form on this page. Where a build touches a real person's likeness or voice, consent and oversight are settled in the agreement, which is the same position the digital twins page takes.
Hosting for the application and its database is recorded as deployed in an Australian region in the Subprocessors and Data Locations register, which sets out every other category of processing by function and region class. The governance page is the reviewer-facing version of all of that.
Open on this site
The parts that need no agreement at all
The twin widget on this page, and the machine-readable copies of the site itself, are served to anyone. They are the fastest way to see the shape of the thing before a conversation about the rest.
The twin widget, as a custom element
A script tag and an element. This page loads it the same way, so the markup below is the markup in the bytes you are reading.
<script src="https://ptr-digital-twin-widget.web.app/ptr-digital-twin.js" defer></script>
<ptr-digital-twin twin="simon" source="corporate"></ptr-digital-twin>twin names the twin and source names the surface it was opened from. The loader that mounts it here is public/Didymo.dc.html, readable in this page's own source, and it sets those attributes plus a launcher mode and the anchor the panel opens against.
Opening a rail from your own interface
Window events drive it, so your button stays your button. This site's own navigation dispatches didymo-toggle, and other pages dispatch didymo-open directly for a specific action.
window.dispatchEvent(new CustomEvent('didymo-open', { detail: { action: 'chat' } }));
window.dispatchEvent(new CustomEvent('didymo-toggle'));The action accepts chat, voice, avatar or book. An event with no detail opens the rail rather than a specific panel, and the shipped widget answers the URL hashes #didymo and #didymo-chat the same way.
A site an agent can read without parsing it
Each route here is published as HTML, as a Markdown alternate at the same path, and inside a whole-site digest. The Markdown is an alternate representation rather than a second canonical page, so it is linked from the head and kept out of the sitemap on purpose.
https://peopletechrevolution.com/llms.txt the route catalogue
https://peopletechrevolution.com/llms-full.txt every page's words, combined
https://peopletechrevolution.com/sitemap.xml the indexable documents
<link rel="alternate" type="text/markdown" href="https://peopletechrevolution.com/developers.md">The structured data on each page is a JSON-LD @graph carrying Organization, WebSite and BreadcrumbList, with Service, VideoObject and ScholarlyArticle nodes where the page has them. A tool in the repository submits changed routes to IndexNow.
A legal library with a checksum
The privacy policy and the terms are versioned documents, and the site's own build carries a manifest of them: for each one a document identifier, a version, an effective date, a SHA-256 of its text and its canonical address. That is what lets a reviewer pin the exact text they assessed.
"PTR-PRIVACY": {
"version": "...",
"sha256": "...",
"effective_date": "...",
"title": "People Tech Revolution Privacy Policy",
"canonical_url": "https://legal.peopletechrevolution.com/privacy"
}The published documents live at legal.peopletechrevolution.com, and a new version replaces the old one at the same address.
How this site is built
The engineering underneath, in specifics
The decisions below are the ones a developer evaluating an integration actually wants, and each is visible in the bytes this site already serves.
Static hosting, and a page that reads with scripting off
This site is static files behind a hosting edge. Every route whose text is produced at runtime also ships a fallback captured from a real browser, and the runtime removes that fallback in the same frame it mounts the live tree. A crawler, or a reader with JavaScript disabled, therefore gets the whole page.
The marker around that fallback carries a SHA-256, and it is worth being exact about what the digest covers: it is a hash of the page's own component template, the templates of every component it imports, and the shared inputs those depend on. It is not a hash of the captured markup. Change any of those inputs without recapturing and the build's own check demands a fresh capture.
<body>
<div data-prerender-static>
... the whole page, exactly as Chrome rendered it ...
</div>
<x-dc><template> ... the live component ... </template></x-dc>
</body>Grep any route on this domain for data-prerender-static and it is there in the served bytes, bracketed by the marker described above.
Panoramas, and the trap that sits under them
The 360 viewer reads its scenes from a manifest and mounts its renderer on the first click rather than on page load. Its full-page overlay pushes a history entry, which makes the hardware back gesture close the viewer instead of leaving the page.
One hosting behaviour is worth knowing before you deploy a sub-path build of your own: a clean URL served with no trailing slash resolves relative paths against the PARENT directory, so a module referenced as lib/app.js is fetched from one directory up and a catch-all rewrite can answer it with an unrelated document. Naming the document's own directory in the head removes that failure.
Standards
What we build against
Open specifications, each one linked to its own publisher so a reviewer can read the source rather than our summary of it.
Tell us what you would build
Say what your product does, who your users are, and where a PTR twin or scenario would sit inside it. Access to the API and SDK is granted under an enterprise agreement, and the form below is the way in.
