The certification basis of a new aircraft is not just a list of requirements. It is a negotiated outcome. Applicable CS version and amendment: straightforward. Special conditions for novel features, equivalent safety findings, accepted deviations: less so. And if you're in a product space using the non-prescriptive approach (GA, eVTOL, EHPS…), the selected standards you propose as AMC : definitely not straightforward.
Each element has a history, a rationale, a correspondence trail, an agreed scope, links: a life-cycle. And that life-cycle must stay connected to the life-cycle of the compliance data, if you want to trust your compliance picture as the design evolves. Which, when you're developing a whole aircraft, it constantly does, obviously.
What I usually see in practice: the certification basis is defined early, captured in a several-pages document, and revised at major milestones, not continuously. And honestly, how could it be otherwise? It's a document. Keeping it in sync with an evolving design by hand would be an enormous effort. The danger: some disconnects stay hidden until just before a critical milestone. This is where automation and a tool that holds all the data in one unified, accessible, always-in-sync structure makes the difference: giving the airworthiness office and the entire organisation real visibility and confidence.
If you're on the TC holder side, I'd love to hear from you. Anything in here that resonates with you, or does your reality look completely different? Drop a comment if you like: I'm always up for a conversation.