Research & Methodology
Research v2.0Version 2.0 · · Governance 2.0 public evidence surface
Governance 2.0 Overview
This page is part of the starnum public Governance 2.0 surface and uses the same evidence layer as the system card, data governance, transparency report, use policy, and security policy.
Governance Summary
This page documents the research operating model behind cultural interpretation, chart methodology, content quality, multilingual translation quality, and AI-assisted governance workflows.
Scope
Astrology-method notes, true-solar-time assumptions, knowledge-base and translation-memory lineage, AWR/TM quality gates, benchmark references, and public transparency artifacts.
Implementation Status
Version 2.0 turns the research page into a maintained evidence hub: claims point to machine-readable artifacts, while systems detect and agents decide whether content needs repair.
Editorial stance: We use the Lu Binzhao school as the primary analytical baseline and compare other schools objectively; school differences are not written as superior/inferior judgments, and test metrics are not written as astrological guarantees.
Update frequency: The research page is checked for update needs by the AI Ops gate. Article-style research is currently published mainly through human review or an AI agent; the archived candidate publisher lives at
scripts/archive/publish-research.js and must not be described as auto-scheduled until it is re-enabled · RSS
What This Page Actually Answers
Starnum's research page is not an academic journal or a marketing page. It is a public workbench explaining how we connect traditional astrology knowledge, chart calculation, AI-assisted writing, multilingual translation, AWR/TM scanning, and deployment gates. Readers should be able to tell here which judgments come from the astrology system, which are just engineering quality checks, and which still need further review by a human or an AI agent.
Every research claim is split into three layers: the first is cultural and astrological methodology, the second is data and tooling evidence, and the third is post-release verification results. Systems are only responsible for detecting, reporting, and preserving machine-readable evidence; whether to revise copy, retranslate, or adjust rules is decided by AI agents such as Codex/Claude.
| Research Layer | Input Evidence | What Can Be Disclosed | Boundaries to Preserve |
|---|---|---|---|
| Astrology methodology | School baselines, star/palace/Sihua conditions, knowledge-base sources. | Which analytical framework this site uses, and why different schools diverge. | School choice must not be written as the only orthodox approach, and astrological interpretation must not be written as scientific proof. |
| Engineering evidence | AWR, TM, schema audits, trust-page audits, deploy smoke tests. | Which gates pass, which data is degraded, which states remain a warning. | Scan results are not the final verdict; they only supply diagnostic material for AI agents. |
| Post-release verification | Cloudflare/R2 deployment records, HTTP 200 checks, sitemap/llms/OKF/schema verification. | Whether public pages can be read normally by users, search engines, and AI crawlers. | Secrets, internal permissions, exploitable attack-surface details, and private data are never disclosed. |
Current Research Tracks
Chart Calculation and True Solar Time
Documents birth-region handling, longitude correction, hour-boundary rules, and front-end display rules, so that "original birth time" and "true solar time" are never mixed into the same field.
Zi Wei Dou Shu Knowledge Modeling
Organizes school differences, Sihua rules, palace relationships, and impossible events, so articles, chart output, and the knowledge base all reference the same logical boundaries.
AWR/TM Multilingual Quality
AWR handles scanning and evidence retention, while TM handles translation memory and consistency; the two must not bounce work back and forth into a deadlock — the final arbiter is an AI agent.
AI Ops Release Evidence
Deployment, sitemap, llms.txt, OKF, schema.org, R2, Cloudflare cache, and smoke tests must all leave a traceable record.
Research Article Queue
data/research-topics.json stores candidate topics, sources, difficulty, and status; before formal publication, each item must pass the astrology-logic, content-safety, schema, and trust-page gates.
Public Page Maintenance
The research page itself is also subject to governance-page audits: source artifacts, verification commands, public claims, footer type sizing, and hreflang must never drift.
Research Evidence Specification
- Astrology methodology: Every astrological inference must be traceable to a school baseline, palace/star/Sihua conditions, and its uncertainty boundary.
- Translation quality: Multilingual pages must be checked against the zh-TW source text and classified as "needs full retranslation," "needs a partial patch," "an AWR false positive," or "TM terminology inconsistency."
- Public governance: Every public claim must link to
data/public-claim-registry.json, a public evidence manifest, or a re-runnable verification command. - Release verification: After a production deploy, the page must at minimum pass an HTTP smoke test, return 200 on key pages, have R2/Worker deployment records, cache purge, and a search-indexing submission.
Research Content Publication Rules
| Type | Can Be Published | Must Not Be Written As |
|---|---|---|
| Methodology | Chart-calculation assumptions, school choice, terminology definitions, system boundaries. | The one orthodox truth, absolutely accurate, unquestionable astrological conclusions. |
| Benchmark | Comparison against public governance frameworks such as OpenAI / Anthropic / Google Gemini. | A claim that a given model is used in production when there is no code or configuration evidence for it. |
| Multilingual quality | Listing translation-quality issues and repair strategies against the zh-TW source text as the baseline. | Automatically retranslating just because a scanner reported an error, or letting AWR/TM bounce work back and forth in a loop. |
| AI Ops | Recording detection, diagnosis, repair, verification, and deployment with machine-readable evidence. | Treating system scan results as the final verdict; final judgment is still carried out by an AI agent. |
Data Sources and Responsibility Boundaries
The research page uses only traceable internal data and public artifacts, and never presents an off-the-cuff judgment as fact. Each type of data has a clear responsibility: astrology data owns methodology boundaries, machine audits own state evidence, AWR/TM own multilingual-quality signals, and AI agents alone own final judgment and repair.
- Astrology and knowledge-base sources
docs/kb/zwds/,docs/kb/numerology/, and research articles define stars, palaces, Sihua, chart patterns, and numerology rules. This data can only support "method adoption" and "interpretation boundaries" — it must never be written as a scientific guarantee.- AI Ops and public evidence
data/public-claim-registry.json,data/public-evidence-manifest.json,data/trust-pages-machine-audit.json, and deployment records prove what the site currently discloses publicly, which gates it passes, and which states remain a warning or degraded.- AWR / TM multilingual governance
- AWR scans articles, pages, CSS, and untranslated residue; TM stores translation memory and terminology consistency. Both only produce routing and evidence — they never rewrite content directly. When the scanner and translation memory conflict, an AI agent decides based on the zh-TW source text, target-language fluency, and evidence severity.
- Front-end and release surfaces
- Front-end true solar time, region selection, font loading, footer consistency, schema.org, llms.txt, OKF, and sitemap are all release surfaces that gates can verify. Any copy change must avoid breaking indexing, accessibility, or cross-language hreflang.
- Research publishing tools
data/research-topics.jsonis the current queryable research topic pool; the legacy publisher lives atscripts/archive/publish-research.jsand is an archived candidate tool. Before it can be re-enabled it must be rewritten for the current routes (/research/zh-TWand/research/posts/...), the current sitemap/llms/OKF pipeline, and AI Ops result reporting — it must not be treated as an active schedule as-is.
AWR / TM Decision Matrix
| Scan Result | Priority Judgment | Repair Strategy | Evidence Output |
|---|---|---|---|
| zh-TW source has a format or tone issue | Fix the source first, since every other language must be checked against it. | A human or AI agent edits zh-TW, then regenerates the registry and translation queue. | AWR row, diff, article registry, format gate. |
| Target language has heavy Chinese residue | Usually needs a full retranslation, not a word-level patch. | Rebuild the article in that language from the zh-TW source, update TM, then let AWR rescan. | Translation repair queue, TM delta, language-ratio and sampling evidence. |
| Only schema / meta residue | Low risk; a structured-data patch is enough. | Fix JSON-LD, title, description, and OG/Twitter metadata without touching the body copy. | Schema audit, JSON-LD parse, public evidence manifest. |
| AWR reports an error but TM and the target language read naturally | Likely AWR rule noise. | An AI agent tags it as a false positive and adjusts the scanner rule or allowlist. | False-positive issue shard, scanner rule diff, regression test. |
True Solar Time Research Notes
Chart-time research currently displays "original birth time" and "true solar time" in separate fields: the original time preserves the user's input, and true solar time shows only the region and the corrected time, e.g. "Taichung 12:29." The page does not additionally display the correction in minutes, to avoid users misreading an engineering correction value as a chart conclusion.
Region selection derives its default range from the site language: Traditional Chinese shows Taiwan-region options, Japanese shows Japan-region options, Korean shows Korea-region options, Thai shows Thailand-region options, Indonesian shows Indonesia-region options, and Malay shows Malaysia, Singapore, and related regions; English and Spanish are primarily country selection, using the capital or a major city as the true-solar-time reference.
The research page does not claim that "every region is always correct." Accuracy depends on the front-end options, latitude/longitude data, time-zone data, true-solar-time calculation tests, and post-deploy smoke tests all being maintained together; where regions such as Malaysia, Taiwan, Luoyang, Beijing, or others have time-zone history or longitude discrepancies, this must be documented with test cases.
Claims We Do Not Currently Make
- We do not claim that astrological analysis has medical, legal, financial, or scientific predictive validity; content on this site is for self-exploration and learning reference only.
- We do not claim that AWR or TM can directly judge whether an article is good or bad; they can only flag suspicious spots and produce machine-readable evidence.
- We do not claim that OpenAI, Anthropic, or Google Gemini are all used for production inference; without code or configuration evidence, this can only be written as governance benchmarking.
- We do not claim that a multilingual translation is automatically natural just because it matches the zh-TW source word-for-word; the target language must still pass tone, terminology, cultural-fluency, and schema quality checks.
Research Queue and Ongoing Maintenance
The research article queue is managed by data/research-topics.json. The monthly publishing tool is currently still an archived candidate and must not be treated as an active automated schedule; before it is re-enabled, research articles should be drafted by an AI agent from the queue, reviewed by a human or an agent, passed through the gates, and then published. Priority topics fall into three categories: true-solar-time and region data, Zi Wei Dou Shu hard rules and school differences, and multilingual article-quality governance. After every publication, status must be written back, and AWR/TM must rescan the corresponding pages.
- Short term: Fill in true-solar-time region test cases, especially for Taiwan, Malaysia, Japan, Korea, Indonesia, Thailand, and Singapore.
- Medium term: Convert the AWR/TM multilingual decision matrix into machine-readable issue-routing rules, so full retranslation and partial patches don't get mixed together.
- Publishing tool: To restore
publish-research, it must first be rebuilt as a current-generation script: it must not write the oldresearch.html, must not append directly to sitemap/llms, and must go through the current public-discovery pipeline and structured reporting. - Long term: Bring the research page, system card, data governance, transparency report, FAQ, and article-publishing gate into a single AI Ops state machine.
Four Transformations in the Lu Binzhao School: Three Interpretations of the Wu, Geng, and Ren Stems
One of the most contested points in Zi Wei Dou Shu: on the Wu stem, does Youbi transform into Ke or does Tianji? On Geng, is it Taiyin or Tiantong? On Ren, is it Zuofu Lu or Tianliang Lu? The currently published research note is available only in Traditional Chinese.
GraphRAG Applied to an Astrology Knowledge Base: A Semantic Graph From Stars to Palaces
How we converted our 2,758 files and 1538K lines of astrology knowledge into a Neo4j graph (343 nodes / 679 relationships) and fused it with Qdrant vector search to build a three-layer evidence system for chart analysis.
117 Hard Rules for Astrology Logic: Boundary Definitions for Impossible Sihua Events
The biggest challenge in astrology AI is not generation capability — it is stopping the model from stating astrologically impossible events. This post explains how we define 117 hard rules (41 Four Transformations rules + 49 chart-pattern rules + 17 core-metric rules) with real examples.
Arrow Lines in the Numerology 3×3 Grid: Taiwanese vs. Pythagorean Traditions
The "3×3 grid numerology" popular in Taiwan and the Western Pythagorean system define Arrow Lines quite differently. This article lays out both calculation methods and explains which standard we chose — and why.
External standards and primary sources
These primary sources inform this page. They are benchmarks, not third-party endorsements of this site.
Current Machine Audit Snapshot
This block uses only traceable local audit data. No unsupported metrics or model claims are added.
- data/state-machine/i18n-parity.json: 8,036 parent URLs, 7,976 articles.
- data/kb-machine-audit.json: 3,238 source files, 0 missing coverage, 0 orphan chunks.
- data/discovery-surface-audit.json: 0 errors, 0 warnings.
- data/sla-report.json: critical / 3 critical, 1 warnings.
Content Maintenance And Update Decision
This block makes governance-page content machine-checkable: every page must disclose its source artifacts, related pages, and the gate that reports update needs.
Update Decision
This is not static copy. When source artifacts, related policies, public metrics, or generators change, AI Ops reports evidence and an AI agent decides whether the page needs edits.
Human Boundary
Systems detect, report, and preserve machine-readable evidence. Codex/Claude agents perform final judgment and repair.
Verification Command
node scripts/verify-trust-pages.js --check
data/state-machine/public-bench.jsondata/kb-machine-audit.jsondata/public-claim-registry.json- Related governance pages: methodology · benchmark · System Card · Transparency Report
- Update flow:
npm run update:trust-pages→npm run test:trust
Verifiable Evidence Layer
This block is not a narrative claim. Each core assertion has a claim id, source JSON, hash, and a repeatable verification command. Public pages disclose governance evidence without exposing source code, secrets, private data, or exploitable attack details.
| Claim ID | Verifiable value | Status | Owner | Source and verification |
|---|---|---|---|---|
| claim.public-url-manifest.indexable-count Public URL and canonical inventory |
39,104 indexable URLs | verified | sitewide | node scripts/generate-public-evidence-manifest.js --dry |
| claim.trust-pages.audit-pass-rate Trust page machine audit |
180/180 pass | verified | sitewide | node scripts/verify-trust-pages.js --check |
| claim.discovery-surface.zero-errors AI discovery surface audit |
{"errors":0,"warnings":0} | verified | sitewide | node scripts/verify-discovery-surface.js |
| claim.structured-data.jsonld-errors JSON-LD / structured data audit |
{"structured_data_invalid_files":0,"breadcrumb_count":28274,"faq_count":27506,"dataset_count":30,"article_count":27406} | verified | sitewide | node scripts/site-machine-audit.js |
| claim.status.sla-state Status page SLA source |
critical / 4 critical, 0 warnings | verified | sitewide | node scripts/generate-status-page.js |
| claim.provider-alignment.openai-anthropic-gemini OpenAI / Anthropic / Google Gemini benchmark alignment |
benchmark alignment only unless code/config evidence exists | verified | sitewide | node scripts/verify-public-evidence.js --check |
| claim.transparency-report.sha256 Transparency report SHA-256 anchor |
{"report":"transparency/report-2026-Q3.json","sha256":"f154fc87139b42098b02567fc93582c30addafc406420b3aea8bae79b6f4ac93"} | verified | sitewide | node scripts/update-transparency-current-data.js |
| claim.release-integrity.gpg-signing GPG signing status |
GPG signing active locally; checked GitHub commit verification is valid | verified | sitewide | gpg --list-secret-keys --keyid-format=long && git log -1 --show-signature |
System Card V2.0: Technical Transparency Layer
This layer publishes the technical governance evidence that can be safely disclosed: architecture, data sources, AI-use boundaries, quality gates, release integrity, and provider alignment. Source code, secrets, exploitable attack details, and private data remain out of scope.
Public architecture
Cloudflare Workers, R2/D1/KV, and local generation scripts form the public-site and governance publication chain. Public pages disclose behavior, state, and traceable sources, not secrets or internal permissions.
AI-use disclosure
AI-assisted workflows are used for knowledge-base retrieval, cross-checking, and error detection. Governance documents are benchmarked against OpenAI, Anthropic, and Google Gemini public frameworks. Production model usage is disclosed only when code/config evidence exists.
Quality and safety gates
Governance page audit 180/180 passing, JSON-LD errors 0, discovery-surface errors 0. Status pages report critical / 3 critical, 1 warnings as-is.
Data traceability
Knowledge base 32,724 chunks, TM 512,152 entries, AI answer-ready 7,976/7,976. Public metrics trace to data/state-machine/*, data/*audit*.json, and transparency reports.
| Governance area | OpenAI | Anthropic | Google Gemini | Starnum implementation evidence |
|---|---|---|---|---|
| Model/system-card disclosure | OpenAI models + safety docs | Claude model docs + system/model cards | Gemini model docs + safety settings | system-card, model-card, methodology, benchmark, transparency-log |
| Safety evaluation and use boundaries | Safety best practices / deployment checklist | Responsible Scaling / safety policy | Gemini safety controls / policy | AI safety, acceptable-use, ethics, risk-boundary copy, crawler policy audit |
| Data governance | Data controls / privacy controls | privacy and data handling docs | Gemini API data governance references | privacy, ai-data-governance, KB/TM source tracking, SHA-256 hashes |
| Monitoring and release | production checklist / eval discipline | system-card transparency discipline | model/version documentation discipline | deploy.js, status.html, SLA report, trust-pages-machine-audit, sitemap/hreflang audits |
- Sources: data/state-machine/model-card.json, public-bench.json, trust-pages.json, security-headers.json.
- Sources: data/trust-pages-machine-audit.json, data/discovery-surface-audit.json, data/ai-answer-readiness-audit.json.
- Sources: data/kb-machine-audit.json, data/tm/quality-audit-report.json, data/sla-report.json.
- Official benchmark docs checked: 2026-08-20; links are listed in the OpenAI / Anthropic / Google Gemini alignment table.
The V2.0 goal is not more claims; it separates implemented controls from planned controls. Production usage, benchmark alignment, status exceptions, GPG signing, and SLA breaches are disclosed from source data.
Release Integrity And GPG
GPG signing active. signingkey=0934DFA0EDA6363A. Checked GitHub commit verification is valid.
OpenAI / Anthropic / Google Gemini Alignment
The governance surface is benchmarked against the three public frameworks: model docs, system/model cards, safety evaluation, data governance, and use policies. This is benchmark alignment, not a claim that every provider is active in production inference. Official docs checked: 2026-08-20
| Provider | Governance focus | Starnum disclosure | Official source |
|---|---|---|---|
| OpenAI | Model documentation, latest model notes, safety best practices, and data controls. | No verifiable production model setting was found in the production code scan; providers are listed as governance benchmarks. | https://platform.openai.com/docs/models |
| Anthropic | Claude model documentation, system/model cards, Responsible Scaling, and safety policy. | No verifiable production model setting was found in the production code scan; providers are listed as governance benchmarks. | https://docs.anthropic.com/en/docs/about-claude/models |
| Google Gemini | Gemini API model documentation, safety settings, data governance, and platform policy. | No verifiable production model setting was found in the production code scan; providers are listed as governance benchmarks. | https://ai.google.dev/gemini-api/docs/models |