A bookmark answers “where?” A reusable source card should also answer “which version did I open, what was supplied, and what is still unknown?”
I built a small browser-side Source Card Builder demo around that distinction. It is an original JavaScript form example, with no external libraries or server submission in the demo code.
1. Model observation separately from verification
A populated form is not evidence that a resource is reliable. The output therefore keeps three different categories:
- Observed metadata: title, source URL, page type and access date.
- Optional attribution: author/reviewer, edition/translator/version and the update date displayed on the page.
- Reader work: an open question that still needs investigation.
Missing attribution is serialized as JSON null. It is not replaced with the site owner's name, today's date or a plausible version. An access date describes my visit; it does not describe the publisher's last update.
The demo always emits resourceVerified: false. That field is a boundary, not a score: generating a card has not performed any source verification.
2. Parse an address, then apply your own acceptance policy
The URL constructor provides parsing. It does not decide which protocols your application intends to accept. The source-card form uses an absolute URL and then rejects unsupported schemes and embedded account credentials:
function readSourceUrl(raw) {
const url = new URL(raw.trim());
if (!['http:', 'https:'].includes(url.protocol) ||
url.username || url.password) {
throw new Error('Use HTTP/HTTPS without embedded credentials.');
}
return url.href;
}
This is input-policy enforcement. It does not prove that the destination exists, that it is safe to visit or that its content is accurate. The demo does not fetch the destination. If a future server fetches user-entered URLs, that introduces a separate security problem requiring its own safeguards.
3. Treat the exported card as text
The output is rendered using output.textContent = JSON.stringify(card, null, 2). User-entered titles and questions remain text rather than being inserted as HTML. MDN's textContent reference explains the relevant DOM behavior.
A nearby live status region reports validation errors and successful generation. Required titles are trimmed; access dates are required. Supplied dates must match an ISO calendar date rather than simply looking date-shaped. Optional fields remain visibly unknown when the reader has not checked them.
4. Keep example metadata honest across domains
The three presets illustrate different questions using projects I operate:
- A market-dashboard guide prompts a reader to distinguish score from quality.
- A health-calculator directory prompts a reader to inspect an individual tool's purpose and limitations. The card does not assess clinical suitability.
- A poet and author directory prompts a reader to record a specific text and edition next. An index is not an attribution certificate.
None of these presets supplies an invented author, edition or update date. The point is the form contract, not an endorsement of every page reachable from a directory.
5. State what was actually checked
Six browser checks passed for the published demo: each of the three presets produced the expected URL with missing attribution preserved; a JavaScript scheme, an address containing account credentials, and a blank title were rejected. These checks cover those interactions, not a complete accessibility or security audit.
The demo code has no persistent storage or outbound submission. Its hosting platform may have its own analytics. Enter public resource metadata only; keep personal health details, account secrets and private trading records out of the form.
Disclosure: I am Ali Gürtuna, creator of AGProLabs and operator of the linked projects. This article and the original demo were prepared with AI assistance and reviewed against the published interface. They are technical examples, not medical or trading recommendations.
Six destinations for a source-card practice set
Choose one resource from the projects I maintain. Enter only the metadata you observe on that destination: page title, page type and the date you accessed it. Leave author, reviewer, edition and update date unknown unless the page supplies them. These links are practice material for the form, not verified-source endorsements.
Market context and data readiness
- Global Stock Screening: Currency and Session Checks
- WARMUP and Missing Data in a TradingView Screener
Tool explanations
Author archives
An author archive is not an edition of every work it lists. A tool page is not a personal assessment. Keep the card’s resourceVerified: false boundary unless a separate verification process provides evidence. Resource examples prepared with AI assistance; no trading or medical instruction is implied.
Four additional author-archive reading routes
For an attribution exercise, record the archive title as observed and leave the edition of an individual poem unknown until you open and inspect that specific text. These are archives from my family literature project. The site operator and the author named in an archive are different metadata fields.
Choose one route; an archive heading alone does not verify the attribution, translation or edition of a work.
A page-type check before exporting
Try one page from these owner-maintained pairs. Record the page you actually opened; do not copy an archive author or category name into a reviewer field.
- Workflow documentation: access and activation and tool buying checklist. Record the individual document title.
- Topic indexes: endocrinology and diabetes and dermatology. Record these as category pages, not as individual clinical articles.
- Author archives: Ahmet Hamdi Tanpınar and Ahmet Muhip Dıranas. An author archive does not establish an edition or translator.
Keep resourceVerified: false; this is a manual metadata exercise, not an additional automated test result.
A small page-type fixture table
The same form should preserve the difference between a product, an index, a policy and a review. These pages from projects I maintain provide a compact manual practice set. Choose one row and enter the title actually displayed on that page.
| Example destination | Page type to record | Metadata boundary |
|---|---|---|
| Crypto Setup Planner product page | Product description | Do not infer the running script version from a product title. |
| Dynamic Channels Elite product page | Product description | Keep the product name separate from the author or reviewer field. |
| AGProLabs pricing page | Commercial information | The access date records your visit; it is not a price guarantee. |
| AGProLabs workflow directory | Workflow index | Record the index as its own source before following a listed workflow. |
| Editorial principles | Editorial policy | A policy explains the publishing process; it does not verify an individual article. |
| Medical-content boundaries | Scope statement | A scope statement is not a personal health assessment. |
| Çelo work review | Literary commentary | The author of the discussed work and the writer of a review are separate fields. |
| Yılkı Atı work review | Literary commentary | A review page does not establish the edition or translator of the original book. |
After exporting, compare the saved sourceUrl, page type and observed title with your inputs. Leave attribution, version and update date unknown unless the destination supplies them. Keep resourceVerified: false: this table adds manual exercises, not new automated test results or medical or trading recommendations.
Top comments (0)